On Wed, 9 Jan 2008, Mark wrote:
Since "No meaning is assigned by the mail system to the presence or
absence of this parameter," it really doesn't interfere with anything,
either. So I don't quite get where your "gigantic poison pill" is coming
from.
The poison pill is DSN itself. To see the ENVID, an MTA must advertise the
DSN ESMTP option. Advertising DSN commits the mailserver to accept messages
with the NOTIFY flag, and give those messages onerous special treatment.
Also, ENVID is supposed to be constant over the life of a message, while
SWK can change. Consider my "All Together Now" example in the original
message, where the SWK is:
* First, a poster's principal e-mail address, added so that the
mailing list can recognize her as a subscriber, even though she has a
VERP bounce address.
* Second, the list's submission address, so that recipients can recognize
the list despite its VERP.
* Third, the input address of a forward, so that the ultimate recipient
can recognize the forwarding relationship even though the MAIL FROM
varies due to SRS.
At any rate, I'm just saying the idea is to use ENVID is not new. Nor, for
that matter an "AUTH" extension to the MAIL command, such as the
responsible submitter extension, using SUBMITTER, instead of AUTH as
extension to the MAIL command.(1) Most of these proposals never seem to
have made it; I reckon all for more or less the same reason: it requires
an official extension to SMTP (whereas SRS can simply be implemented
without first traversing a lengthy IETF track).
SUBMITTER is dead because it is required to keep it in lockstep with the
RFC822 headers, and the procedure for mapping from RFC822 headers to the
correct PRA is patented. Also, unless a mailing list does specific header
mangling, messages it explodes will often carry a PRA that is not valid for
the list MTA's IP under SenderID's loopy interpretation of v=spf1 records.
TENBOX/E defines no connection between the message content (including
headers) and the SWK. Unlike PRA, it is safe to reinterpret v=spf1 records
to validate SWKs, since only an MTA that is looking for special treatment
will display an SWK, and only an MTA that was already SPF-pass for the SWK
domain can get such treatment.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=83618262-c476b7
Powered by Listbox: http://www.listbox.com