disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in mailman 2.1
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>" 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). 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". Curtis
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>
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 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. 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. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
In message <572AA1F6.8090807@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@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
participants (2)
-
Curtis Villamizar -
Mark Sapiro