Mailing List Archive

Mark,

Keep in mind what happens in the transfer of an email. I'll strip it down to the important part:

Email comes into destination server. The destination server sees that the email claims to be from joe@domain.com. The server knows that the email came from IP address 1.2.3.4.

When the destination server knows these two pieces of information, <email address> and <IP address>, it looks up the SPF record for the domain part of <email address> (in this case "domain.com"). Let's say that the SPF record for domain.com is "v=spf1 ptr -all". In this case, the server next does a PTR lookup on 1.2.3.4. Now, let's assume that the result is 'mail.domain.com'. Finally, the server does a DNS lookup on 'mail.domain.com' and IF the result is 1.2.3.4, then the lookup passes. If you check out the actual design document at http://spf.pobox.com/draft-ietf-marid-protocol-00.txt and look at the section 4.5 on PTR, it says that this is a LAST RESORT, because it is so DNS intensive. To quote:
> Note: This mechanism represents a burden on the reverse DNS tree.
> Therefore, it should be used only as a last resort, if domain policy
> cannot be expressed using alternative mechanisms. If a domain
> decides to use it, it should ensure it has the proper PTR records in
> place for its hosts.

It may seem like a lot of lookups to use PTR, but keep in mind that if anyisp.com has a block of IP addresses, that ISP has complete freedom to define the PTR/ReverseDNS responses for those IP addresses. Let's say that they have IP address 5.6.7.8 and they are sending out an email also claiming to be from 'joe@domain.com'. The email server looks up the SPF record for domain.com, finds the 'ptr' directive and does a reverse lookup on 5.6.7.8. Now let's assume that the ISP has 5.6.7.8 PTR = mail.domain.com (forged!). This is why the server does the final lookup. mail.domain.com = 1.2.3.4, so the PTR FAILS!

Hope that helped....

Marc Alaia
>
> From: "Mark Smith" <spf@ms.cx>
> Date: 2004/08/04 Wed PM 06:28:55 EDT
> To: <spf-help@v2.listbox.com>
> Subject: [spf-help] Ptr mechanism
>
> According to the SPF Setup Wizard, the ptr mechanism means "Any server whose
> name ends in domain.com is allowed to send mail from domain.com."
>
> This implies that when email is received from mail.domain.com, the SPF
> record for domain.com is looked up, and the querying agent is told that mail
> is allowed to be sent from mail.domain.com.
>
> This is not what happens - instead, the SPF record for mail.domain.com is
> looked up.
>
> So what does the explanation in the Wizard actually mean?
>
>
>
> -------
> Archives at http://archives.listbox.com/spf-help/current/
> Donate! http://spf.pobox.com/donations.html
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com
>

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com

Mark Smith wrote:

> So what does the explanation in the Wizard actually mean?

Let's say you get MAIL FROM:<user@example.com> and IP 1.2.3.4.

The sender policy for example.com says "v=spf1 ptr -all".

You'd then match all names for IP 1.2.3.4 against *.example.com

If one of these names is e.g. adsl-4-3-2-1.example.com, and if
the IP of adsl-4-3-2-1.example.com is really 1.2.3.4, then you
have a match and a PASS. Here's another example extracted from
draft-ietf-marid-protocol-00.txt appendix B:

| $ORIGIN example.com.
[...]
| amy A 192.0.2.65
| bob A 192.0.2.66
[...]
| $ORIGIN example.org
[...]
| mail-c A 192.0.2.140
[...]
| $ORIGIN 2.0.192.in-addr.arpa.
[...]
| 65 PTR amy.example.com.
| 66 PTR bob.example.com.
[...]
| 140 PTR mail-c.example.org.
[...]
| ; A rogue reverse IP domain that claims to be
| ; something it's not
| $ORIGIN 0.0.10.in-addr.arpa.
| 4 PTR bob.example.com.
[...]
| v=spf1 ptr -all
| -- sending host 192.0.2.65 passes
| (reverse IP is valid and in example.com)
| -- sending host 192.0.2.140 fails
| (reverse IP is valid, but not in example.com)
| -- sending host 10.0.0.4 fails
| (reverse IP is not valid)

192.0.2.65 has the name amy.example.com, and amy.example.com
has really this IP => match example.com and PASS

192.0.2.140 has the name mail-c.example.org and this is really
192.0.2.140, but mail-c.example.org doesn't match example.com,
therefore only -all matches resulting in a FAIL

10.0.0.4 claims to have the name bob.example.com, this would
match, but bob.example.com has IP 192.0.2.66 and not 10.0.0.4,
therefore you get a match later for -all (FAIL) instead of ptr.

Bye, Frank


-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com

On Wed, Aug 04, 2004 at 11:28:55PM +0100, Mark Smith wrote:
> According to the SPF Setup Wizard, the ptr mechanism means "Any server whose
> name ends in domain.com is allowed to send mail from domain.com."
>
> This implies that when email is received from mail.domain.com, the SPF
> record for domain.com is looked up, and the querying agent is told that mail
> is allowed to be sent from mail.domain.com.
>
> This is not what happens - instead, the SPF record for mail.domain.com is
> looked up.
>
> So what does the explanation in the Wizard actually mean?

http://spf.pobox.com/mechanisms.html#ptr

If you send mail fro mail.domain.com, it _will_ lookup the spf record
for mail.domain.com, nothing else. It then processes this spf record. If
it encounters PTR, it will do a PTR lookup of the connecting IP, and see
if any of the returned domain names end in mail.domain.com.

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com