Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NANOG: users
REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
 

Index | Next | Previous | View Flat


jeroen at unfix

Jul 1, 2008, 2:54 AM


Views: 485
Permalink
REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)

Chris Owen <owenc[at]hubris.net> 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
Attachments: signature.asc (0.18 KB)

Subject User Time
REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) jeroen at unfix Jul 1, 2008, 2:54 AM
    Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) owenc at hubris Jul 1, 2008, 7:28 AM
        Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) justin at justinshore Jul 1, 2008, 2:17 PM
    Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) vandry at TZoNE Jul 4, 2008, 2:01 PM
        Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) justin at justinshore Jul 4, 2008, 11:05 PM
            RE: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) Skywing at valhallalegends Jul 4, 2008, 11:25 PM
    Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) jfmezei at vaxination Jul 5, 2008, 1:52 AM
        Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) justin at justinshore Jul 5, 2008, 8:50 AM

  Index | Next | Previous | View Flat
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.