Feature Requests

[Guest]

Here are some features I would really like to see in the future:

i) greylisting option

ii) better support for privacy

iii) text-based script/interface to account creation/management

Regarding the first, I noticed that sneakemail now offers greylisting as an option.

The next issue concerns primarily the use of spamgourmet addresses in public forums. Given that some companies (Microsoft in particular) are devoting resources to studying databases of newsgroup postings and developing various metrics to rank participant expertise, one might want more control over the "nym" they use to post messages. A particularly sweet solution is offered by the (apparently defunct) gnosis-anon protocol, that basically uses a simple one-way hash to scramble any "real" email address to <hash>@gnosis.com. Then any mail sent to <hash>@gnosis.com gets forwarded to the "real" address which is stored on its server.

Regarding the third issue, many of us prefer to stay in console-based tools as much as possible (e.g. emacs fanatics). It would be nice to be able to create new accounts and manage existing ones from within emacs or at the command line. Alternatively, it would be very nice to be able to create/manage accounts with a completely email-based protocol.

Nevertheless, I want to add that SG is a great tool as it currently exists and I really appreciate your hard work and generosity in sharing it with all of us.

[SysKoll]

Regarding the third issue, many of us prefer to stay in console-based tools as much as possible (e.g. emacs fanatics). It would be nice to be able to create new accounts and manage existing ones from within emacs or at the command line. Alternatively, it would be very nice to be able to create/manage accounts with a completely email-based protocol.

Actually, we're quite concerned about scriptable access to spamgourmet. If we ever allow sending email from SG (a popular request), we'll have to set up various countermeasures to prevent spammers from using automatically created SG account to spread spam. I am an emacs fanatic myself BTW so you're not alone.

[SysKoll]

User Gianni has posted the following feature request:

Hello!

I'm a very happy user of your service!

I have a request, an option to choose to move the info appended by SG at the end of the Subject line into a specific field of the email header, to avoid cluttering the email Subject.

Example 1, now:

Subject: Force type of column in ODBC (profox_list: addressed to trusted sender for this address)


Example 2, after choosing the new option:

Subject: Force type of column in ODBC
Spamgoumet info: profox_list: addressed to trusted sender for this address


The latest option leave the info normally invisible.

Thanks for the attention!
Gianni

[josh]

What's the official definition of grey-listing?

As regards CLI/script oriented tools, be sure to check out John Bajana-Bacalle's VI/VIM macro that is available in the Downloads section off the front page.

[ebuleheb]

I think it's here: http://projects.puremagic.com/greylisting/
Basically, when someone tries to send mail to a graylisted address, the receiving SMTP will report a temporary error, suggesting the sender to retry later. If the sender is a spammer, he won't retry (read the text for the reason), if it's a legitimate server it will retry for enough time and then it will be accepted.
I have always been wondering why SG just accepts and discards all those messages. It seems to me that you're losing a lot of money unnecessarily. The FAQ says it's cheap, but when you think of the possibilities it is far from the cheapest solution. I remember reading an explanation in a discussion (maybe in the old forum), but I can't find it, and I don't remember exactly. Is it for preventing spammers from finding valid (unexpired) addresses? I wish a better solution can be found. Sneakemail seems to me more reasonable to me because of those (for my needs of course). They have lots of free users and also premium users. They're earning money instead of losing. So this suggests to the users a greater chance of future continuity of the service.

[SysKoll]

Greylisting breaks some mail systems, especially large corporations who have a pool of MTAs. That's explained in the linked document. It also forces a delay between the sending and the reception of a message.

So at best it would be a user-selectable option.

Besides, I expect spammers to start handling retries pretty soon. A large proportion of spam now comes from trojaned Windows machines, and it's relatively simple to add a retry function to spam Trojans. So at best, the effectiveness of greylisting is measured in months, not years.

[ebuleheb]

I had read the article partially and skimmed through most of it, not noticing what you said about breaking some mail systems. Of course you know it better and I agree that it should be optional if it gets implemented (btw I wasn't trying to say that it should be enforced, of course it'd be optional but I didn't say).

Anyway that greylist part was a reply to Josh's post and the thing I find more important is saving our system from unnecessary load (though i'm not sure if it is really unnecessary because i'm not sure if we can do it the other way). The amount of users is continuosly increasing (although he may limit in the future). The number of addresses is definitely quickly increasing. The amount of spam is also increasing quickly.. I wonder how much longer the system can resist the load, eating over 100k messages every day. Can't we just reject the messages (just after RCPT TO) that would otherwise be eaten, saving bandwidth? It would also notify legitimate senders that they couldn't reach.

[SysKoll]

Well, the answer to that question is really easy: Greylisting takes more CPU (because you have to store and retrieve the address triplets) and more DB space. On the other hand, with the current generation of spamming software, you save bandwidth because you send a temp error to the spam source before it has a chance to send the body of the spam message.

I expect this advantage to vanish very quickly. Look at how fast spammers reacted to the blacklisting of major spam spewers. They paid coders to write the spambot Trojan that are now infecting hundreds of thousands of Windows machines equiped with broadband access. These Trojans are now a major source of spam and their distributed nature make BLing impossible.

As for the temp error sent to legit senders, that's the biggest drawback of the system and it's guaranteed to generate help requests. ("Help! Aunt Amy emailed me her pictures yesterday and when dialed up AOL this morning, she got something about an error message at my address! SG is broken!" -- or worse, a note from Aunt Amy herself telling us to fix our site.)

So if greylisting starts becoming prevalent, the next generation of Trojan will have a retry function.

Meanwhile, here is what I propose: we put the greylisting feature as an option if:
1. bandwidth starts to be a problem ,
2. CPU is not too busy,
and 3. spammers haven't released retrying spambots yet.

[James Day]

There's a variation on graylisting which I'm eventually going to implement in a SpamPal plugin. Mail arrives at the mail server normally and is stored. The plugin checks the date, logs a unique hash code for the email and tags the header with "graylisted". Client mail program set to leave mail with that header on the mail server. Once a predefined time limit passes, the header is no longer added and the mail proceeds to the client normally the next time mail is checked. Whitelisted addresses exampt from the delay. Once it's in place, you can get mail from friends every 5 minutes but still give the DNSBLs a couple of hours to recognize the spammers. Without it, checking mail every 5 minutes gives the DNSBLs too little time to react, so more spam leaks through.

Not true graylisting because it's not exploiting the lack of retries, but it's a lot safer, because the receiving behavior is completely normal.

Probably too costly to implement here, because you would have to store the email for a while, then check the DNSBLs before finally forwarding it. Trusted senders could be the whitelist here.