Re: [exim] can't see email replies

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Mike Brudenell
Datum:  
To: Exim Users
Betreff: Re: [exim] can't see email replies
Hi, Phil et al -

Just for information, here at York we are working towards a DMARC policy of
at least "p=quarantine" for our york.ac.uk domain. Depending on its effect
we might in time continue on to try and move to "p=reject". We already have
"p=strict" for most of our (few) subdomains.

I know of at least two other UK universities working to implement a DMARC
policy, although I don't know what their intentions are regarding
quarantine/reject policy. I guess it's something we all — list users and
the list admins — need to keep mindful of as uptake continues.

I remember reading a somewhat brain-bending example somewhere of A sending
a message to B which then forwarded/distributed it on to C and the original
DKIM surviving: something to do with B's signature and what headers it
added/signed — possibly a Resent-from? — and because B had signed A's
DKIM-signature everything worked. Or something. Of course I can't find the
page now in my bookmarks! :-(

By the way, I confess I find it a little sad that the list doesn't
DKIM-sign its outgoing messages and neither is there even an SPF record for
the exim.org domain. What's the reason for not having either?

Cheers,
Mike B-)

On 1 February 2017 at 06:20, Phil Pennock <pdp@???> wrote:

> On 2017-01-31 at 22:09 -0600, Dan Liles wrote:
> > I'm having a problem with this list - for some reason I'm not seeing
> replies
> > to my answers in my inbox ( I have to look at the archive on the website
> ).
>
> You had replies from: James Lovejoy <jlovejoy@???>
>
> Gmail is rejecting those replies as they come through the @exim.org
> servers, because James has published a DMARC policy telling them to do
> so.
>
> % dig +short -t txt _dmarc.lovejoytech.com
> "v=DMARC1\;p=reject\;rua=mailto:admin@lovejoytech.com\;ruf=mailto:
> admin@???\;adkim=s\;aspf=s"
>
> A strict DMARC policy is appropriate for transactional emails from
> systems which only ever mail to people, it's not appropriate for domains
> with humans who send emails to mailing-lists.
>
> Coincidentally, I've been considering talking with the other list admins
> for exim.org [Bcc'd] about whether we should accept the current trend to
> have mailing-lists rewrite messages so that they appear to come "from"
> the list, instead of from the original poster, for DMARC users. This is
> horrible for various reasons, but with large mail providers pushing
> DMARC, we now have a choice:
>
> 1. Rewrite mails a lot, breaking DKIM, for messages through @exim.org
> 2. Block all messages from domains which publish DMARC policies.
>
> Option 2 is the quick fix, but James has been helpful and I don't want
> to block his mail. Yet, if he sends enough mail to exim-users, other
> subscribers risk being automatically unsubscribed by mailman when
> Gmail/Yahoo/etc reject enough of his mail and they're deemed to be
> "bouncing addresses".
>
> Option 1 basically means that we're committing to implementing DKIM
> signing on exim.org itself, not necessarily a bad thing.
>
> I wrote the mailman patch for option 2 a few years back, which some
> other lists deployed. Since that time, various "not utterly horrible"
> solutions for Option 1 have become available.
>
> _Because_ new subscribers to exim-users are moderated by default, I'm
> not slapping Option 2 in place immediately as a stop-gap; any current
> subscribers could thus abuse the setup and cause mass unsubscriptions.
> If anyone does that, we'll have to clean up afterwards and issue formal
> complaints. I _think_ we'll be okay for the moment.
>
> -Phil
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>




--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm