Subject: RE: What Meng said

From: "Jim Lyon" <[email-masked]>
Date: Wed, 11 Aug 2004 09:49:30 -0700

Andy said, quoting Meng: 
>  [11:05:42] <mengwong> if submitter is not present, we fall back to 
> mail-from. people are missing this.

From both my reading of the docs, and what I believe was the intent of
the docs, this is wrong.
If submitter is missing, one needs to get the PRA from the data of the
message.  (Of course, with submitter one must still verify that
submitter == PRA and reject the message otherwise.)

I think that Meng may be referring to the text that states that at some
date in the future (which hasn't been specified yet), one may treat the
absence of submitter as submitter == mail-from.  However, this can only
occur after very wide-spread adoption of submitter-aware MTAs, and after
another standards action.

-- jimbo

Internet commerce will never really take off until you can buy something
online without getting spammed by the vendor.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrew Newton
Sent: Wednesday, August 11, 2004 9:08 AM
To: ietf mxcomp "(e-mail)
Subject: What Meng said

In rereading the Jabber logs and reading the recent threads on 
SUBMITTER, I'd like to point everyone to a simple sentence Meng wrote 
in the Jabber session:  
http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04.html

In defense of "people", I reread marid-submitter and marid-core this 
morning and could not find the place where this was stated.  However, 
this statement is significant.  I'm not saying it is a good or bad 
idea, but it profoundly changes how SUBMITTER is used, the nexus of 
SUBMITTER and PRA, and even the semantics of the RR version identifier.

-andy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Aug 2004 13:11:25 -0700

Jim,

JL> I think that Meng may be referring to the text that states that at some
JL> date in the future (which hasn't been specified yet), one may treat the
JL> absence of submitter as submitter == mail-from.  However, this can only

this is a good example of the reason that specifications should not make
promises or predictions of the future.  that's a social process, not an
engineering process.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "John Glube" <[email-masked]>
Date: Wed, 11 Aug 2004 16:50:08 -0400

Jim wrote -

>>11:05:42] <mengwong> if submitter is not present, we fall
>>back to mail-from. people are missing this.

>From both my reading of the docs, and what I believe was
>the intent of the docs, this is wrong. If submitter is
>missing, one needs to get the PRA from the data of the
>message.  (Of course, with submitter one must still verify
>that submitter == PRA and reject the message otherwise.)

>I think that Meng may be referring to the text that states
>that at some date in the future (which hasn't been
>specified yet), one may treat the absence of submitter as
>submitter == mail-from.  However, this can only occur after
>very wide-spread adoption of submitter-aware MTAs, and
>after another standards action.

I am grateful for this clarification. 

However, it raises the following questions:

* Does PRA check for a malformed SMTP mail from?

* Does PRA check for a spoofed SMTP mail from?

* Does PRA check EHELO?

The answer is it does not. PRA ignores any data which may
be derived from this information at the data transmission
stage.

In the absence of Submitter:

* An MTA which is running a PRA check must swallow the
message to extract the PRA from the headers and carry out
the appropriate checks using the sender policy record found
in the domain's DNS TXT file.

However, some ISPs are going to want to run a full battery
of tests (see the earlier comments by Carl Hultzer of AOL)
at the data transmission stage.

Also we have the apparent decision to have a new version
string for sender policy records to allow for PRA checks.

What does this mean?

Prudent Senders will now have to publish two records, one
to allow an MTA to do a SMTP mail from check (and any other
checks which may be carried out using this data - based on
the unified SPF approach which is not before the IETF but
exists in the wild) and one to allow an MTA to do a PRA
check, since the proponents are insisting receivers can't
rely on any other record set, except that which is
specifically designated for use with a PRA check.

However, this raises the next series of questions:

* When an MTA extracts this data from the DNS TXT file, can
the software distinguish between the two records?

* Will the need for two records places some Senders in the
position of having TXT files which are to large?

* Will all this transmission of data cause unforeseen
problems during the data transfer stage introducing
unforeseen instability into the mail system?

I don't know the answer to these questions, but three
comments:

* Responding to these concerns should be part of the
mandate given to the graybeards who are conducting the
operation and security review of Sender-ID.

* All this discussion points to a solution which allows the
sender to publish one sender policy record which can be
used by a receiver to carry out any one or more checks the
receiver wishes to carry out in accordance with specified
protocols as long as the receiver clearly identifies to the
sender in the event of failure the specific cause so a
solution can be properly diagnosed.

* If the underlying objective of sender authentication is
to thwart spoofing and other technical means used to hide
identity, and since we do not whether the PRA check will in
fact achieve this objective in the wild, from a design
perspective, this approach allows the receiving MTA to
utilize built in redundancy checks. 

In light of these comments, my ultimate questions are:

* Will the chairs now allow the WG to discuss unified SPF
as a solution at least as to writing a sender policy record
for use by PRA and include the relevant portions allowing
receiving MTAs to carry out malformed SMTP mail from, SMTP
mail from, EHELO and PTR checks in marid core at the data
stage in addition to a PRA check, providing the receiving
MTA specifically indicates the reason for rejection, or is
this request simply out of order?

* If that request is out of order, I would ask for guidance
from the chairs to the WG to deal with the issues I have
raised.

I should add that in raising the noted issues I am not
wishing to make life any more difficult for people than it
already is. But, I am concerned if we don't address these
concerns as Meng has pointed out, we may well end up in the
wrong place at the end of the day.

I am asking for a solution which reasonably meets the
underlying objective, while facilitating a common goal
which all parties can reasonably support.

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.734 / Virus Database: 488 - Release Date: 04/08/2004

---

From: Andrew Newton <[email-masked]>
Date: Wed, 11 Aug 2004 17:11:08 -0400

> this request simply out of order?

The reason I asked that alternate proposals not be discussed is that we 
have already had people complain about the confusion.  So please, lets 
hold back the flood gates just a little while longer.

> from the chairs to the WG to deal with the issues I have

Discussion of the problem is certainly relevant.  Its the proposing of 
the solutions that seems to be confusing people.

-andy

---

From: "John Glube" <[email-masked]>
Date: Wed, 11 Aug 2004 17:23:06 -0400

Andy wrote,

>The reason I asked that alternate proposals not be
>discussed is that we have already had people complain about
>the confusion.  So please, lets hold back the flood gates
>just a little while longer.

>Discussion of the problem is certainly relevant.  Its the
>proposing of the solutions that seems to be confusing
>people.

I thank you for taking the time to respond and will follow
the WG chairs guidance as to when it is appropriate to put
forward alternate solutions to deal with the problems
raised, if they are not resolved in the interim.

John

John Glube
Toronto, Canada

---