On Sat, Jan 05, 2008 at 09:47:37AM -0700, Edmig wrote:
If the HELO name ends in the domain of the return address, assume no
forwarding, and reject on SPF fail. If not, assume forwarding, and
don't use SPF.
HELO name (e.g. "mailhost.provider.example")
return address (e.g. "info(_at_)client1(_dot_)example")
This is *not* forwarding. I wrote an example where mail originates at
provider.example thus is initially sent by provider.example
The assumption you make does not work.
I was talking about forwarders on the receiver's side. For the case you
suggest, where the forwarder has a contractual relationship with the
original sender, the forwarder should make sure he is explicitly authorized
by the sender.
I was *not* talking about forwarders.
There is *no* simple rule which says that a sending host's name
has to match the sender's email address.
But it does have to correlate with the IP address used by the sending host.
Which raises the question again - why not just use the HELO name to
authenticate an incoming IP address?
uplink-01-xyz.somecarrier.example. A 10.1.2.3
ge5-3-2.othercarrier.example. A 172.16.1.2
mailhost.provider.example. A 192.168.1.1
internal.provider.example. A 192.168.2.1
external.provider.example. A 192.168.3.1
Which of these names is *the* fully qualified principle hostname?
Which of these addresses is connecting to your mailhost?
Yes, "mailhost.provider.example" could have 5 A RR's, but what if
this leads to undesired results? Perhaps I don't want all addresses
to be tried when someone connects to mailhost?
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=82179650-b39dbe
Powered by Listbox: http://www.listbox.com