ietf-mxcomp
[Top] [All Lists]

RE: What Meng said

2004-08-15 10:09:14

Margaret Olson wrote on August 14, 2004 at 5:39 PM

Here's how I'm interpreting the practical implications of this,
please tell me if I'm just misunderstanding you:

If I want my record to be evaluated based on the PRA algorithm
then I MUST use SUBMITTER

If I want my record to be evaluated based on MAIL FROM then I
MUST NOT use SUBMITTER and my PRA MUST be the same as the MAIL
FROM.

How does this work when the receiving side doesn't understand
SUBMITTER?

Okay, let me venture forth ... and kick the ball a bit
further down the field and ask some additional questions:

* Based on the newest drafts, is it correct to state that
Sender-ID will only read the spf/pra02 version string. 

* Prudent senders will therefore have to publish a v=spf1
version string in the TXT record and spf/pra02 in the DNS
RR type SPF2.

* Will Submitter compliant Senders only use Sender, or will
you want to include SMTP Mail From in case the receiver
can't read Submitter and is only using SPF?

* Would the best practice be to have the domain in Sender
and SMTP mail from the same?

* What about CSV? 

Should prudent senders also be publishing the version
string for CSV?

How will Submitter compliant senders relate to receivers
for example who are using CSV and SPF, but not Sender-ID
for licensing reasons?

I raise these questions as:

* The WG has apparently decided to go down the consecutive
as opposed to the concurrent path.

* This means each protocol will use its own version string,
as opposed to one version string serving all protocols.

* We are now confronted which inter-operability issues, so
making things even more complex.

* These are questions which need to be answered.

In my view, while it is all very nice to say:

* Sender-ID will only read sender-id records and CSV will
only read CSV records, 

We need to ensure a sender can transmit to someone who is
relying on any one or more of:

SPF, 

(Even if SPF is not a formal protocol, it exists in the
wild and unfortunately the most recent Sender-ID protocol
version does not to the best of my understanding give even
the minimal compromise that Meng was asking for to carry
the SPF community forward with Sender-ID. Therefore, please
don't be surprised if ultimately many in the SPF open
source community simply respond by rejecting Sender-ID.),

Sender-ID and CSV, 

(which don't yet exist in the wild to any significant
extent), 

Otherwise we will end up with a mess.

Thanks

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
 



<Prev in Thread] Current Thread [Next in Thread>