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/U...> 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@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan