[dmarc-discuss] How does *this* mailing list interact with dmarc?

Brian Corrigan bcorrigan at majorleaguegaming.com
Wed Jun 20 14:04:17 PDT 2012

I'm new to the list and personally I'm finding this pretty
interesting.  It would be nice if there was a way to address this, as
its obviously a common use case and for most people, separating users
from transactional messages isn't going to be practical and as John
mentioned, list participation (and the like) is very common.

Can someone make sure I understand this right?  I think the problem is:

* Assuming a forwarder preserves a DKIM header, and adds its own, a
receiver should be able to perform a valid check on both the sender
and the intermediary (and it would pass).

*  However, because SPF wouldn't include the intermediary, the SPF
check would fail.

Do I have it?


On Wed, Jun 20, 2012 at 4:07 PM, Derek Diget
<derek.diget+dmarc-discuss at wmich.edu> wrote:
> On Jun 20, 2012 at 18:50 -0000, Franck Martin wrote:
> =>It is notorious that people having a .edu email address use a lot
> =>forwarding, and that systems break DKIM in the process...
> =>
> =>http://www.it.cornell.edu/services/cmail/howto/spoof.cfm
> We don't allow forwarding[1] of email for our 40,000 users
> (faculty/staff/students).  We also don't offer POP.  We offer webmail
> over SSL, IMAP over an encrypted connection (no POP) and SUBMIT over an
> AUTH/encrypted connection.
> If we did forwarding our mail routing layer would do SRS.  It has been
> talked about for emeriti/alumni only.  Also, we would probably resign
> DKIM messages with our own signature.  I have not really looked into
> DKIM that much once I found out how many failures we see.  Insert long
> story about the MTA author and his history with MIME and fixing messages
> to comply with RFCs.  It was also when we would be evaluating the DKIM
> signature after the message was accepted and "fixed-up".  Now we
> would do the evaluation during the SMTP transaction, fix-up the message,
> and then sign.
> We do see a decent number of SPF FAIL because of forwarding.  We are
> currently quarantining those messages, but as we move to a
> "non-quarantine" configuration, we will be rejecting them.  (We tell our
> users's to stop using the forwarding address and have the messages sent
> directly to their Western account.)  Who are we to question if a
> forwarded paypal, stubhub, facebook, etc message is legitimate?  The
> domain owner says the message shouldn't be coming from the forwarded
> system.  We follow what the domain owner had published.  We don't want
> to be accessories in a forgery case.  Note our user's don't get to
> white-list SPF FAIL as, again, the sending domain has not given them that
> authority.
> Now that I have go way off topic....follow-ups should probably should be
> taken off list.
> Note 1: Via a setting/preference in mail routing layer or server-side
> filter.  Users can of course "forward" via their mail client button.
> --
> ***********************************************************************
> Derek Diget                            Office of Information Technology
> Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
> ***********************************************************************
> _______________________________________________
> dmarc-discuss mailing list
> dmarc-discuss at 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)

More information about the dmarc-discuss mailing list