On 9/2/20 6:33 AM, Douglas E. Foster wrote:
> For mailing lists, we have pushed the limits of authorization.   But there is 
> another class of problems where sender authorization is not feasible:   mail 
> which is auto-forwarded after a spam-filter has made content-altering changes.

Yes, this is an increasing problem, as exemplified by the number of enterprises 
that have started tagging subjects and bodies with [External] warnings.  
Coupled with DMARC adoption, the ability for users to auto-forward successfully 
is shrinking.  

I realize that John's message in the other thread probably wasn't referencing 
auto-forwarding, but I think his point dovetails to the auto-forwarding issue:

> As always, as I hope we all remember DMARC alignment doesn't mean not spam,
> and you still do all of the stuff you do to sort your mail.  This scheme
> depends on the forwarders you authorize being well-behaved.  That's why I
> am concerned that senders need to be selective about who they allow to
> forward.

I am concerned with:

a) It assumes that the domain owner has the ability and desire to authorize 
every potential forwarder, even though auto-forwarding is a user-level decision.

b) It assumes that all potential forwarders check for authorization before 
forwarding -- essentially the same problem with the way most ESPs will use a 
domain in the From header without checking for authorization via DMARC.

c) Selectively allowing forwarding at the user level is difficult because users 
are gonna do what they wanna do (you try telling faculty they can't forward).  
It's not the case that all enterprises want to prohibit all of their users from 
auto-forwarding (even though that's the answer you may get if you survey the 
CISO community)
     
d) Selectively forwarding based on the knowledge of whether the forwarded 
message will reach the destination is challenging because the intermediary 
doesn't really know if it will succeed, and selectively forwarding in this way 
will lead to the user only seeing a subset of their messages being forwarded.  
This is essentially what's happening today (see my first sentence in this 
message), and I know users who are still bound and determined to auto-forward 
and they have just resigned themselves to the fact that they have to 
periodically check the intermediary mailbox for all of the messages that didn't 
survive the forward.


> In the absence of such techniques, the forwarding system (or the outbound 
> gateway) needs to be aware that a message has been forwarded after 
> content-altering changes.   When this is the case, the message either 
> requires a known exception at the receiving system or a From address rewrite 
> so the message will pass DMARC.   At minimum, our DMARC specification should 
> make this clear.

I agree with this, however, I'm increasingly of the mindset that since this is 
a user-level issue, we should be thinking about solving it via OAuth 
mechanisms.  Modern email services do support the ability to fetch from a 
mailbox, authorized via OAuth, so it might be easier to convince the downstream 
mailbox providers to enhance their fetching mechanisms to support the features 
that people expect of inbound mail (i.e. apply inbound filtering rules).  The 
mailbox provider would still need a way to determine the original DMARC 
results, spam analysis, etc, but wouldn't that be easier to implement since the 
message is "frozen in time" and wasn't subjected to the altering changes 
implied by forwarding?

Jesse

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to