On Thu, 2014-08-21 at 15:02 +0400, Oleg Motienko wrote:
Hello,
Due to DMARC policy of several domains some mail is blocked (see an
example below).
I suppose maillist software ( ezmlm ) needs some tuning, it must
forward email to list with own sender address ( @squid-cache.org ).
I don't see a response so I'll have a go. I run DKIM on several sites.
A lot of DKIM implementations are thoroughly screwed up.
1) Many sites have bad DNS DKIM/DMARC content (CostCo was one).
2) Many sites use small, 512-bit keys even though the RFCs
and NIST explicitly have words written on this subject.
Implementations like OpenDKIM, by default, reject messages
signed with keys less than 1024 bits.
3) From a DMARC perspective, which is why people are moving
to SPF and DKIM, the reporting email address in DNS either
does not exist or is encoded improperly.
4) Some email is not properly signed.
But the problem here is email lists. Squid is not alone. The FreeBSD
lists have the same problem. Section 3 of RFC-6377 has a few words on
mail lists. This probably applies:
In general, absent a general movement by MLM developers and operators
toward more DKIM-friendly practices, an MLM subscriber cannot expect
signatures applied before the message was processed by the MLM to be
valid on delivery to a Receiver. Such an evolution is not expected
in the short term due to general development and deployment inertia.
Moreover, even if an MLM currently passes messages unmodified such
that Author signatures validate, it is possible that a configuration
change or software upgrade to that MLM will cause that no longer to
be true.
Patches exist for resenders to strip existing DKIM signatures and add a
new, valid signature. The argument against doing this is load. In my
case, I use a 2048 bit key and process 60k outgoing messages a day. My
mailers do a lot of other work including anti-spam/anti-virus processing
with two-to-three MILTERs. Based on my load graphs for the last 4-6
weeks of running DKIM/DMARC against the prior months, there is NO
significant load increase. In fact, the additional load is little more
than additional noise.
Currently, as a receiver you are forced to insert exceptions, if you
can. The problem is these exception lists can get fairly lengthy and
quickly become unmanageable. It is better if resenders simply patch
their implementations.
An example:
--
Return-Path:
Received: (qmail 8574 invoked for bounce); 9 Aug 2014 15:48:22 -
Date: 9 Aug 2014 15:48:22 -
From: mailer-dae...@squid-cache.org
To: squid-users-return-1235...@squid-cache.org
Subject: failure notice
Hi. This is the qmail-send program at squid-cache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
motie...@gmail.com:
74.125.142.27 failed after I sent the message.
Remote host said: 550-5.7.1 Unauthenticated email from yahoo.com is
not accepted due to domain's
550-5.7.1 DMARC policy. Please contact administrator of yahoo.com domain if
550-5.7.1 this was a legitimate mail. Please visit
550-5.7.1 http://support.google.com/mail/answer/2451690 to learn about DMARC
550 5.7.1 initiative. o17si27260806icl.100 - gsmtp
--
