1) Yes, via two methods - The first is mailbox aggregation (why setup forwarding when I can just read the mailbox for you?) which is currently supported by a number of email providers. The second is via Authenticated Received Chain (ARC - see http://arc-spec.org/). Also currently supported by a number of email providers. 2) Yes, but because it requires potentially significant user and provider work, it's not really seen as a preferred solution. It also doesn't solve many other issues that forwarding (and things like Lists) have with DMARC. ARC should be able to solve these problems without requiring user work/effort - it will however require provider effort, but most of the major providers and several large FOSS mail packages/libraries already have implemented or have committed to implementing ARC. See http://arc-spec.org/ for the current state of things.
On Mon, May 21, 2018 at 11:29 AM, Pete Holzmann via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > I'm seeing a growing number of bounce-back errors from major players who > have DMARC fully implemented. > > I have some observations, questions and a suggestion. > > Blessings, > Pete > > *OBSERVATIONS* > > There's a pattern here that I suspect is only going to grow: > > * User R with SomeCo creates an email filter rule to auto-forward some > subset of incoming emails to their smart phone or other alternate mailbox > (gmail, apple, etc) > > * From 'R's perspective, they simply want those emails to show up in their > "other inbox" > > * From Google/Apple/etc perspective, those emails get the full treatment > for: > - SPF/DKIM/DMARC validity > - Anti-spam filtering > - Etc. > > The result (with varying details): > > a) Originator "O" of the email may get a DMARC bounceback (see example > below) indicating that gmail (or whoever) would not accept the message. > b) User "R" with the forwarding rule may find messages not showing up on > their phone. > c) Google/Apple/etc may start treating SomeCo as a source of spam > > ...and the hard part: from Originator and User perspective, everybody's > doing what is "normal" but the email systems are causing grief. Only an > expert examining headers and server logs can get a clue about what is > happening. > > In a perfect world all software will perfectly implement DMARC. In the > meantime, users get frustrated and email gets blocked. > > *QUESTIONS:* > 1) Is anyone working to solve these issues? > 2) Has there been consideration of a forwarding token that could validate > all such emails? > > *SUGGESTION: * > a) Since user+al...@dom.ain is a valid alias for u...@dom.ain ... > b) Why not create a standard for personal forwarding authentication > tokens? I.e. > * A typical mechanism is used to create token asd!_4521Zxy > * asd!_4521Zxy is stored as PrivateForwardToken in gmail box or > ??? > * User forwards their email to user+asd!_4521...@gmail.com > instead of > u...@gmail.com > * Google auto-approves all such email as if it were internal > rather than > externally sourced. > > [Probably needs modifying so such messages are rapidly recognized during > transport... but I want to make sure end users can easily implement this on > ANY email client, ANY email service, without help.] > > > *EXAMPLE* > > I sent email to a friend. I received this bounceback. I was surprised to > hear that my friend received the message... until on questioning he > realized he also was auto-copying to a gmail box. > > > Sorry. Your message could not be delivered to: > > gmail.com > DATA > Received: 5.7.1 Unauthenticated email from icta.net is > not accepted due to domain's > 5.7.1 DMARC policy. Please contact > the administrator of icta.net domain if > 5.7.1 this was a legitimate mail. > Please visit > 5.7.1 https://support.google.com/ > mail/answer/2451690 to learn about the > 5.7.1 DMARC initiative. > s4-v6si8436056ita.127 - gsmtp > > [end] > > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) > -- PAUL ROCK *Sr Software Dev Engineer* | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
