RE: SPF record confusion

Thanks for posting your question here.

As you have probably discovered the format for SPF records can vary greatly
depending on the version of SPF Record you choose to create (version 1 or
2) and on the options that you chose when you ran the wizard. Hopefully I
can shed some light on the topic here.

There are 2 versions of SPF records, 1 and 2 (go figure!). Each version is
associated with a different set of message headers from which the PRA
(Purported Responsible Address) can be determined. The PRA is simply who
the sender CLAIMS to be. Each version and set of message headers is
associated with a different RFC that defines the headers for that portion
of the message and you will see terms for each of these used almost
interchangably to describe them.

- SPF1 / RFC8281 / "Mail From"

SPF1 records are intended to be read, interpreted, and acted upon by
a receiving mail server that relies on determining the PRA from the address
specified in the "Mail From" command in the SMTP dialog. The "Mail From"
command is defined in RCF8281 along with other SMTP commands like EHLO,
"Rcpt To", Data, etc.


- SPF2 / RFC8222 / "PRA"

SPF2 records are intended to be read, interpreted, and acted upon by
a receiving mail server that relies on determining the PRA from the address
specified in one of the following SMTP commands: Sender, From,
Resent-Sender, and Resent-From. These header commands are defined in
RFC2822. These are the SMTP dialog commands that are entered after the
"Data" command, which is one of the RFC2821 commands. In some SenderId
discussions and documents the sender in these headers is also referred to
as the "PRA". But PRA can also be used in general terms to refer to the
supposed sender of the message.

You will notice that the format of SPF1 and SPF2 records is different to
make it more "interesting". Don't concern yourself with the format much as
long as you have chosen the right options in the wizard.

If a receiving mail server like Exchange 2003 SP2 finds an SPF2 record in
the DNS zone of the purported sending domain, it uses it for senderid
verification. If one does not exist, it looks for an SPF1 record and uses
that. If that does not exist either, it doesn't usually fail verification
but rather passes the fact that it could not find it on to the IMF and then
the IMF uses that info to assist in determining the SCL (Spam Confidence
Level) of the message.

In short, you don't really need any SPF records at all, but if you want to
reduce the likelihood that messages sent from your domain will wind up in
someone's junk mail folder, then I would BOTH types. It does not hurt to
have both as discussed above. The receiver will look for the version(s)
that it supports.

Keep in mind that one of the purposes of senderid is to protect your
customers and your reputation by reducing the chance that a malicious
entity will send email as your organization and then prompt innocent
victims for personal information or direct them to a malicious website.

One other note...the wizard at
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
seems broken right now. If you choose to create both kinds of records it
only creates an SPF1 record, whereas if you choose to create only SPF1/Mail
From/RFC2821 it creates both.

My advice to you...choose the option on that wizard to create the one for
RFC2821 (effectively creating both) then send those to your ISP or add them
to your own public DNS zone as TXT records.

Another note, the above wizard gives you A LOT of options. In a small
business server scenario I would keep it simple and choose to create
records for IPs for which you have MX records. That is, check the box
labeled "Domain's inbound servers may send mail". Because most likely in
SBS your outbound mail server is also your inbound mail server. But if you
choose the option in SBS to forward outbound through a smarthost, then you
might want to also choose the option to add your ISPs domain or outbound
mail server IP addresses since they will essentially sending mail on your
behalf.

I know this is a lot to digest. Let us know if you have any additional
questions about this.

Jim Martin - (MSFT)
jimmart@xxxxxxxxxxxxxxxxxxxx
Microsoft Corporation

.

Relevant Pages

  • Re: content filtering
    ... opinion on experience that's limited to dealing with domestic US ... Considering that the large majority of spam originates from the US, ... Now all you need is some method of identifying the sender. ... 550 code would come to the attention of the mail server admin who could ...
    (microsoft.public.exchange.admin)
  • Re: Returning an email to its sender. Is that possible?
    ... How do you know the sender used their own e-mail address? ... will notice the sending mail server DURING the mail session. ... Fake bounces are tantamount to vigilantism. ...
    (microsoft.public.outlook.general)
  • Re: Outlook Express Undeliverable
    ... If your client is not getting an NDR message back from ... his mail server (which means his sending mail server got rejected during the ... Maybe you have server-side spam filtering enabled and his mails ... sender is infected so his mails could also be infected. ...
    (microsoft.public.internet.mail)
  • Re: hotmail password request tool (intranet usage)
    ... that some email viruses started sending themselves as passworded files. ... I personally consider it bad practice for a mail server to alter the ... It also fails to inform the *sender* ... language has no way to express 'partial delivery'. ...
    (comp.security.firewalls)
  • [Full-Disclosure] Re: Multiple buffer overflows exist in Mercury/32, v4.01a, Dec 8 2003.
    ... > There are 14 vulnerable commands that can be used to cause buffer ... author of both Merucry Mail server and Pegasus Mail has aknowledge ... please be sure to advise David Harris. ...
    (Full-Disclosure)