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@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. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
