Jim wrote -
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.
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