Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er

From: "Daryl Odnert" <[email-masked]>
Date: Thu, 19 Aug 2004 13:17:53 -0700

John,

I understand that Sender ID, as currently written, does
not prevent joe jobbing and the associated "blowback" or
"backscatter" problem that results from this practice.

I disagree with Chris that Sender ID makes this problem
significantly worse than it is right now.  Why?  Because
his example assumes that a hacker/spammer/zombie has gained
access to an MTA that is willing to accept mail with
a reverse-path in the victim's domain.  At this point, it
is not difficult to construct messages that will be rejected
with 5xy errors at the recipient's relay.  You don't need
the recipient's MTA to have implemented Sender ID testing
to make that happen.

I think a proposal that would enable both reverse-path
and PRA authentication is definitely a worthwhile endeavor.
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-00.txt
for more insight into that choice.) 

Daryl Odnert
Tumbleweed Communications
Redwood City, California

---

From: "John Glube" <[email-masked]>
Date: Sat, 21 Aug 2004 10:43:06 -0400

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