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
worse:
some kind of "keep-alive" technique.
I believe, that TAMPFAILing is tolerant only for technical reason (no disk
space,
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
final
decision on acceptance of the mail.
My point is that is this analyse take more then average few seconds, you have
to
accept it and then deal with it as you do usually.
If after half of hour brainstorming your software decide that given message
spam,
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
reply
on SPAM, just delete it". I new that is somehow violate RFC but it is nowadays
reality.
- 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.
TBP