Re: List is being blocked as source is SPAMmy...

Raman Gupta <[email protected]> wrote:
> Am 13.11.22 um 17:26 schrieb Charles Cazabon:
>
> > My domain has DKIM, SPF, and DMARC validly configured.  I have a
> > restrictive SPF policy that only validates email for my domains coming
> > from my (single)
> > > mail server.

> I've never run a mailing list myself so I can't say I'm familiar with all
> the details, but some more info that may be useful:
> 
> It seems like ezmlm is signing a lot of emails via domain "lists.pyropus.ca",
> which has SPF and is doing DKIM signing and also has a p=reject DMARC
> policy (subdomains can override parent domain DMARC policies):

It's not ezmlm doing the signing, but otherwise that's correct.  And yes, my
published SPF and DMARC policies for the lists.pyropus.ca domain are
restrictive by design - they *have* to be to get maximum deliverability of
messages.  If your published policies are *not* restrictive, many mailhosts
will simply reject, send to spam, or black-hole mail from your domain.

You don't need to tell me what my DMARC policy says or means.

> Which should be OK for DMARC too as long as the SPF passes and is aligned.
> But this setup means any SPF alignment failures will cause a rejection for
> non-DKIM signed messages.

You don't seem to have understood what I've said earlier.

Every mailing list mail I send uses an envelope sender address in the
lists.pyropus.ca domain.

That domain's SPF and DMARC policies are correct and properly strict.

Every message sent through my mailing lists should therefore pass SPF and
DMARC policy checks.

Any SPF failures are bugs on the part of the receiving mailserver(s) the
message passes through - the ones I see are machines which are checking the
domain of the address in the message's From: header field, rather than the
envelope sender address.  Doing this is strongly recommended against by
section 2.2 of the final SPF RFC.  Not only is it recommended against, this
situation is the *exact example* they give of why you should NOT check any
domain from any header field in the message.

> but unfortunately with a p=reject policy I don't see the Authentication
> headers for messages that are failing.

Most DMARC reports and bounces do not include full headers.  The ones that do,
I check, which is why I know exactly what's happening.

> Maybe temporarily change the policy temporarily so that we can debug the
> problem, if there is one?

Uh, no.  I like my mail actually being delivered rather than black-holed.  My
policies are correct.

The problem doesn't need debugging - I have described exactly what it is,
several times, and it is a problem with some receiving mailservers,
particularly when people subscribe with one address and then forward their
mail to a different address or re-inject it into the SMTP stream via fetchmail
etc.

I'm curious why you think I don't know how my mailserver is configured.  I do
have more than 20 years of this under my belt, including many years of being
paid to tell other people how to configure *their* mail servers, or to
diagnose problems like this that they are having.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at:               http://pyropus.ca/software/
-----------------------------------------------------------------------