-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At some point hitherto, Paul Iadonisi hath spake thusly: > 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.
This is difficult, if not impossible, to acheive. At least, if I understand you correctly. The SMTP gateway is a mail TRANSFER agent, and knows nothing about what the client wants or doesn't want, BY DESIGN. The exception is probably MS Exchange, which I don't know much about, and wouldn't ever use/manage unless I were starving to death. > 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. This is not a shortcoming in procmail. It's a problem with your corporate policy. If you're going to lay blame, please do so where it belongs... A workaround for this problem is to run fetchmail to get your mail from your IMAP server, and filter it with procmail locally. And IMNSHO, it's a much cleaner way than what you're about to suggest... > 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. Procmail does not suffer from this problem. > 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. Unless I'm mistaken (which is very possible), Cyrus mail tools require the use of Maildir format mailboxes, which just aren't supported all that well. True, a lot of major mail clients support it, but a lot of popular clients don't. And if you need to read mail with mailx in an emergency, forget it. > 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. This seems to me to be making the process of delivering mail to a user entirely too complex. The LAST thing I want, as a system administrator, is dependence on a database program to make delivery of mail work. When you do this, you've probably increased the complexity of mail delivery by more than 100%, given how basically simple sendmail is. That means headaches for me, and I don't like it. You can even configure procmail to send the sender bounce messages, if you really want to. YAY! > > 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. Yes, I have some thoughts. What you're describing is a sysadmin's worst nightmare, and I for one want no part of it. It's a great example of overengineering a reletively simple problem. The best solution for dealing with spam always was and always will be to press the delete key. Anything else runs the risk of losing legitimate mail if it's not configured meticulously, and if you ask me what you describe introduces enough aditional complexity to make it very much not worthwhile. But that's just my opinion... ;-) - -- Derek Martin [EMAIL PROTECTED] - --------------------------------------------- I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Jpt/djdlQoHP510RAv/JAKCLTQyba25L6bJuiKfpmGvP7ZDkdQCgkBly +wbz+rgrLEvIqG6GeuyZaM0= =RV4Q -----END PGP SIGNATURE----- ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
