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 -0000 > Date: 9 Aug 2014 15:48:22 -0000 > From: MAILER-DAEMON@xxxxxxxxxxxxxxx > To: squid-users-return-123504-@xxxxxxxxxxxxxxx > 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. > > <motienko@xxxxxxxxx>: > 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 > > ------------------------------------------------------------------------------------------------------ >
