RE: RE: Sender ID in the news

> > From: Julian Mehnle
> > I thought one of the main points of RFC 2822 checking was to avoid the
> > forwarding problems of RFC 2821 checking.  If you do both, you might get
> > the worst of both worlds.
--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
> There must be something in the way I'm expressing myself on this, because
> every time I post on this I seem to create more confusion.  It appears I
> have a natural talent for this.

I think people may be touchy on anything having to do with 2822 at this 
point in time.  I would not take it personally :)

> This is not using any existing spf1 record for a purpose that was not
> intended.  No one with an existing record would have their record
> interpreted any differently than it is today.  It requires the domain
> owner who runs a particularly strict operation to actively publish an
> additional modifier ("eh" suggested by William for "equivalent headers")
> that informs recipients of their strict outgoing controls.  This is a
> modifier, not a mechanism, so hosts that don't understand it MUST ignore
> it.  I cannot see how this will impact anyone negatively and people who
> do a very good job of running an MSA and wish to publish that fact will
> get a slight benefit.

My opinion is that adding to SPF1 records for this is not the best course. 
For one thing, this has to do with MSA policies and SPF is pretty focused 
on the MTA.  For another, the "best practices" in these cases are still in 
the process of being clarified and are not well understood by most ISPs, 
let alone practiced widely.
Probably the best thing to do for SPF1 users is to write up a "best 
practices statement" that says what RFC2476 expects MSAs to do, and to 
encourage senders to follow it, as Part 2 of a two-part anti-forgery 
campaign, where SPF1 is Part 1.  Make it clear to people that SPF narrows 
the forgery playing field down from "anywhere in the world" to "your ISP" 
and it is up to the ISP to close the local loopholes.  Suggest to people 
that if their ISP doesn't comply, that they should give the ISP a ? instead 
of + when referring to them by include, ptr, etc.  (Though creative use of 
SES and a magic DNS server might still upgrade the questionable-sourced 
messages to a "+" status)
I would also suggest that we add "MSA auth best practices and standards" to 
the list of "things to do" for SPF2, because it seems to fit at least 
tangentially with the idea of scopes and wider policy statements.
(Now I might be in the minority here, so I am willing to be overridden, but 
I'm guessing that more people will hesitate to add anything to SPF1, 
however harmless...)


> Most of us, myself included, will not be in a position to benefit from
> this as our providers do not yet meet these standards.  But for the few
> providers who take the trouble to really do it right, meaning enforcing
> submission rights on both 2821 and 2822 identities and providing SMTP
> AUTH so their customers can always send from their own servers, why can't
> we give them a small benefit and some encouragement in the form of extra
> joe-job protection that doesn't cost the rest of us anything?
Again, it's not that I'm objecting to the idea per se, just that I think it 
adds complexity without adding huge value.  It's totally important for ISPs 
to comply, and to state that they comply, but giving them an automated way 
to make that statement is not needed that badly right now, and I don't 
think SPF1 is the best way to do it.
Now if we were talking SPF2 I would be totally all for it :)

gregc

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>