[105772] in North American Network Operators' Group
REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Tue Jul 1 05:56:32 2008
Date: Tue, 01 Jul 2008 11:54:46 +0200
From: Jeroen Massar <jeroen@unfix.org>
To: Chris Owen <owenc@hubris.net>
In-Reply-To: <sAe610KZ4TaIFAPO@perry.co.uk>
Cc: nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig044B72F8A64CFDEF367C0F12
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Chris Owen <owenc@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=20
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=20
virus/bot or something else silly is trying to send these mails it=20
either has to handle the bounces, which they generally (afaik ;) don't,=20
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=20
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=20
better let sending SMTP servers queue a bit (or throttle them) then=20
having to process them anyway later.
Of course not all mail platforms can be fitted in this way, but people=20
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=20
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=20
the customers, that way they know that they are sending spam ;)
Greets,
Jeroen
--------------enig044B72F8A64CFDEF367C0F12
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIaf7mKaooUjM+fCMRAsGZAKCwK46bE1cVH+U+ZhnDX6v5GU6NnQCgjKFK
woSI6+jxMCwDI0o1lR8aZhE=
=5Rca
-----END PGP SIGNATURE-----
--------------enig044B72F8A64CFDEF367C0F12--
