(no subject)

[cyrano]

I hate feeling like an idiot. I hate it more when I actually get off my lazy ass and bother trying to figure something out and I don't have enough basic grounding to understand the instructions.
I continue my search to make SPF and SID make sense.
I think I'm going home early.

Comments

[gconnor.livejournal.com]

I have some background on the whole SPF vs SID debacle, if you want some of the backstory. Seek out archives of the MARID list if you want some of the background (but likely not all of it).

OK ttyl.

[cyranocyrano.livejournal.com]

See, my problem is that I don't even understand SPF yet. A co-worker came by my cube and we talked a little more about SPF for Dummies, so I can kind of read one now, at least.

[gconnor.livejournal.com]

So... SPF starts with the question, "How can I tell if this message is really from the claimed sender" SPF then attempts to bite off a smaller, more chewable part of this complex problem, which can be expressed as a slightly different question, "How can I tell if *this* IP address is authorized to send mail for *this* domain"? The proposed answer is to list which IPs are "authorized senders" for the domain, somewhere in that domain's DNS (where presumably only the domain owner has rights to publish such a list). All domains have DNS and TXT records are provided with most DNS services now, so if your domain works for email, it should be cheap or free to publish a little more DNS info to make this list work. (Early versions of this idea were called "Reverse MX" because they listed authorized senders, as opposed to MX records which list authorized receivers).

The rest of the SPF evolution then revolved mostly around two questions. The first was, what tools can we give domain owners so they can publish some simple text that expresses their wishes, other than just a list of IP numbers. For example, "anything in this subnet/range" or "anything with valid reverse DNS showing my domain" or "same as my incoming/MX records", etc.

The second big hurdle was how to deal with forwarding, because forwarders are really agents for the receiver, but they mostly work by keeping the return address (and hence the sender's domain) intact. If you have a LiveJournal email address which just forwards to your AOL account, then effectively LiveJournal sends the message from Receiver agent 1 to Receiver agent 2, and claims the original sender as the sender of the repeated copy. This arrangement is totally unpredictable to the sender, so the second stage would almost always violate the sender's predetermined "authorized senders" arrangement. You would have to somehow rewrite the return address so that any returns are routed back through the first receiver to get around that and many forwarders didn't want to participate in that game. If the sender and 2nd receiver are playing by the rules, but the forwarder isn't, the message would get bounced.

I know that's not a complete explanation but please ask me questions about it... I love talking about SPF and spam prevention in general.

[cyranocyrano.livejournal.com]

That's a pretty good start on theory. What I need to work on now is "How do I read an SPF record, and how can I tell why a particular SPF record fails our validity test?"

Also... mx records list authorized receivers, so that means a list of addresses that can be in the To: field? Or the From: field?