Douglas Otis wrote:
Due to the macro nature of SPF, full processing is required for
each name evaluated.
If what you call "full processing" is the procedure to fetch the
policy record of the domain in question, and match the connecting
IP against this policy for a PASS / FAIL / "DUNNO" verdict, then
this doesn't depend on using macros or not in the policy.
Maybe you mean that macros can reduce the chances for a DNS cache
hit, e.g. for per-user-policies based on the local part macro.
With SPF, the recipient might be interested in the PRA, or MAIL
FROM.
When I talk about SPF it's generally RFC 4408, i.e. MAIL FROM and
HELO, not the Sender-ID PRA. The PRA doesn't necessarily help to
identify a permitted or forged MAIL FROM. In other words the PRA
or FWIW DKIM are not designed to avoid backscatter.
when an SPF hammer is the only tool
Folks didn't like the idea to reintroduce RFC 821 return routes ;-)
Of course receivers are free to use any tool to avoid backscatter,
but SPF is today the only tool designed for this job.
Cleaning up how DSNs are constructed would be _far_ more effective
than asking that all DSNs be dropped when SPF does not produce a
PASS.
No. When I was the victim (back in 2004 before SPF started to work)
the _size_ of DSNs and other backscatter wasn't the main issue, the
_number_ of bogus auto replies was the real problem.
JFTR, "not PASS" can be FAIL or "DUNNO". FAILs should be rejected.
Your idea to abuse DSNs for indirect spam or malware delivery is a
valid consideration, but in practice the volume of all backscatter
not limited to DSNs is the real problem.
Limiting the size of DSNs is okay, but it's not "far more effective"
than "reject a.s.a.p.", in fact it misses the point wrt backscatter.
Perhaps that is why Bell Canada ensures all addresses achieve
a PASS. : (
Oops, bell.ca still has this ridiculous policy, that certainly won't
help them to reduce backscatter.
Auto responders aren't in a good position to verify the validity
of the return path. Good positions to do this are the MSA based
on RFC 4409 and later the MX based on RFC 4408.
RFC4408 did not mitigate a potential DDoS exploit. This exploit
exists when recipients attempt to process SPF as specified.
Actually they've to ignore a SHOULD in the security considerations
of RFC 4408 if they wish to participate in your convoluted attack
scenario. And the SPF RFC did mitigate this potential with several
MUSTs in the security considerations in comparison with pre-MARID
drafts.
Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf