Daryl,
I appreciate your suggestion that:
I think a proposal that would enable both reverse-path and
PRA authentication is definitely a worthwhile endeavor.
I also appreciate your comment that:
But I wouldn't necessarily throw away the existing Sender
ID proposal on the basis that it doesn't solve a problem
that the authors chose not to solve in the first place.
(Read
http://www.ietf.org/internet-drafts/draft-ietf-marid->rationale-0
0.txt for more insight into that choice.)
The approach of using a best current practice document to
'bridge' the gap is probably the most workable solution.
My concern is that the good faith proposal put forward by
Harry in suggesting a BCP that only deals with checking for
malformed SMTP mail from addresses at the data stage does
not go far enough.
I appreciate from a design perspective there is a strong
view the semantic differences between "the 2821 MAIL FROM
address and the 2822 headers" should not be bridged through
Sender ID or any related BCP.
See the RE: Forged Sender (Resent-From) attacks thread.
I certainly applaud the proposed effort as outlined in the
Sender ID Framework Overview' as found on the Aug 20th
version of:
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
My concern is that this overview does not accommodate the
proposal of doing a malformed SMTP mail from check and an
SMTP mail from check in the absence of PRA at the data
stage.
In fairness, I am having difficulty understanding the
rational for not crafting a BCP which accommodates the
suggestion of doing an SMTP mail from address check in the
absence of PRA.
Without this accommodation, we run the significant risk of
an environment of two solitudes developing between those
system administrators who support Sender-ID and the SPF
community of system administrators.
(I trust in only referencing system administrators I have
not offended others who are involved in this overall
effort. I am simply suggesting those who have to implement
and administer what ever is proposed is the core audience.)
I suggest that MS and those who support Sender-ID need to
reflect strongly on whether this is an ideal outcome.
If it is not, then I would urge MS and those who support
Sender-ID to come forward with a best current practice
document which accommodates the concerns I and others have
raised.
On the other hand, if it is felt system administrators and
others, being the folks who will put into practice what is
proposed by MARID will simply follow suit once Sender-ID is
approved as an IAB protocol, then perhaps there is no need
to change course.
Personally, I think this is a mistaken presumption, but
then only time will tell.
John
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004