On Fri, 2004-01-23 at 21:32, tv+spf(_at_)duh(_dot_)org wrote:
On Fri, 23 Jan 2004, Mark Shewmaker wrote:
the envelope
indicates an authoritative DSN return path.
The envelope is most interesting from a forgery (and spam) control
perspective because it is very easy upon which to clamp down.
Error in my thinking: I thought MTAs threw MAIL FROM away.
I did not realize that it was preserved in Return-Path:
As the original and spf-validated MAIL FROM would be available in the
Return-Path: for MTA's or filtering programs to compare on as they like,
I am no longer concerned about the spf1 spec being unable to attain its
own goals, or the would-be-resultant need to soon do mta-level header
checks as spammers adapt, checks that the spec neither requires, nor
enourages, nor mentions.
My concerns on this point was entirely due to my own misunderstanding.
However, for things such as domain-keys checks and similar proposals, I
think that there will still be a general desire to have future spf specs
discuss how to do body checks, so I'll continue this response in that
light.
That is, a discussion of the technical merits or stupidities :-) of
rejects-at-"." for when people are clamoring for it and claim they want
it.
But first, I have to admit to yet another mistake:
: > rejection at DATA requires consuming the whole message, whereas dropping
the
: > TCP connection is equivalent to a transient failure that will cause the
: > remote MTA to retry.
:
: But my understanding was, especially given other emails on this list
: stating this in no certain terms, was that if an MTA considered that a
: transient failure that that was a bug in that MTA
A dropped TCP connection in the middle of DATA is explicitly defined by
RFC821:4.1.1 as equivalent to a 4xx error, not a 5xx error.
I misread: When you mentioned "dropping the TCP connection" above I
simply read right through that without comprehending what you actually
said, somehow reading instead that you were again referring to the same
sort of rejection-at-"." that I and everyone has been talking about,
namely, returning a 5xx error.
I simply didn't catch that you were referring to actually dropping the
TCP connection itself!
I am most emphatically not suggesting that! I was instead suggesting
returning a 5xx error at that point. 571 sounds spot-on to me.
And returning errors after DATA is okay according to RFC2821, section
3.3:
| The end of mail data indicator also confirms the mail transaction and
| tells the SMTP server to now process the stored recipients and mail
| data. If accepted, the SMTP server returns a 250 OK reply. The DATA
| command can fail at only two points in the protocol exchange:
|
| - [...]
|
| - If the verb is initially accepted and the 354 reply issued, the
| DATA command should fail only if the mail transaction was
| incomplete (for example, no recipients), or if resources were
| unavailable (including, of course, the server unexpectedly
| becoming unavailable), or if the server determines that the
| message should be rejected for policy or other reasons.
Of course if MTA's don't respond properly to 5XX codes after DATA, (by
considering them transient failures instead of permanent), then that
problem would have to be worked around somehow, (and I suggested one way
to do so.)
Because I did misread you a couple messages ago, I think it makes sense
to back up and more appropriately re-respond to your previous message:
: > What I said (explained here in further
: > detail) is that rejection at DATA requires consuming the whole
: > message, whereas dropping the TCP connection is equivalent to a
: > transient failure that will cause the remote MTA to retry. So any
: > check that is at DATA is inherently more expensive by several
: > orders of magnitude, as the entire data stream must be received
: > before the 5xx can be sent.
Two things:
1. The first sentence compares the rejection of the forgery (which
as discussed in other messages this week would be done via a 5xx
error code) with dropping the TCP connection.
Where does dropping the TCP connection ever come into the picture?
(I'm guessing you also misunderstood me. If that's so we can drop
the whole dropped-connections confusion.)
2. You then claim that a check at DATA is more expensive, as the
entire data stream must be sent.
My question is "More expensive than what?":
o More expensive than an envelope check?
Nope: We've already done an envelope check, the message so far
passed it, and so we're now obliged to receive the entire data
stream anyway.
Doing a check after we get the data we're obliged to get isn't
any more bandwidth expensive than NOT doing a check after we get
the data we're obliged to get.
o Dropping the TCP connection? No, because even if you wanted
to do that for some reason, you'd just get the same email again
later, so dropping the TCP connection would be more bandwidth
expensive.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡