spf-discuss
[Top] [All Lists]

RE: RE: Sender ID in the news

2004-10-28 00:34:43
From: Greg Connor
Sent: Thursday, October 28, 2004 1:13 AM

<...>

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.

Well, it's the MSA at the sender end telling the MTA at the recipient how to
interpret it's policy, but I tend to agree with your larger point:

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.

This is the real issue.  People have not discussed this seriously enough to
form a consensus on best practices.  That will take time.  It's a pity
because we have an opportunity now and if we let this lie too long, we will
be using our CPU's to validate DK signatures with no thought about the
connection between 2821 and 2822 identities.  Maybe people are not aware,
but DK only makes an identity assertion for 2822.from or 2822.sender.
That's it.  Nothing about 2821, nothing about Resent-Sender: and no
connection between 2821 and 2822 identities.  It would be sad if the whole
discussion was pre-empted by the adoption of DK.  That's my only concern at
this point.  Otherwise, I am content to stick with 2821.mailfrom.


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.

I seriously doubt the ISP's would care, as long as their mail gets
delivered.


(Though creative use of SES and a magic DNS server might still upgrade the
questionable-sourced messages to a "+" status)

Yes it could.  This would have a good effect on the domain but possibly take
the ISP's server off the hook since a bad actor on their server only ruins
the reputation of that domain.  In other words, what we are doing has the
unintentional side effect of decreasing collateral damage (a good thing)
which takes pressure off ISP's to run a clean house (a bad thing).  I know
we can't have it both ways, but I hate to make it easier for spammers to
find a new home by taking the pressure off of ISP's.  Overall, we're doing
the right thing, it's just not perfect.



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.

More than tangentially.  The MSA is the place it all has to happen.  That is
where the user authenticates, if they do that at all, and knowing the user
identity the MSA is now in a position to enforce some policy, if they have a
mind to do so.



(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...)

I would guess you're in the majority on this one and I'm in much the same
place.  I had just hoped that people would be closer to consensus by now,
but we're obviously not there yet.

--

Seth Goodman


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