spf-discuss
[Top] [All Lists]

RE: Council: The Meeting on 2005-02-29

2005-02-24 10:40:44

Microsoft/Sender-ID and SPF.  Meng reported that he had been 
in contact with Microsoft and that they had complained about 
three aspects of the current official SPFv1 specification 
draft[4]: the mention of HELO checking, the limitation of 
SPFv1 records to the use with RFC 2821 identities, and the 
concept of zone cut defaults.  During 70 minutes of 
discussion, the following conclusions were reached:

  * HELO checking:  Everyone agreed that HELO checking should 
be kept in
    the SPFv1 specification, and nobody made a motion to repeal the
    existing resolution[11].

I don't know why Microsoft is objecting to this, have we got any details?

I believe that it is important to offer HELO as an option because there are
going to be people making that check, there is no way to stop them so we
might as well ensure that everyone makes the same check.


  * Zone cut defaults:  Following the last month's discussions of the
    issue on the spf-discuss mailing list, it was quickly 
agreed on that
    the zone cut default algorithm should not be used by SPFv1[12].

I think this is the right decision, recent movement on DNSEXT suggests that
the idea of macro-wildcards is receiving serious attention. This is an
administrative convenience, I would prefer to avoid overcomplicating the
spec if possible. Making use of the cut is bad voodoo to be avoided if
possible.

I am currently working on a proposal for Domain Keys Identified Internet
Mail that addresses these issues. I think they are soluble.

  * Limitation of SPFv1 records to the use with RFC 2821 identities:
    Meng reported that he had been told by Microsoft that the IETF DEA
    directorate was going to review a set of drafts that 
would constitute

    However, the other council members unanimously reaffirmed 
their view

Yeah yeah, you decided not to give an inch. As is pointed out elsewhere the
DK license is also incompatible with the GPL, nobody has complained. It is
not only the Microsoft lawyers who have a problem with issuing a license on
the terms demanded by Rosen. I don't think any corporation is going to
provide that type of license.


I believe that it is important to offer HELO^d^d^d^dPRA as an option because
there are going to be people making that check, there is no way to stop them
so we might as well ensure that everyone makes the same check.

IIM, DomainKeys & Co. -- competing or complementary to SPF?  
Julian surveyed the council for opinions about the position 
of other sender authentication technologies like Identified 
Internet Mail (IIM)[15] and DomainKeys[16] relative to SPF.  
It was a common, even uniform, view that those were not 
directly competing with SPF, but really were complementary. 

It is probably going to be necessary to use both DNS and cryptographic
authentication in parallel. SPF has a curious feature that makes it
practical for very large senders and very small senders. It gets really hard
for medium sized enterprises to implement it however. We have a lot of
infrastructure deployed that sends various email alerts as part of its
normal function, this is spread over a huge number of co-locs in very
complex ways. To make things worse a lot of the installations are NAT'd and
firewalled.

It turns out that it is actually easier for us to implement DK
authentication than SPF. The necessary code is simply rolled into the next
software distribution and pushed out. 

Julian added that within the field of content-bound (as opposed to
transport-bound) authentication methods, he actually 
preferred full-blown message cryptography methods such as PGP 
and S/MIME. 

S/MIME and PGP both have serious problems when it comes to ubiquitous use.
Eudora reacts baddly to S/MIME and PGP mail unless it has the right plug in.
Older AOL software gives spurious warnings, it's a mess.


Also, he and Wayne voiced some reservations 
against the equivalent use of transport-bound and 
content-bound methods (i.e. SPF and IIM/DK) to compensate for 
the shortcomings of each, and they promised to elaborate on 
the spf-discuss mailing list.

They are not equivalent, that is part of the point, the systems fail in
different ways. DK is subject to the replay problem but it does not affect
the use at VeriSign or for that matter any Enterprise that does not provide
public access. 


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