Subject: RE: What Meng said

From: "Harry Katz" <[email-masked]>
Date: Wed, 11 Aug 2004 16:29:38 -0700

On Wednesday, August 11, 2004 1:57 PM, Dave Crocker wrote:

> Jim,
> 
> JL> I tend to agree.  Should we remove the language about the future 
> JL> from the SUBMITTER spec?
> 
> 
>  my very strong, personal preference is to have a 
> specification make no  statements about the future, and 
> particularly not about plans.
> 
>  the one exception, of course, is to show technical possibilities.
>  examples of how a spec is capable of being enhanced.  not 
> will be, not  planned to be, but what technical flexibilities 
> are present.
> 
>  and of course it's always good to show examples of how the 
> spec might  be used NOW (or, rather, after it is published...)
> 
>  sorry for being so pedantic, but i want to be clear about 
> what i do  mean by the suggestion.
> 

I did remove references to future behavior from the -02 version of the
Submitter spec.  Please see the change notes at the end of that doc.  If
I missed any occurrences, please let me know and I'll remove them for
-03.

---

From: "Harry Katz" <[email-masked]>
Date: Mon, 16 Aug 2004 09:52:06 -0700

My apologies for the confusion.  You are correct that there are some
hold-overs from Caller-ID on that wizard, including the use of an _ep
subdomain.  The text of the wizard does need to be updated.  We'll get
this corrected ASAP. 

> -----Original Message-----
> From: John Glube [mailto:[email-masked]] 
> Sent: Friday, August 13, 2004 5:15 PM
> To: Harry Katz; 'Meng Weng Wong'; 'Mark Lentczner'; 'Andrew 
> W. Donoho'; 'Carl S. Gutekunst'
> Cc: 'IETF MARID WG'
> Subject: RE: What Meng said
> 
> Harry,
> 
> If one goes to:
> 
> http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.asp
> x
> 
> A wizard has been set up to assist folks in publishing what 
> is called an 'E-mail policy document' which can be used by 
> people who have implemented Sender-ID
> 
> I found this link by going to:
> 
> http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
> 
> (It is referenced under related links.)
> 
> If you run through the wizard, at the last page, you will 
> find the following statement:
> 
> Your E-Mail Policy Document must be published in DNS records 
> of type TXT in the subdomain "_ep" under your domain. Consult 
> the documentation of your DNS administration tools for 
> further details on publishing this.
> 
> It is my understanding:
> 
> * the marid protocol for SPF (to be renamed Sender-ID) does 
> not require publishing the 'E-Mail Policy Document' in the 
> subdomain "_ep." 
> 
> * this is a carry over from the Caller-ID protocol.
> 
> * with the merger of SPF and Sender-ID this requirement was dropped
> 
> With the media drive now underway to get the word out about
> Sender-ID:
> 
> * if people go to the SPF site they will receive one 
> instruction for publishing an Sender Policy Framework in DNS 
> records of type TXT;
> 
> * if people go to the anti-spamtools.org site, people are 
> going to be lead to believe they have to publish their 
> 'E-Mail Policy Document' in DNS records of type TXT in the 
> subdomain "_ep."
> 
> With the ongoing issue of a change in version string and 
> whether you have to publish one or two records, this raises concerns.
> 
> I am not wanting to suggest any malice on anyone's part. 
> 
> I suspect what happened is that someone in setting up the 
> wizard simply read the wrong document.
> 
> If you scroll down the page at:
> 
> http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
> 
> you will note that the: 
> 
> >Sender ID Draft Specification: MTA Authentication Records in DNS"
> 
> is the version dated June 23, 2004 which is now out of date.
> 
> Can we get this rectified so that the wizard is based on the 
> most recent version of the protocol? 
> 
> Otherwise I suspect people are going to be publishing the 
> wrong records in the wrong place.
> 
> John
> 
> P.S. I also note the following additional statements on this page:
> 
> http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
> 
> concerning the wizard.
> 
> >Note: This tool is in beta, pending IETF approval. SPF 
> records created 
> >with this tool will require later revisions.
> 
> >To check for the SPF record in incoming mail, your ISP or system 
> >administrator will need to update to Sender ID-compliant software to 
> >check for the Purported Responsible Address (PRA) of incoming mail.
> 
> >If you are a software developer and are interested in 
> implementing the 
> >PRA check in your software, please review the terms of the Caller ID 
> >for E-Mail implementation license agreement before you begin. Please 
> >note that Microsoft does not require a license agreement for 
> >individuals, companies, or ISPs who wish only to publish 
> their Sender 
> >ID SPF text records.
> 
> I simply reference this material in passing.
> 
> 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: "Sauer, Damon" <[email-masked]>
Date: Tue, 17 Aug 2004 11:22:51 -0500

I agree with Andrew.
I think it will also be most useful during the transition.

Regards, 
Damon Sauer 

[Postmaster]  -----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Andrew W. Donoho
Sent: Tuesday, August 17, 2004 12:12 PM
To: Meng Weng Wong
Cc: IETF MARID WG
Subject: Re: What Meng said

On Aug 17, 2004, at 09:25, Meng Weng Wong wrote: 

Sender ID as currently specified doesn't do that. 

If people want the MAIL FROM to play a role in Sender ID, 
they should say so. If they do not say so, the working 
assumption is that nobody cares. 

I personally think that if the PRA lookup returns "none" or 
"unknown", MAIL FROM should be checked, and if that test 
returns "fail" then the message should be rejected. 

Meng, 

This statement does not make any sense to me. SPF is a 2821 time check.
While the Sender-ID spec tries to eliminate it, Sender-ID is really a
2822 time check and it performs a different function than SPF. There is
no reason that Sender-ID precludes an SPF check. In fact, if you think
of the anti-spam problem as a security problem, then you want defense in
depth. You want any mail to pass multiple checks. Therefore, I think
many operators will check SPF before the DATA phase and Sender-ID, along
with other anti-spam filters, after receipt. That is the beauty of SPF -
it is simple and, hence, performs one thing well. While you made a deal
to combine the two specs, that is not necessary and I think that the SPF
community is uninterested in dropping a working simple protocol. They
can coexist. 

Andrew 

____________________________________ 
Andrew W. Donoho 
[email-masked], PGP Key ID: 0x81D0F250 
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m) 

*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you received this in error, please contact the sender and delete the material from all computers. 113