On 10/7/11 4:56 PM, Frank Ellermann wrote:
On 8 October 2011 01:26, Scott Kitterman wrote:
The header field we are basing this on is called authentication
results. That ship already sailed.
Changing it to something else will be more confusing for everyone
!Doug.
-1
ACK. Besides RFC 4408 always uses the "correct term" for everyone
including Doug. His broken record^W^Wsuggestion to change "policy"
into "script" can be evaluated for 4008bis.
Nothing has changed. Bulk senders don't care about risks, just turning
a profit. But...
10 macro mechanisms x 10 resolutions per connection represents a hazard,
especially when confronting IPv4 in a growing IPv6 world. How can
defensive strategies deal with shared translation mechanisms without
causing significant disruption? Distributing the potential of SPF
derived transactions emitted by libraries applying script-like macro
expansions represent a real risk of enabling distributed denial of
services. The underlying mechanism of such attacks will be difficult to
identify and impossible to defend against, that can target any domain
not even present within the message.
Also too many forget SPF is _not_ an Authentication mechanism. SPF can
offer pass results unrelated to the source IP address also not captured
in Authentication-Results headers. Those making use of SPF need to be
repeatedly reminded of SPF limitations and risks. For example, SPF
selected by Mail From or PRA can not be used to validate receivers of
feedback.
Requiring DKIM headers not be redacted also provides spammers a sure
place to encode spamtrap locations. Another don't care for bulk senders.
Lack of SPF authentication and lack of sender/recipient information
applied against DKIM signatures means a system based on these two
protocols will make it impossible for smaller domains to receive
equitable treatment. Equitable treatment demands _all_ accountable
sources be authenticated as having sourced the message directed to a
recipient that considered it to be unsolicited and undesired. Larger
domains are naturally protected by complaints making them "too big to
block" and immune against reputation attacks.
-Doug
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
