Andy Bakun wrote:
On Sat, 2005-03-26 at 14:39, Radu Hociung wrote:
I would suggest that will people come to this document with two
questions in mind:
1. What is SPF and what's in it for me ?
2. What should _I_ publish?
I would structure it like so:
- Introduction
Explains what SPF is, why is it needed, and who needs it.
- Typical use scenarios
Yes, this is what I was targeting. I was thinking the information would
be arranged, in the typical use scenarios, as:
I'm a home user who has their own domain for vanity or business
purposes and I only use email when at home. My connection to
the Internet is through the monopoly cable provider in my area.
I have configured my email client using the instructions
provided by my ISP and had to tell my email application my
username and password for my ISP. How should I configure my SPF
record?
The SPF record for your domain should be
"v=spf1 mx:isp.com ~all"
because ....
I want to arrange the "question" part with the way non-technical people
would talk about it. That is "tell my email application my username and
password for my ISP" implies SMTP AUTH without having to use confusing
acronyms. These assumptions would be explained in the "because ..."
portion of the "answer". A key could also be provided early on ("if you
have to tell your email program your username and password in order to
send email, then you are using SMTP AUTH"). This way, it makes it
easier after reading a few of them to hone in on the exact configuration
you want and be able to determine which scenario applies to you.
The document's table of contents could be arrange in such a way as to
make it easy to find the group of scenarios that apply to you without
having to read the entire document.
Perfect! Great minds think alike ;)
My own explanation message in the published SPF policy is
"Dear %{s}, please send mail only through mail.ohmi.org port 587 using
your login password"
I have a few users who really don't care about whether it's SMTP AUTH,
POP, IMAP, SPF, etc. It's all an alphabet soup to them and what really
matters is what to type in what configuration fields of Outlook or whatever.
I don't care that forgers get that same Dear... message, because they
know they're not Dear to me and the message doesn't apply to them.
Although the example record you gave is not very good. If the cable
modem runs a vanity domain off of the cable modem, the record should
have been "v=spf1 include:isp.com include:pop3.provider.com ~all"
Even though they send through the cable modem ISP, their incoming mail
sevice (which can generate bounces on behalf of the hosted vanity
domain) is something else, as the cable operator surely won't accept to
handle the incoming mail for the vanity domain.
Perhaps it might be a good idea to discuss the SPF records you are
planning to include in the document first, so you don't have to do too
many corrections. That way, maybe some of the discussions (if any) will
even generate (part of) the explanations that should be included in the BCP.
Radu.