[Mailman-Users] Mailman and Mimecast

[Mark Sapiro]

On 11/18/2016 09:42 AM, Hirayama, Pat wrote:
> 
> Problem 1:  One list gets their email rejected with a 550 Rejected by
> header based Anti-Spoofing policy: ...
> https://community.mimecast.com/docs/DOC-1369#550
> 
> If I am reading the referenced
> (https://community.mimecast.com/docs/DOC-1419-anti-spoofing-policies)
> page correctly, the problem is that the sender of the list is at
> domain A, the recipients of the lists are at domain A, but the
> listserv itself is in domain B, and from Mimecast's POV, there
> shouldn't be mail from A to A being relayed by B.  And then it goes
> on to say that you should reconfigure your Mimecast to put in a
> bypass policy for this server.


There is a generic problem here. It is that various entities try to
enforce various anti-spam, anti-spoofing, anti-phishing measures without
considering a) how effective their measures will really be and b) the
adverse effects on mailing lists and other types of mail forwarding.


> What the mail folks at domain A would prefer is that I (domain B) fix
> this.  I'm thinking that I could fix this by using either
> anonymous_list or changing the setting of from_is_list.  But, what
> isn't clear to me is if this is really the correct step to take (my
> initial inclination is that they should follow Mimecast's direction
> of putting in a bypass policy).


I agree with you. They (domain A) have put policies in place that
negatively impact their users and are asking you to change your behavior
to mitigate the impacts on their users instead of doing what Mimecast
suggests.

However, getting them to see the light and behave responsibly to their
users may be futile.

I wouldn't use anonymous_list for this, because it really makes your
list anonymous which is not something most list's want.

You can use from_is_list, but there is another issue with that. Various
Microsoft services have started adding "spoofing" warnings to received
messages which are both To: and From: the same address. This will be the
case with most from_is_list = Munge From or Wrap Message messages unless
you also enable Full personalization for the list.

It is probably only a matter of time before this "spoofing" test becomes
more widespread and results in message rejection rather than just
addition of a warning.


> Problem 2:  Another list I have -- they actually accept the mail, and
> then send it back.  So, I see status=sent in my postfix logs, but the
> members don't get it.  Apparently, it is running into a problem
> because the HELO greeting from my mail gateways (MX) doesn't match
> the FQDN of the mailman server.
> 
> So, the mailman server is smarthosted to my MX servers, which do some
> scanning of the message before sending it out.  Apparently, what
> these Mimecast users want me to do is to rewrite the envelope so that
> instead of the mailman server's FQDN, I replace it with either the
> FQDN of the MX server, or just my domain.


The envelope sender needs to be LISTNAME-bounces at maillist.domain or in
the VERP case, LISTNAME-bounces+user=users.domain at maillist.domain for
Mailman's bounce processing to work, and these addresses need to be
deliverable.


> In the /etc/aliases file on my MX servers, I have the 'post' address
> listed, so mail sent to listname at domain gets routed to the mailman
> server.  I haven't listed any of the other 9 mailman addresses (i.e.
> -admin, -bounces, -confirm, -join, -leave, -owner, -request,
> -subscribe, -unsubscribe).  So, my thinking is that if I do the
> rewrite, so the message comes from listname-bounces at domain, instead
> of listname-bounces at lists.domain, I will need to add this and the
> other addresses on my MX server so that mail routing will work. Since
> I have 3000+ lists, that's like 27k more lines in /etc/aliases to
> add/manage.


So are you saying that currently the other LISTNAME-xxx@ addresses are
undeliverable or what?

I'm having trouble understanding the configuration.

As I said above, if bounce processing is going to work, mail to
LISTNAME-bounces at maillist.domain must be deliverable.

The -admin address is a historical artifact and you don't need it, byt
the other -xxx addresses are all documented and should work.

If they do work by direct delivery to the Mailman server, then maybe all
is OK in that respect.

I'm having difficulty in wrapping my head around this.

I'm now thinking that Mailman thinks it's email domain is what you are
calling lists.domain and that mail to that domain goes directly to the
Mailman server. If so, that's good so far.

Then you have aliases in the MX for 'domain' so mail to LIST at domain gets
relayed to Mailman for 'convenience.

So if that's all correct, the issue is the mail is not delivered because
the outgoing smarthost identifies itself as 'domain' in HELO/EHLO and
the envelope is from a sub-domain lists.domain.


> Again, I'm thinking that they should put in some exception in their
> Mimecast configuration.


If my understanding above is correct, my mind boggles at the stupidity
of rejecting mail because the envelope sender domain is a sub-domain of
the HELO/EHLO domain.

I have an MX which sends mail with envelopes from various virtual
domains that aren't the MXs canonical domain. This is supposed to work.


> Am I just being obstinate here for no reason?  Should I just assume
> the pain and change the behavior of my mailman server?  Thoughts?


I agree that "they" not you should change, but getting them to is
another issue. What you do depends on how badly you want this mail
delivered.

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