[Mailman-Users] Mailman and Mimecast

[Stephen J. Turnbull]

Mark Sapiro writes:
 > 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.

This is the approach most in the interest of the mail recipients.
However, it is somewhat problematic to configure a bypass, because
many domains that host mailing lists also host ordinary users.  Any of
those users could be a spam source.  On the other hand, it's rather
unlikely that mailing list hosts will be spam sources in this way (the
well-known best practice is to filter outgoing personal mail for spam,
and list hosts are fairly likely to implement that practice).
Furthermore, there is currently an Internet Draft proposal called
Authenticated Received Chain (ARC) to help authenticate such
bypasses.  The ARC signature would only be on mailing list traffic, so
the recipient can distinguish ARC mail from ordinary personal mail.

Unfortunately, many admins would prefer to drop legitimate mail in
quantity rather than risk a spam incident.

 > > What the mail folks at domain A would prefer is that I (domain B) fix
 > > this.

*You* can't *fix* it.  Only they can.  You can install workarounds,
but once you swallow the principle, you are at their mercy.  Any time
they change their filtering policy, you may be asked to adjust.

 > 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.

Right.  They basically have abdicated responsibility for reliable
delivery of their users' mail, in favor of an infinitesimal
improvement in malmail rejection rates.

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

Indeed.  Since the facts don't reflect well on them, they're likely to
deny that they're doing anything that adversely affects their users,
and blame you.

Unfortunately, it doesn't help to go to the users, either.  They don't
understand the technology, are willing to believe in magic, and
yelling at you is a lot less disruptive to their lives than changing
email providers.

 > > 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.

That is really broken.  There must be another factor involved, because
smarthosting is very common, and presumably the same problem would
arise with virtual hosting in many configurations.  In the absence of
another protocol, HELO should validate against the IP address of the
gateway, and that's all.  What's worse, AIUI the envelope from is a
mailbox at the Mailman server, so the MTA should be able to reject at
the MAIL FROM command if HELO != MAIL FROM is really the problem.

I suspect you can fix this at your end by providing an SPF record
saying that your MX's IP is an authorized source for mail apparently
from your list-host domain.  If you already have such an SPF record,
then the Mimecast system[1] is really broken.

 > 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.

I don't see how the above would be relevant, since it's not visible to
the Mimecast system.

 > > Am I just being obstinate here for no reason?

No, you may have some configuration problems you could and should fix,
but you haven't mentioned any yet that I can see.  The requirements
that Mimecast places on incoming mail are far more strict than
anything in the RFCs.  It's their responsibility to own up to their
users that that is the case.

 > > 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.

Indeed.

"Just" assume, no.  Admins who install Mimecast have a legitimate
interest in reducing the spam received by their users.  However, they
are trying to impose much of the cost on innocent third parties like
you.  You may wish to absorb that cost, but IMHO you have the right
to protest it.

You may wish to raise price of subscription in some way (including the
option of raising prices for those subscribers affected by Mimecast
only!)  You could start a Kickstarter project to compensate you for
the effort (and suggest that their mail provider do the paying, not
them ;-).  Or you could just no-mail their subscriptions and tell them
to subscribe from another address.  (That's what my employer, the
Japanese Ministry of Education, did in response to the DMARC fiasco of
2014 -- ironically, yahoo.co.jp is the only yahoo.* domain that
doesn't publish the problematic p=reject DMARC policy!)

Note that Mimecast sites are also imposing costs on their own users,
since there is no way for mail sources to see Mimecast's upraised
middle finger.  Mail sources don't find out about these policies until
the recipients have already lost mail.


Footnotes: 
[1]  "Mimecast system" refers to the host, operating system, and
configuration running Mimecast, not to Mimecast itself.  I don't know
enough about Mimecast to criticize it.