Stuart D. Gathman wrote:
AOL is a poster child for why the canard about how SPF "breaks forwarding"
is complete FUD. *Any* system that blocks the sources of spam
"breaks forwarding". And that is as it should be. Alias forwarding
is broken, SPF or no SPF.
It can only work when specifically configured by the receiver as well as
Thus far, we have located a few ways to aid that task:
* whitelisting by MTA-specific (IP-based?) settings,
* the AUTH Parameter to the MAIL FROM command,
* SPF "i-am=" or similar modifiers in the DNS record.
David MacQuigg wrote:
Well, using our new terminology, we should be able to simplify this discussion.
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA -->
Border (Stuart) (aol.com)
I'm not sure aol.com should be labeled "MDA". In addition,
there is a second border after the Forwarder(s). The latter
is what makes it difficult for the receiver to reuse spam
knowledge gathered by the recipient.
Why is that forwarding different from secondary MX transfer?
(The last time I had a secondary MX it was on a different ADMD
in order to be on a different network --that way, I did once
receive a notification that my network was unreachable.)
Currently, I have no secondary MX in order to avoid those
difficulties. Besides unlisting/nolisting tricks, I guess that
is the current best practice about secondary MXes. Isn't it?
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com