On Fri, Jun 18, 2004 at 01:42:21PM -0400, John Glube wrote:
|
| Otherwise you could end up with a situation where
| the vast majority of senders are using method X,
| but some receivers insist on method Y, meaning
| senders are compelled to add method Y if the
| sender wants delivery to those receivers.
I see it more as "interpretations X, Y, and Z are all valid
given the input data."
People who need a refresher on the MARID proposals are
welcome to look at http://spf.pobox.com/marid/
| Can you perhaps elaborate further on this point,
| so we can better understand your vision of how
| this will all come together?
Use Case 1: one box
Example.com is a domain with a single machine.
example.com A 192.0.2.1
192.0.2.1 PTR example.com
It sends mail with
HELO example.com
MAIL FROM:<user(_at_)example(_dot_)com>
From: <user(_at_)example(_dot_)com>
Unified SPF asks example.com to publish one SPF record:
example.com TXT "v=spf1 a -all"
This SPF record is meaningful for all of the following:
1 the PTR lookup (MTAMark / SS)
2 the HELO name (CSV / DRIP / DHVP)
3 the MAIL FROM (SPF Classic, DMP, RMX)
4 the header From: (CallerID's PRA)
For the "am I MTA or Not?" semantics represented by MTAMark
and SS,
Start with the client IP address.
Turn the client IP address into a domain name using PTR.
SPF query the PTR domain name.
Pass means "the network owner declares this IP is an MTA
on the internet."
Fail means "in a stricter world the network owner might
even block outbound port 25 for this IP".
For the HELO semantics represented by CSV,
Start with the HELO name.
SPF query the HELO domain name.
Pass means "192.0.2.1 is authorized to use the name
example.com".
Fail means it's not authorized, please reject the
connection.
Whitelisting can then operate on the basis of the HELO name.
For the MAIL FROM semantics, you get SPF Classic.
You make the policy decision on the basis of the MAIL FROM
address.
For the Purported Responsible Address, you get the
CallerID/SenderID semantics.
You make the policy decision based on the PRA.