[Cadre-politics] forward: note re SMTP connection rejection

[Dan MacNeil]

This info is mostly for sys-admin types, but considering these issues is
part of what makes us better than most email providers. Resolving them
would make us much better. :->  Explaining this is a marketing challenge.

Right now we accept mail, queue it and at our leisure perform expensive
SPAM and virus testing. If it fails the tests, it is quarantined. By the
time we get to testing the mail, it is too late to reject it. We can
only discard it (which we do) or bounce it (send a message back to
sender saying we won't deliver it)

Below is a strong argument for rejecting mail at SMTP time, not
accepting the message in the first place. The problem (as Craig Sanders
points out in a different thread on debian-isp) is that we lose the
ability to qeueue. --We could easily get overwhelmed or need much, much
more processing power.

Good Info for would-be sys-admins about the SMTP conversation here:

http://www.cs.cf.ac.uk/Dave/PERL/node175.html#SECTION001932000000000000000


-------- Original Message --------
Subject: Re: BLOCK: ASSP
Date: Thu, 25 Jan 2007 07:50:15 -0500
From: Rich Kulawiec <rsk at GSP.ORG>
To: SPAM-L at PEACH.EASE.LSOFT.COM
References: <da6da671ea5b2eb3a04cfe176dabae93 at powerviewsystems.com>
       <p05200f04c1dd2a21aac3@[192.168.1.254]>

On Wed, Jan 24, 2007 at 10:25:07AM -0500, ljknews wrote:
> But so long as those user blacklists actually cause an SMTP reject,
> normal social processes will sort it out.  It is when blacklists
> just put an accepted message into a place where nobody will look
> at it that the model is broken.

This is why I'm adamantly opposed to "quarantines".  I think it's
a fundamentally broken concept.

If an incoming message contains a recognized virus/worm, then just reject.
Except for research purposes, there's just no need to spend the resources
to accept such a message, store it, and wait for a human being to do
something with it.  And there is little point in reporting it, as the
most prolific sources are also the least likely to take any action.
(And because what they use for an OS/application environment is in
reality a marvelous incubator for malware, so even if they DO take action,
they'll just get infected by something else tomorrow.)

If an incoming message is classified as spam, then shoving it into a
quarantine also serves no purpose.  If users have to go through that
quarantine to pick out false positives, then they'll spend as much as
time as if they had to wade through all the traffic in their mailbox in
the first place.

Which they will quickly learn not to do.

If users don't go through that quarantine, then messages which have been
accepted for delivery never actually get delivered in any meaningful sense
-- they're being thrown in a bucket that nobody looks at.  Might as well
send them to /dev/null and save the disk space.

Making a binary decision while the SMTP connection is open avoids these
problems, and clearly communicates back to the originating mail server
the disposition of the message.

[ If this still isn't clear, consider what happens when A sends a message
to B whose content is such that a content-aware filter classifies
it as spam.  It goes into B's quarantine, which B never looks at.
Later, B sends a similar message to A (they're both doing research in
the same area) which is classified as spam by an instance of the same
content-aware filter and goes into A's quarantine, which A never looks at.
Later, A & B meet and both accuse each other of ignoring important
research correspondence.  Now replay and see how the classification
mistake is quickly discovered and the social damage avoided by issuing
rejects. ]

---Rsk