At 09:11 AM 5/10/2005 -0400, Scott Kitterman wrote:
>From the last council meeting:
21:19 <freeside> had a chat with mark lentczner a few months ago about
what we would've done differently.
21:20 <Julian> "we"?
21:20 <freeside> one thing he mentioned was that it might be a good
idea to leave out the "-all" completely.
21:20 <MarkK> O?
21:20 <freeside> in other words, if we, the spf community, had just
focused on making assertions for when you do know
it's from the sender --- ie. all the positive
mechanisms, like ip4, mx, a, etc.
21:21 <Julian> I doubt that's what most of the community want.
21:21 <freeside> and then remaining mum about explicitly denying
forgeries --- eg. "if it didn't match, well, we're
not saying it's from us, and we're not saying it's
not, so you draw your own conclusions"
What I would have done differently is to place more emphasis on
administrators needing to control their e-mail infrastructure. At all
points in an e-mail's transmission, onward routing is either under the
control of the sender or the receiver. The point where control transfers is
the one and only one point where SPF checks can and should be done.
At that point, the transmitting MTA should be described in the sender's SPF
record and the receiving MTA can reliably check it. From that point on,
there is some kind of ongoing relationship and trust.
This is not too difficult on the receiving side. Receivers care about spam
more than senders. I'm still having trouble understanding how it will work
on the sending side, however. My mail goes to gain.com, then from there to
mailsystem.us, then out. I've talked to the "tech support" guys at
gain.com, and they really don't understand how mailsystem.us got in
there. I suppose at one point there must have been some technical person
involved at gain. Someone there had to set up the outbound forwarding,
maybe with some hand-holding from someone at mailsystem.us. Even if
someone at gain.com figures it out, he will have to anticipate changes at
mailsystem.us and make the right changes in the SPF records. Then you
still have the problem of some other customer of mailsystem.us forging
gain.com. We can only hope that mailsystem.us doesn't make a deal with
some other forwarder, or that gain doesn't start splitting the mail streams
to different forwarders for different destinations.
What I would like to see is a different expectation for forwarders, and not
so much burden on the endpoints. Trusted forwarders MUST authenticate
incoming (by whatever method they chose), they MUST provide their own ID
for outgoing, and they MUST prepend a standard authentication
header. Every domain then takes care of its own SPF records, and nobody
has to authorize anyone else's servers.
Maybe that won't work either. If very few forwarders comply, the rest will
have no incentive to comply. We need leadership. Someone with clout has
to push a standard. Looks like it isn't going to be the IETF. I worry
that the FTC will bungle it, or Microsoft will try to monopolize it.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *