|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
Chris Owen <[email protected]> wrote It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it". The magic keyword: REJECT-ON-SMTP-DATA. Aka during the "DATA" phase of the email, also directly scan it, then when the spam/virus tool thinks it is spam/virus, you just reject it. This solves a couple of things in one go: - You don't have to handle bounces if you would send a bounce back to the sender "hey you had a spam/virus" because you already accepted the mail, thus less overhead at least there - The sending SMTP server will send a bounce back to the sender. The sender thus gets a SMTP rejection mail, with the rejection reason and knows that you didn't accept the message and why. They can then opt to change the content of the mail or contact you differently. - No more 'spam' folder, as the stuff that is spam is already rejected. You might get a few mails through that are actually spam, but this is mostly marginal. This thus solves completely that email "gets lost". Also note that if a virus/bot or something else silly is trying to send these mails it either has to handle the bounces, which they generally (afaik ;) don't, thus the faked sender doesn't get a swamp of failed deliveries either. This is a Win-Win situation in my ears. Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can better let sending SMTP servers queue a bit (or throttle them) then having to process them anyway later. Of course not all mail platforms can be fitted in this way, but people who have such systems probably already have other ways to handle things. For the excellent Spamassassin, read: http://wiki.apache.org/spamassassin/IntegratedInMta The 'milter' options (originally sendmail, but nowadays also available for other mailers) can do this for you. Other anti-spam tools might also be able to do similar things. YMMV. Oh and of course as a access-ISP, one should also employ this trick to the customers, that way they know that they are sending spam ;) Greets, Jeroen Attachment:
signature.asc
|