On Wed, 18 May 2005, David MacQuigg wrote:
At 03:59 PM 5/18/2005 -0400, Michael Hammer wrote:
On 5/18/05, william(at)elan.net <william(_at_)elan(_dot_)net> wrote:
>
> http://emailauthentication.org/summit2005/agenda.html
>
> This meeting has a lot of items in agenda on SPF but it seems to be
> controlled by "industry" in particular DMA, Microsoft and their friends
> are over-represented there and I suspect they will be talking about SID.
>
Actually, I believe they will be talking about SID as encompassing
SPF. There was a presentation at Information Security Decisions
(Chicago, May 8-10) where the presenter spoke of SID as the "successor
to SPF". I waved my hand and pointed out the Councils statement,
pointed out the potential for problems where PRA is applied to SPF1
records and suggested that anyone interested should check out the
SPF-DISCUSS list.
Personally I think the Council should step forward and force the issue
with the organizers of this conference. If the Council cannot control
their own standard then it isn't much of a standard. The fact that a
member of the Council will be there and NOT addressing the issues per
the stance of the SPF Council and SPF Community is a shame.
Seems like a futile battle to me. The best you can do is hold them back for
another year. If they really are abusing SPF1 records, the best way to make
that clear to the world is rapid deployment.
How does that solve anything when they are abusing the same records we are
asking people to deploy? No - the best way for resolution is education
about what they are doing wrong which would effectively stop their
deployment and abuse either directly at the end (people will not deploy
solution that is abusing another system) or stop it from at the
standardization stage.
Don't give them any more time to patch their product until nobody can
tell what it is, but it is actually SPF1 in disguise. :>)
If they were doing 100% SPF1 and just called it something else for
convenience of marketing, I'd be fine with it actually and probably
everyone else here as well.
The best thing we can do right now is establish a simple protocol within
which all methods can operate, and the rest of the industry, not involved in
this competition, can move forward. I'm talking about simple things like how
the sender should declare its identity ( *how*, not *what* identity ).
You have serious misunderstanding about security protocols and email sender.
You can not mix multiple things together like that because name of the
connecting mail client (EHLO) is very different then persistent MAIL FROM
session identity and that is different then end-user targeted author name
and address of the message (From:), which may or may not be the originator
of transmission ("Sender:"). You actually have to have separate spec to
protect each identity and it has to be valid on its own. Email is
not authenticated just because some identity X has been authorized.
The above does not mean you can not "hang" accreditation/reputation on one
specific identity but it has to be one and only one for that reputation
system and not just random one chosen at the time of transmission.
I'm actually working on the paper on this very topic. I'll make it
available very very soon and will try to explain this in detail.
Until there is at least a de-facto standard on this and a few other
simple items, there will not be widespread use of authentication,
domain-rating services will not emerge, and we will never get to the
point where every domain wanting to operate a Public Mail Server feels
the need to authenticate.
Domains don't authenticate! (its email servers that authenticate)
Domains records can publish credential records for authorization of
specific email identities but having authorized one identity does
not mean email or the source of it is authenticated! (it just means
that particular identity is not forged/spoofed)
I've written a few proposals, and I'm ready to submit one (the Identity
declaration) to the IETF. Anyone wanting to help is welcome. I'm
particularly interested in avoiding anything that will make it difficult for
SPF to adapt.
The Sender's Declaration of Identity proposal can be found at
purl.net/macquigg/email draft-macquigg-authent-declare in various formats
(txt, htm, rtf). There is also a discussion on ietf-smtp.
Its bad proposal because it mixes completely different identities
without any regard to what it means. You probably need to read a
more on topic of messaging security as I'm not really right person
to explain it and definitely can't do it in few sentences on the list.
BTW - last NANOG meeting (just concluded) had good presentation on
security in general from the expert (not exactly something for everyday
spf user but some of you might find it quite educational):
http://www.nanog.org/mtg-0505/perlman.security.html
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net