der Mouse:
[...]I think the question we need to be asking is "is this, however
widespread and however longstanding, something we will ultimately be
forced to give up?". If the answer is "no", we should try to find
antispam tactics that preserve it. If the answer is "yes", we should
mentally give up on it now and figure out how to best manage the
(inevitable, in that case) transition.
I'm not convinced of either "yes" or "no" at this point.
Maybe what you're looking for is some kind of cost/benefit thing. Would the
(wider) benefits of a given Antispam Tactic outweigh costs, including the
new costs incurred by users of some Traditional MTS Feature? Why would
users choose to change?
The main value of the forwarding objections, I suspect, is that they tend
to invalidate the assumption that a sender can make true assertions about
the path their messages will follow. Just can't be done - as things stand.
From the openSPF site:
"I only send mail from these machines. If any other machine claims that I'm
sending mail from there, they're lying."
Who is this "I" ? is it a person? or the entity controlling the domain? And
what's "mail"? is it a SMTP transaction? or a message? Is it the actual
import of the communication? And what exactly does "from" mean here?
It's not so much that SPF breaks forwarding, or that SRS is dangerous (it
isn't) but that forwarding makes it difficult for the "I" to make this kind
of assertion. We get into the situation where "I" didn't send mail "from"
the forwarder (in a particular sense - the mail is sent on by an agent
acting for the recipient) but we can show that the message received at the
far end is essentially identical to the message "I" sent, and is being read
by the person "I" intended to receive it. Can "I" justly call the forwarder
a liar for claiming that "I" sent the "mail"?
And anyway, why do we care about sender policy? Shouldn't we be concerned
with recipient policy? [Mourns 'consent']
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg