Re: SMTP REJECT after DATA

[Andy Dorman <ad...@ironicdesign.com>]

Kai Schaetzl wrote:
> 
> Assess that and you find it doesn't make sense to spam-scan messages and 
> reject them in/after DATA stage in a real world scenario. 

I hesitate to jump onto this "firing range", but Kai has always seemed reasonable.

We have very "real world" experience doing this sort of thing and I disagree 
with Kai's statement for incoming email.  FWIW, I DO agree for outgoing email 
while talking with a user's mail client (or the spammer's malware client running 
on a user's PC)

But for incoming email, although I sincerely wish we could reject spam before/in 
the DATA stage all the time, SpamAssassin is not perfect.  AND we offer Block 
and Pass lists to our users and they make mistakes too.  PLUS, there is 
absolutely no accounting for taste and we have some users that WANT their Lotto 
Pick Newsletter in spite of the stratospheric scores.

So even if we can decide an email is spam before the DATA stage, it makes no 
difference since we have to store the thing for a while anyway in case the user 
wants to look for something caught that shouldn't be.

Cheers,

-- 
Andy Dorman
Ironic Design, Inc.
AnteSpam.com, HomeFreeMail.com, ComeHome.net

Re: [sa] Re: SMTP REJECT after DATA

[Charles Gregory <cg...@hwcn.org>]

On Tue, 9 Mar 2010, Andy Dorman wrote:
> So even if we can decide an email is spam before the DATA stage, it 
> makes no difference since we have to store the thing for a while anyway 
> in case the user wants to look for something caught that shouldn't be.

(nod) To rely on this methodology requires that you *rely* upon your
users to apply a conscientious and consistent system of reviewing their
spam trap/folder on a regular basis. If you have this, then without 
sarcasm I would say you are very fortunate.

But in a system like mine where educating ignorant users is difficult at 
best, it feels a bit too dangerous to allow (too much) mail to be received 
and held without notice to the sender. And unfortunately SMTP protocols do 
not contain a code to tell the sender that mail was 'accepted but held for 
review'. The only way to do that is with a separate mail, and that leads 
back to the backscatter horrorshow, which I am quite sure you would never 
advocate.... :)

So for us (and we recognize not for everyone), the policy/practice we have 
chosen is the most workable and efficient. I think the only reason I 
leaped into this thread was because of the overbearing attitudes that 
seemed to completely ignore the fundamental notion of YMMV....

- C