[Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in mailman 2.1

[Curtis Villamizar]

In message <572AA1F6.8090807 at msapiro.net>
Mark Sapiro writes:
 
> On 05/03/2016 12:26 PM, Curtis Villamizar wrote:
> > By default DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL is set to
> > https://publicsuffix.org/list/public_suffix_list.dat
> > 
> > I have mailman set up on an IPv6 only host and publicsuffix.org has no
> > IPv6 address.  A near identical configuration is set up on a dual
> > stack host.  Any email to the IPv6 only host fails with an entry in
> > logs/error of the form "Unable to retrieve data from
> > https://publicsuffix.org/list/public_suffix_list.dat: <urlopen error
> > [Errno 43] Protocol not supported>"
>  
>  
> The log entry seems correct for this situation. The mail delivery
> failure is unrelated - see below.
>  
>  
> > In the mean time I would like to disable the use of
> > DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL by setting it empty.  To do this
> > it seems that I would need the following change:
> > 
> > --- Mailman/Utils.py.orig       2016-04-09 04:08:56.000000000 -0400
> > +++ Mailman/Utils.py    2016-05-03 14:37:12.683904000 -0400
> > @@ -1205,6 +1205,8 @@
> >      Domain which may be the same as the input."""
> >      global s_dict
> >      if not s_dict:
> > -        get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
> > +        if mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL:
> > +            get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
> >      hits = []
> >      d = domain.lower().split('.')
> > 
> > This works for .com, .org, .net, etc but not for things like co.uk,
> > etc (which in my case is not an issue).
>  
>  
> This is a bug. I've created
> <https://bugs.launchpad.net/mailman/+bug/1578450> and have fixed it, but
> not as above, although as above should work. The fix is at
> <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1648>

OK.  Same change except in the called function instead of the caller.

> > A second question is why does failing to access publicsuffix.org
> > result in a hard fail rather than a soft fail?  The change I made just
> > skips over get_suffixes and leaves s_dict empty.  It seems that
> > get_suffixes does do a try and except which logs and returns, but then
> > the mail gets rejected and the reason is not clear to me.  In
> > logs/smtp-failure there is a message of the form "failed with code
> > 554: 5.7.1 <fqdn[ipv6addr]>: Client host rejected: Access denied".
>  
>  
> The above message in smtp-failure is saying Mailman is trying to send
> mail to the list or whatever and the recipient MX for this delivery does
> not allow IPv6 access to its MTA, at least not from you. This has
> nothing to do with the changes you made to skip loading
> DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL. I think it is going to be a
> serious problem if you are trying to send mail in general because not
> every recipient domain is going to be listening on port 25 at an IPv6
> address.

I'm not sure what the problem was.

The only thing I'm sure of is testing the config using IPv6 only was
what tripped the bug above.

> I think if your outgoing MTA is connecting only to IPv6 addresses, you
> will have difficulty delivering mail in general regardless of the source
> of the mail.

That's not it.

This was a test mailing list with one recipient - one of my email
addresses.

> As for as why it's a 554: 5.7.1 hard fail, That's the status your MTA is
> giving to this condition. If you think this should be a 4xx status, you
> may be able to configure that in your MTA.

I think this might have been due to a connect to port 25 rather than
running sendmail.  Connect to port 25 would only work if using TLS
(after STARTTLS) and then passing SASL auth.  This host acts as an MDA
and as a MSA for mailman using a dual-stack "smarthost" relay but not
as an MX/MTA (MX points to two DS MTA and the MTA relays to it).

If that is the case it was a config problem in mailman.  I'm still
working on backing up and restoring a complete mailman config.  (That
could be another topic).

> -- 
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan

Thanks for the help.  This was a replacement server, upgraded due to
security advisories, and is now in use.

And BTW - the server was given an IPv4 address before going to
production use but the IPv4 is only needed for apache, not for the
email setup.  The IPv4 may be dropped entirely in the future since I
don't use the web interface anymore.  Recipients are populated from a
database - which is one thing that has always worked fine.

Curtis