On Fri, 23 Jan 2004, Mark Shewmaker wrote:
: The tests discussed elsewhere on this list in the past week or so
: discussing the possibility of neither header body Sender: nor From:
: having anything to do with the MAIL FROM sender.
They don't in today's world as it is, nor should they. From: indicates an
origin; Sender: optionally indicates an aggregator or gateway; 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. It has
[RFC-mandated, for that matter] traceability implications that are not
inherent to From: or Sender:.
: > I didn't mean that. 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.
:
: 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.
====>
If the connection is closed prematurely the receiver should
act as if a RSET command had been received (canceling any
pending transaction, but not undoing any previously
completed transaction), the sender should act as if the
command or transaction in progress had received a temporary
error (4xx).
<====
This is further clarified by RFC2821:3.9, with rules on server and client
behaviors.
====>
An SMTP server MUST NOT intentionally close the connection except:
- After receiving a QUIT command and responding with a 221 reply.
- After detecting the need to shut down the SMTP service and
returning a 421 response code. This response code can be issued
after the server receives any command or, if necessary,
asynchronously from command receipt (on the assumption that the
client will receive it after the next command is issued).
[...]
SMTP clients that experience a connection close, reset, or other
communications failure due to circumstances not under their control
(in violation of the intent of this specification but sometimes
unavoidable) SHOULD, to maintain the robustness of the mail system,
treat the mail transaction as if a 451 response had been received and
act accordingly.
<====
The behavior described above (which is explicit in RFC821 and a "SHOULD"
in RFC2821) is indeed implemented as described in all currently deployed
SMTP MTAs, to my knowledge.
: The greater expense would come not from larger body data streams but
: because on the very small percentage of emails that make it past your
: envelope tests but not the simple spf body tests: You'll have to
: workaround buggy MTA's by keeping track of these past failures to reject
: at envelope the second time around, or use some other expensive
: workaround.
If it makes it past an envelope check, then something major is amiss, and
the whole shebang is a prime candidate for education, scolding, and/or
blacklisting (so that it *does* get caught by many folks at envelope test
time). We already do this sort of thing in the wild today.
: > Adding a bunch of DATA phase check possibilities to the core spec encourages
: > too many mail senders (you know, the ones who create the SPF records in DNS)
: > to be lazy. This defeats the lightweight check purpose of SPF, which I
: > believe will lead to too many "unknown" results in the wild due to low
: > adoption rate.
:
: Honestly that doesn't make sense. I really don't follow the logic and I
: don't understand what you mean by being lazy: I can't imagine that
: anyone would ever want to skimp on the envelope checks for one, and the
: header checks discussed elsewhere are about as clear as the envelope
: ones.
Encouraging use of header/body checks, which is what putting them in the
main spec would do, defeats the purpose of having lightweight envelope-time
checks. The primary, encouraged method should be the one that lives up to
the [original] lightweight envelope check mission of SPF.
Body-based checks would tend to be easier (hence "lazy") to implement for
less knowledgeable folk, since the From: header is typically more prominent
than the envelope and seems to some as the authoritative place to go. If a
large number of people stuck only DATA-phase checks in their SPF records,
and -- as has been shown in past DATA-phase filtering efforts -- ISPs don't
have the horsepower or contractual ability to check at DATA time, you've
actually done them a disservice.
Those DATA-only SPF records would, instead, return an "unknown" result, thus
equivalent to having no SPF record at all. That puts one hell of a stick in
the mud wrt SPF's goal of being deterministic for the majority of domains.
: > Please, before we fall into the DATA-phase trap, put it in an extension
: > document that is not attached to the core SPF spec.
:
: Uhm, that's effectively the same thing I'm suggesting--I really can't
: see the difference between a separate extension and mention of how to do
: an additional check that people will surely be doing.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The majority of the anti-spam community balks at any kind of new DATA-phase
check, particularly if it's meant to be somehow authoritative.
If my word's not good enough, I wholeheartedly encourage you to ask them
yourself. But an advance word of warning: In this thread, I've been quite
... tactful ... compared to some others you may run into. 8-)
--
-- Todd Vierling <tv(_at_)duh(_dot_)org> <tv(_at_)pobox(_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
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡