Does anyone have any opinions or comments on rfc2505? My particular interest is section 3.2: Personal anti-spam filters. One area where all anti-spam measures I've seen so far fall short is that, IMNSHO, mail should be rejectable at the SMTP gateway for your mail organization, yet configurable by the mail recipient. In other words I (and only I) should be able to decide whether or not I want to receive mail from a particular sender, yet if I have chosen to reject it, it should never even show up in my mail provider's systems. It's also been my criticism of most mail filtering tools (including procmail). Procmail filters it independent of MUA, but it doesn't help much with sealed servers running IMAP -- you need permission to put your procmail filters on a server you don't have access to. Most other filtering mechanisms are client specific. I'ld like to be able to switch clients freely and not have to port my filters to each and every client. This is where sieve comes in. I comes as part of cyrus-imapd and does all it's filtering before delivery -- i.e.: it gets delivered to a folder of the recipients chosing and doesn't require login access to the imap server. It has it's own protocol for transfering sieve scripts and can even notify a running IMAP client of new mail in any IMAP folder. I haven't tried any of this yet, but it looks promising. All we need now is for it to be adopted more widely, including any easy way to download, modify, and upload sieve scripts using your mail client of choice.
But I digress.... What I'ld like to see is this behavior, using sendmail and mysql only as an example: o Each recipient who wants mail filtering has an entry in a table in a mysql db. o The table has a list of addresses the recipient is willing to receive mail from, unfettered. o Each user also has list of sender email addresses that will be rejected. o When an SMTP connection comes in and the SMTP conversation reveals that the email's recipient has an entry in the mysql db, check the recipient's address list for the address in the RCPT TO: field. o If the sender's address is in the recipients 'okay' list, then just forward the mail on without question. o If the sender's address is in the recipient's 'not-okay' list, then reject the message with a 550 error code. Now here's the tricky part, that's not in rfc2505: o If the sender's address is not in either of the recipient's lists, then temporarily reject the message with a 451 error code and then notify the recipient of the sender's attempt to reach him. This can either be through a MAILER-DAEMON message, or possibly some other new gui or web interface to the mysql db that indicates the sender's email address and offers the recipient the chance to automatically add the sender's address to his accept or reject list. Or to accept the mail, but not add the address to either list. (This would require a third list of temporary entries good for only one email -- removed when the email is received.) Since the mail was temporarily rejected with 451, the delivery would be attempted again later. It should be possible to specify a timeout so that if the recipient takes no action, a default action is taken. There are still lots of unanswered questions, many of which are specified in rfc2505. The most important one is that you don't want to end up hurting your upstream MX provider. I think that can be solved, however, by sharing your accept/reject database with all your lower priority MX providers. The database obviously needs to be secured -- imagine if the spamdweebs got a hold of a list of addresses you are willing to accept mail from. So a secure mechanism (and written agreement about limiting it's use to mail filtering) needs to be established to transfer this database (similar to DNS zone transfers to secondary DNS servers). Any thoughts? I have some pseudocode that I'ld like to try and code and am interested in any insight or help anyone could give. Especially since it's been a while since I've done any significant coding. -- -Paul Iadonisi Senior Systems Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
