Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
John Leslie wrote:
Fundamentally, of course, the attempt to have one-size-fits-all
processing by the receiving MTA is dubious. It's not the coding of
SPF records that breaks forwarding: it's the processing of them.
Relaxing the processing rules could help a lot.
Would you please expand on that? Relaxing rules implies the knowledge
that a message is being forwarded. Are you talking about whitelisting
well known forwarders, or what?
I was intentionally vague...
However, there are a limited number of ways that forwarding might be
shown in the trace headers, so it should be practical to determine that
a forwarding is documented (though possibly forged).
We then have a quite different situation from what raw SPF processing
would indicate. Thus I claim the rules deserve to be relaxed (without
going into detail how).
Forging headers to indicate forwarding which didn't happen indicates
evil intent, and should be practical to block-list like other spamming
IPs. Well-known forwarders could be whitelisted, enabling us to trust
their pre-forwarding headers. Et cetera...
And I see promise in the use of the pending Authentication-Results
header (though I must agree with Doug Otis that it would be stronger
if it included the IP address).
Hm... the header's name suggests it is reporting already acquired
results, as had been noted. I'm surprised Doug didn't propose an
additional test more in tune with that spirit, e.g.
Authentication-Results: example.com;
dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3
I'll let Doug speak for himself. I didn't propose such a thing
because I believe arguing over extensions would detract from getting
the basic header adopted.
(I do believe that adding a resinfo listing the IP address is a
practical way to deal with SPF's choice to omit it from their resinfo.)
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg