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@maillist.domain or in the VERP case, LISTNAME-bounces+user=users.domain@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@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@domain, instead > of listname-bounces@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@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@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 <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ 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
