Re: Bug #65934: rcvdist runs afoul of gmail DMARC/DKIM/ARC policies

[Ken Hornstein]

>The recent bug report, Bug #65934: rcvdist runs afoul of gmail
>DMARC/DKIM/ARC policies, could use some discussion here, I believe.
>
>Here are the contents of the bug
>(https://savannah.nongnu.org/bugs/?65934):
>
>    I have been using slocal and rcvdist for many years to forward
>    filtered mail to a private gmail address.  But their recent
>    enforcement of DKIM/DMARC policies is causing many (most?) such
>    messages to be bounced, since my SMTP server doesn't match the From:
>    address in the message.  I regard this behavior as a feature of
>    rcvdist, since the incoming message appears to be from the original
>    sender.  But I acknowledge that this use case is not easy to
>    distinguish from spam.
>
>    Is there a workaround here?  Perhaps a switch (or user customization
>    via rcvdistcomps) to allow a modified from line along the lines of
>    "Original Sender <local address>"?  Or is rcvdist no longer the
>    right tool for this purpose?

Oh, hm, what a great question.  I hope the creator of this bug is on
nmh-workers and can chime in.  However ... I'm not sure there's a
wonderful answer, although maybe it's possible with some (possibly
a lot of) work.

As I understand it from this bug report, the message flow is:

- User gets email from "person@internet" to their nmh mailbox ("user@nmh"),
  presumably with a From: header field of "person@internet".
- rcvdist dist(1)s that email to "privategmail@gmail.com".  So the email
  has these headers:

  Resent-From: user@nmh
  Resent-To: privategmail@gmail.com
  From: person@internet
  To: user@nmh

- Gmail rejects this based on From: person@internet (maybe?)

Now, due to general lack of feedback on SPAM filtering, it might not be
possible to determine exactly why it fails.  At first glance SPF
SHOULDN'T be affected because that works on the SMTP Mail From and
in theory post(8) with the -dist flag would take the SMTP envelope
from Resent-From so that should be correct.  But maybe you're one of
those people against all advice who use "mts: sendmail/pipe" in
your mts.conf file.  In that case I'm not really sure what your
SMTP envelope is going to end up being; that might be problem one.

A quick perusal of my email shows DKIM signatures that include
Rsent-From, Resent-To, and Resent-Date and rcvdist modifies those
headers so that would break a DKIM signature, so that's possibly another
place where things break.  If your local email provider does produce
their own DKIM signature headers then in theory at least one of the
signatures in the message headers would be valid and that should
solve that problem, but again we don't know anything about your
email setup.

Another issue is depending on the DMARC DNS record, the non-working
domains might specify a strict SPF alignment check, which means that
your SMTP envelope should "align" with the email From: header field.
Again, the details there matter; if the alignment is "strict" the
domains have to match exactly, and what those end up as depends
entirely on the details of your email configuration.

It might be interesting to have example domains that succeed and
fail in that setup so we could query them and see what the relevant
DKIM/DMARC/SPF DNS records are; that was why I am hoping the creator of
that bug report is willing to chime in.

Now, first off ... what, exactly, are you trying to accomplish with this
setup?  I ask because while in a perfect world this should work just
fine and you wouldn't need to change anything, unfortunately in 2024
that isn't the reality we live in and no amount of screaming into the
void will change that.  So I'm wondering WHY you do this: do you want to
read those messages on your phone and you never reply?  Do you want to
do something else with them on your private Gmail account?  Are you just
using Google as a last-ditch backup mechanism?  The answers here kind of
depend on your goal.

Now, as to SOLUTIONS ... well, there aren't wonderful answers.  But
here are some general thoughts:

- If you want to perform some surgery on the original message to the
  point where it's not easy to reply to it from gmail, you could:

  - Strip off all DKIM/DMARC/ARC headers
  - Change the From: header field to point to something in your email
    domain.

  You should be able to accomplish this with anno(1) and some shell
  scripting.  That should get the contents of the email onto Gmail
  where you can at least read it.

- Do the right magic to forward the message along.  Ralph brings up
  ARC, but my understanding is that isn't quite enough.  You're going
  to need DKIM, SRS, _and_ ARC, at least according to this post:

  
https://serverfault.com/questions/949620/gmail-rejects-forwarded-mail-with-dmarc-but-i-am-using-srs

  That references this post which has more details (a lot of it is
  postfix-specific but it gives you an idea of what you need to do):

  
https://forum.howtoforge.com/threads/postfix-rspamd-do-not-dkim-sign-forwarded-messages-solved.87742/

  There are a lot of details there, and it's complicated but should work.
  But ... some of this (DKIM at least) requires control over your own
  DNS records.  Maybe you have that!  If you use a commercial email
  provider and they DON'T do DKIM, unfortunately I do not think you
  can use ARC (but I could be wrong).  In terms of software, there
  is already a lot of code that implements DKIM and ARC, so at least
  you don't have to roll that yourself.

So you see that the details here matter a LOT, that's why it would be
helpful to understand your ultimate goal.

--Ken