> > Calendar invites are a special case which requires a task-specific > solution. > > The larger problem is with forwarding. Forwarders want a way to reliably > identify themselves so that their forwarded traffic is given a favorable > reputation. Authentication based on the “Sender” header is one variant on > this objective. The theoretical obstacles to this goal are substantial. > > For a general solution, we must assume that the forwarder receives a > message stream which includes both wanted and unwanted messages. We can > also assume that the forwarding organization and the final recipient > organization have different spam filtering rules. > > If the filtering rules of the forwarding organization are stricter than > the receiving organization, then the recipient will miss some messages that > should actually be delivered, leaving both originator and recipient feeling > unhappy with the forwarder. In the general case, this incents the > forwarding organization to have relatively weak filtering rules. > > In the more likely case that the filtering rules of the forwarding > organization are weaker than the recipient organization, then the > forwarding organization will accrue a reputation as unreliable, the source > of some spam. > > Additionally, the process of forwarding hinders the ability of the > recipient organization to filter based on the actual sender. The process > of forwarding hides the message source behind the forwarder identity, > obscuring information that would have been used to evaluate the message if > it had been sent directly. Consequently, we have a message source that is > known to send some spam, combined with insufficient tools for > distinguishing between trusted and malicious originators. > > To solve these problems, a forwarded message will need to be evaluated > using both the forwarder identities and the originator identities. That > process will require scanning the entire header structure, particularly the > entire Received chain, which should then be correlated with any changes > made to the RFC5321.MailFrom address or RFC5322.From address. My opinion > is that the current header structure lacks the identifiers necessary to do > this correlation, even if the submitting servers are eager to supply > whatever is desired. > > The trust problems are aggravated by the inability to verify the accuracy > of the Received header, SRS rewrites, or mailing list modifications. If > recipients begin using unverifiable header elments for whitelisting, then > spammers have an incentive to construct fraudulent header elements. If > recipients only use this information for blacklisting, then the needs of > forwarders have not been sufficiently satisfied. > > Therefore, I conclude that forwarders will always be dependent on > recipient organizations who are willing to create local policies to handle > the traffic from a trusted forwarder differently than traffic from an > unrecognized > forwarder or unforwarded messages from sources with authentication FAIL. > >
> >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
