Re: [dmarc-ietf] Sender vs From Addresses

[Douglas Foster <[e-mail]>]

>
> 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.
>
>

>
>