[Mailman-Developers] Extracting some Mailman code

Mark Sapiro mark at msapiro.net
Sun Oct 15 13:24:16 EDT 2017


On 10/15/2017 07:35 AM, Lindsay Haisley wrote:
> 
> I assume the reference to publicsuffix.org comes with later versions of
> 2.x and in MM 3 since there's none in 2.1.18-1. This must be something
> new in the DMARC mitigation world and I'm not familiar with it.


This is code that was added in 2.1.22 to deal with organizational
domains. Every domain has a corresponding organizational domain which
may or may not be the same as the original domain. In many cases it's
simple. For example, the organizational domain for example.com is
example.com and organizational domain for any.subdomain.of.example.com
is example.com.

The DMARC standard says check the policy of the domain, but if the
domain doesn't publish a policy, check the policy of the corresponding
organizational domain, so you actually need to check the organizational
domain. It's even more complicated than that because the organizational
domain can publish a p= policy which applies to it and any subdomains
that don't publish their own policy, but it can also publish an s=
policy which applies only to subdomains that don't publish their own
policy but not to itself.

The actual determination of the organizational domain for a given domain
can be complex. For common tlds like .com, .org, .edu, .net and the
like, the organizational domain is simply the next level, e.g.
example.com, etc., but it can get much more complicated than that. For
example, see the .jp section in the data at
<https://publicsuffix.org/list/public_suffix_list.dat>.


> Is there any reason to pull in a more recent MM 2 and use the DMARC
> detection code therein? Speed is important here since this is simply a
> turnaround on a single email, not dependent on any list variables. I'm
> reluctant to burden every redirection turnaround with an HTTP look-up.


I think you need to deal with organizational domains. You may be able to
get away with just assuming the organizational domain is the two top
levels and ignoring all those cases where it isn't, but you should at
least look at either
<https://gitlab.com/mailman/mailman/blob/master/src/mailman/rules/dmarc.py>
or
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/Mailman/Utils.py>
for ideas.


> Replacement of the From header is just a matter of reading the email
> headers into an array, making modifications if necessary and pushing
> the result, followed by the message body, out to Courier's sendmail
> clone. Basically:
> 
> if from_domain publishes bad DMARC:
>     if Reply-To does not exist:
>         copy From header to Reply-To
>     Replace From with "On behalf of old_From" <postmaster at fmp.com>


I have seen it said that email addresses in display names in From:
headers are a sign of spaminess. Thus, in the above I suggest that
old_From should just be the display name part of the original From: or
be munged in some way (replace '@' with ' at ' or ?) so it doesn't look
like an email address.


> Feed headers and body to Courier's sendmail clone
> 
> My take on it is that this should work OK.
> 


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


More information about the Mailman-Developers mailing list