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.