Re: spf entries for which hosts ???

Margrit,

Welcome to the list.  I am just another member on this list, but will try 
to offer what I can, deferring to those who have lived with SPF far longer 
than I.  If I have grossly erred, I welcome corrections.  I also have a 
question included below for other members on the list regarding the 
usefulness of a new syntax option targeted to AV plug in software vendors 
and those who might also choose to implement the syntax element in their 
MTA software.
Margrit, as you understand from your attached, MX records are published in 
DNS Zone files for a domain and they guide other MTAs to the location of 
MTA(s) handling email service for a target domain.
SPF provides a vehicle to send information back to an SPF enabled MTA via 
DNS TXT records which are located in the DNS Zone file for a domain.  The 
SPF TXT record provides any SPF enabled MTA servers information on which 
MTA(s) the domain owners are announcing should send email.  The receiving 
MTA can check the incoming message's claimed header "FROM" domain against 
the actual domain's published DNS based SPF TXT record.  In this way the 
receiving MTA can validate the source of the message sender by examining 
message "FROM" domain and comparing that to information in the SPF record 
which the domain's owners publish.
If the data validates, the message did come from the domain's claimed 
outbound MTAs.  Was the message sent a spam?  Who knows, that is not being 
checked for here.
Alternatively, if the data does not validate, we know that the sender of 
the message is using a "FROM" domain from a specific place that is not in 
the domain owner's published list of outbound MTAs for that domain.  Was it 
spam?  Again, we really don't know that for sure, but we certainly do know 
minimally that the source of the message sender checked against the domain 
owner's DNS SPF TXT record does not match that which the domain owners 
allow for sending email from their domain.  So, when this happens, the 
message should be rejected for delivery in some way because the check failed.
FOR OTHER LIST MEMBERS: I am interested in knowing if some of the AV plug 
in vendors also have plans for direct support of SPF.  I ask because such 
support should make SPF deployment and acceptance at the MTA level 
easier.  If so, could we consider adding a switch which might cause said AV 
plug in software to either send or not send a message back to the domain 
owner regarding the misuse of their name by another party?  While it is the 
purpose of SPF to stop the domain name from being misused, it might also be 
useful for evidence gathering purposes to have data points documenting 
misuse when gathering evidence for any other actions a domain owner might 
want bring against individual(s) attempting to misuse their domain name in 
email spam.  A switch mechanism here makes it easy for a domain owner to 
decide on how they might choose to actively learn of or not learn of such 
identity theft events taking place.  With something like the "v=spf1 -ALL" 
syntax, the AV plug in would presume that the owner wants confirmation of 
abuse as opposed to "v=spf1 NOCONFIRM -ALL" were they would not.  Perhaps 
the attorneys on this list might want to comment on the usefulness of or 
logic error being made in implementing this as regards evidence gathering 
procedures.  Any thoughts on this would be appreciated.
In any case, getting back to Margrit's question, just like MX records, it 
is through the information you publish in a specially formatted DNS based 
TXT record that this processing can take place.
I believe that the TXT record was chosen because it is a logical choice, 
allowing people to quickly publish SPF records for their domain(s).  This 
is true because I think that all DNS RFC compliant servers since the 
earliest days support the RR for TXT records, thereby eliminating any 
potential RR incompatibility issues among DNS servers that might occur with 
the introduction of a new RR type.   The logical step forward from this 
mode of publishing is to migrate to an SPF DNS RR record, but that is not 
the case today.  Today we use a specially formatted DNS based TXT record to 
publish an SPF record for a domain.
An syntax example for one of the simplest SPF records you might publish 
could look like this:
example.com.  IN TXT "v=spf1 -A"

The above means that no mail should ever come from example.com, so a 
receiving MTA which checks for SPF records should realize the owners don't 
publish email and therefore any message it receives claiming to be from 
example.com should not be delivered because no outbound MTA information for 
example.com was published in the SPF record.
You should visit the RFC at 
http://spf.pobox.com/draft-ietf-marid-protocol-00.txt to really learn about 
all of the syntax possibilities - this too is still being matured, but it 
is a great guide.  Keep in mind as you read that any examples of syntax not 
explicitly shown in TXT records for readability and focus sake actually are 
contained in DNS based TXT records in a zone file for a domain - so for 
example on page 10 of the above referenced -
v=spf1 +mx +a -all

must be contained in a zone file TXT record, perhaps looking more like this 
in your zone file -
example.com IN TXT="v=spf1 +mx +a -all"

As zone files themselves may have different syntax constructs associated 
with them in different DNS service software vendor implementations, keeping 
DNS zone syntax out of specific SPF syntax examples allows the focus to 
remain on the SPF syntax.
As Koln mentioned, there is much available from http://SPF.POBOX.COM/ for 
you to review.  Take some time to do so and it should become clearer how 
all of the syntax options behave and how to best implement them in your 
environment.
Hope this helped you a bit more.  Good luck.

Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/


At 03:25 AM 10/11/2004, you wrote:
> We are interested in SPF.
> I'm the postmaster from our university.
>
> We're working with a number of virtual domains
>      uni-magdeburg.de      for functional addresses
>      urz.uni-magdeburg.de  compute centre
>      mathematik.uni-magdeburg.de mathematics
>      ...
> (in the DNS there are MX records that control smtp transfer
>  to that domains to our mailrelay servers (exim MTA)
>
> There are also a number of smtp servers that send/receive
> emails to/from that mailrelay servers.
>
> If there are following servers
>
>   server1.urz.uni-magdeburg.de
>   server2.et.uni-magdeburg.de
>   server3.math.uni-magdeburg.de
>
> that can send emails with the domain part urz.uni-magdeburg.de
> ...
>
> Which spf entries I have to write for server1,server2,server3 ???
>
>
> --
> Mit freundlichen Gruessen
> M.Lottmann
>
>  Otto - von - Guericke  Universitaet      __  __   ____ _____         _   __
>                Magdeburg                 / / / /  / __ \__  /        / | / /
>  ------------------------------------   / / / /  / /_/ / / / ______ /  |/ /
>            Margrit Lottmann            / /_/ /  / _, _/ / /_______// /|  /
>        Universitaetsrechenzentrum      \____/  /_/ |_| /____/     /_/ |_/
>          Netze & Kommunikation
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta 
> features SPF and Sender ID.
> To unsubscribe, change your address, or temporarily deactivate your 
> subscription,
> please go to 
> http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com