[Top] [All Lists]

Re: slow email validation problems

2005-09-15 05:01:04

RFC2821 says:

6.1 Reliable Delivery and Replies by Email

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.

OK?  Re-read that until you understand - sending a '250 OK' is to be taken
*seriously*, to the point where losing a message because the system crashes
is considered a "frivolous" excuse.

Exactly! I always have the paragraph in my thoughts. 

Point of our disagreement is: when it is tolerant to use 4xy codes or even 
some kind of "keep-alive" technique.

I believe, that TAMPFAILing is tolerant only for technical reason (no disk 
DNS down, DB down, else). So I expect most of the time to get immediate answer 
ACCEPT or REJECT and, sometimes TAMPFAIL as nothing is perfect.

As a result, it's in my interest to do *anything* I can to avoid sending that
'250 OK' unless I'm very confident that I can deal with it - after all, I know
that while I'm busy being indecisive, it's safely queued on the sending system
that issued a '250 OK' before trying to forward it to me. ;)
We can analyse "generic" situation more in detail. Let us consider that we have 
a mail.
 - FROM is correct or possible, elsewhere you reject/TEMPFAIL mail;
 - Remote host IP is not in BL elsewhere you reject mail;
 - TO is correct elsewhere you reject mail except if LDAP/DB/etc is down so you 
can TEMPFAIL mail;

At this point you start your anti-spam analyse or what ever you want to make 
decision on acceptance of the mail. 

My point is that is this analyse take more then average few seconds, you have 
accept it and then deal with it as you do usually.

If after half of hour brainstorming your software decide that given message 
you can, depending on your policy:
- Forward message to your user with "spam" label
- Discard it as many companies, anyway, regularly says to their users: "Never 
on SPAM, just delete it". I new that is somehow violate RFC but it is nowadays 
- Send report to remote system abuse account if you consider doing the same 
thing to your users.

If you accept it, and it's spam, it means there's a spam source in the
sender site. 
Why not just forward?

If you then violate the RFCs and silently discard it, it won't get fixed.
 On the other hand, if you refuse to '250 OK' it, it will
eventually get bounced by the sending system - and probably double-bounce
because the spam injector used a bogon MAIL FROM:.  And maybe, just maybe,
all those double bounces will hit the mail admin on the head and clue him
in that he has a spam problem that needs fixing....
Scientific fiction ;-) My statistic is that I get about 5% answers on mails 
sent to 
postmaster/abuse. And again most of them are answers of robots.