Home | Sitemap | Recent Changes | Login

SPF Logo

Sender Policy Framework

History of FAQ/Hints for ISPs


Revision 12 . . (edit) 2008-04-14 3:24 (UTC) by Frank Ellermann [IANA link]
Revision 11 . . (edit) 2008-04-14 3:17 (UTC) by Frank Ellermann [s/maybe/please/]
Revision 10 . . (edit) 2008-04-14 2:40 (UTC) by Frank Ellermann
Revision 9 . . (edit) 2008-04-14 2:39 (UTC) by Frank Ellermann
Revision 8 . . (edit) 2008-04-14 2:31 (UTC) by Frank Ellermann [guess]
Revision 7 . . 2008-04-14 2:18 (UTC) by Frank Ellermann [fixed type, added note about redirect=]
Revision 6 . . 2008-04-14 1:58 (UTC) by Frank Ellermann [Explain include magic]
Revision 5 . . 2006-12-10 16:10 (UTC) by Julian Mehnle
Revision 4 . . 2006-11-11 8:08 (UTC) by Scott Kitterman [Added port 465 to the SASL recommendations]
Revision 3 . . 2006-03-11 17:23 (UTC) by Scott Kitterman
Revision 2 . . 2006-03-11 17:21 (UTC) by Scott Kitterman
Revision 1 . . 2005-11-05 17:28 (UTC) by Koen Martens
  

Difference (from prior major revision) (minor diff, author diff)
Paragraph 11Paragraph 11

This means that any mailer claiming to be <tt>mailer2.your.domain.example</tt> with an address different from <tt>A( mailer2.your.domain.example )</tt> in the EHLO got it wrong.

This means that any mailer claiming to be <tt>mailer2.your.domain.example</tt> with an address different from <tt>A(mailer2.your.domain.example)</tt> in the EHLO gets a FAIL, receivers checking SPF hopefully reject FAIL.



More interesting, your users with various domains cannot be sure what outbound servers you use.  But they need to know this when they try to publish policies for their domains, and wish to send mail using your services.

More interesting, your users with various domains cannot be sure which outbound servers you use.  But they need to know ''or guess'' this when they publish policies for their domains, and wish to send mail using your services.  Forcing users to ''guess'' is a bad idea.



To make this as painless as possible for them offer a policy they can '''include''' enumerating all your outbound servers by name (SPF "'''a'''" mechanism), or by number (SPF '''ip4''' or '''ip6''' mechanism), or if you must, use the '''mx''' mechanism as an indirect way to list all names - but note that MX is actually about your inbound servers, this trick makes [[FAQ/Common_mistakes#no-mx|only]] sense if inbound happens to be the same as outbound for your mail servers.

To make this as painless as possible for them offer a policy they can '''include''' enumerating all your outbound servers by name (SPF "'''a'''" mechanism), by number (SPF '''ip4''' or '''ip6''' mechanism), or if you must, use the '''mx''' mechanism as an indirect way to list all names - but note that MX is actually about your inbound servers, this trick makes [[FAQ/Common_mistakes#no-mx|only]] sense if inbound happens to be the same as outbound for your mail servers.

Paragraph 21Paragraph 21

Your users might have not the faintest idea what that is about, and maybe you intend to offer a Web form or similar, where the smarter users can set their SPF policies, actually published by you, because your services cover mail + domain + DNS.

Your users might have not the faintest idea what that is about, and maybe you intend to offer a Web form or similar, where the smarter users can set their SPF policies, actually published by you if your services cover mail (SMTP) + domain (DNS).



In that case simply offer '''include:dummy.your.domain.example''' as default like this for all domains hosted by you:

In that case offer '''include:dummy.your.domain.example''' as default like this for all domains hosted by you:

Paragraph 24Paragraph 24

That means mail from <tt><nowiki>any@user.example</nowiki></tt> gets an SPF PASS if it is sent via your servers, otherwise it gets NEUTRAL.  You can offer to switch it to "otherwise FAIL" when a user wants this.

This means that mail from <tt><nowiki>any@user.example</nowiki></tt> gets an SPF PASS if it is sent via your servers, otherwise it gets NEUTRAL.  You can offer to switch it to "otherwise FAIL" protection when a user wants this.



Maybe add "'''a'''" to the default for <tt>user.example</tt> if that is not anyway covered by <tt>dummy.your.domain.example</tt>.  While you are at it maybe also publish identical policies using the new SPF RR type, using TXT is a kludge until all name servers and SPF implementations can deal with the new DNS RR type.

Maybe add "'''a'''" to the default for <tt>user.example</tt> if that is not anyway covered by <tt>dummy.your.domain.example</tt>.  While you are at it please also publish identical policies using the new <html><abbr title="SPF resource record">SPF RR</abbr></html> type, using TXT is a kludge until all name servers and SPF implementations can deal with the new [[http://www.iana.org/assignments/dns-parameters|DNS RR]] type.


Please note that</em> '''?all''' and '''-all''' in an '''include'''d record have the same "no match" effect, the including policy needs its own '''-all''' for FAIL-protection. However, if the dummy record is also the target of '''redirect'''ions, the difference matters:

> <tt>your.domain.example. IN TXT "v=spf1 a redirect=dummy.your.domain.example"</tt>