-----Original Message-----
From: Dennis Willson [mailto:taz(_at_)taz-mania(_dot_)com]
Sent: Friday, August 26, 2005 5:23 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] SMTP Question
I thought I would ask those on this list that are far more
knowledgeable about the RFCs and real eMail standards than I
a question:
I've seen postings where people say that you cannot do SPF
checks on the From address that's in the data (what a lot of clients
display) because you cannot interrupt the data with an error.
However, can't you return an error AFTER the data command is
complete?
For example instead of: "250 2.6.0 Queued mail for
delivery", return "5xx some error message" instead?
Yes, of course.
I realize that you would have still temporarily stored the
message (maybe not based on the implementation, you may have
seen the failure your looking for fairly early then just
pretended to accept the rest of the data). But won't this
return an error to the sender in the same fashion as
returning an error after the "mail from" or "rcpt to"
command? I thought it would. This should not break the "chain
of custody" as required by the RFCs as you never returned a
good return code as to having accepted the message (I think anyway).
Yes, as long as it's a real sender and not a virus/trojan
spammer/worm which doesn't care about result codes after
it sends data, but then dropping the emai is a GOOD THING.
Please let me know if this is correct... I don't mean to get
flamed here, I have just been thinking about some issues
between several of the eMail "anti-Spam" and "Authorization"
solutions different people are talking about (on this and
other mailing lists) and knowing this may help understand
some of the points different people are attempting to make.
Most of the people on this list seem to know more real RFC
based information than most of the other mail lists I get.
We DENY (reject) LOTS of email after the data is sent and
before we confirm acceptance.
(Real email servers must deal with this since your email
server might even crash during reception.)
For instance...
I use greylisting up front BEFORE the data but ONLY on
selected (read: suspicious) messages, but if a message
is received without checking greylisting AND SpamAssassin
indicates it is likely spam THEN we temporarily defer
the receipt of the message (temp reject) and expect a
REAL email server will come back later for a retry and
that most spammers (92% actually) will never return,
thus knocking spam (that must be reviewed) down by a
full order of magnitude.
--
Herb
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com