![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
As a moderator of our list, I know when messages are approved, and I'm seeing very erratic delivery times to my own address, which is on an Exchange server. They used to come through within a minute or so, now they can take 20 minutes or an hour.
I subscribed my gmail address for comparison, and am finding that the same list messages come through to it as quickly as ever.
From those observations I would conclude that the Exchange server is having problems receiving external mail, but I've found that test messages sent from my gmail account to my Exchange address come through within seconds.
Can I assume this has nothing to do with mailman?
Peter Shute
Sent from my iPad
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Just for interest, the email below took 15 minutes to arrive back. I'm sure they normally come back way faster than that, which makes me think it's a problem with the Exchange server.
But what sort of problem makes a server take longer to receive a list message than a direct message?
Peter Shute
Sent from my iPad
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On July 14, 2014 4:29:16 AM PDT, Peter Shute <pshute@nuw.org.au> wrote:
Can I assume this has nothing to do with mailman?
Look at the Received: headers in the received message to determine where the delay is.
Could grey listing be involved?
-- Mark Sapiro <mark@msapiro.net> Sent from my Android phone with K-9 Mail. [Unpaid endorsement]
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Would grey listing show up in the headers? We haven't installed grey listing here, but who know what our anti spam does. If it's using it then it certainly isn't using it consistently. I can't see anything in the Exchange Message Tracking logs that shows anything unusual as they come in. They simply arrive late.
I dumped from Outlook the last few weeeks of send and received times for stuff I've received from this list. Some of the delays will be moderation time, but I can see that the number of messages delayed longer than a few minutes increased greatly on 11/7/14, but that there is still the occasional one that comes though within a minute.
These are the top two headers from a delayed message. Does this tell me anything other than it was received by the server upstream of mine 21 minutes before it was received by mine? If so then the delay could be before that upstream server sent it on, or while it waited for my server to accept it. If it tried several times, would that be shown in the headers?
Received: from s26.web-hosting.com (192.64.112.70) by NUWVICMS2.nuw.org.au (192.168.0.36) with Microsoft SMTP Server id 8.1.436.0; Fri, 11 Jul 2014 09:11:01 +1000 Received: from localhost ([127.0.0.1]:37183 helo=server26.web-hosting.com) by server26.web-hosting.com with esmtp (Exim 4.82) (envelope-from <birding-aus-bounces@birding-aus.org>) id 1X5NAu-001sA8-Fw; Thu, 10 Jul 2014 18:50:48 -0400
![](https://secure.gravatar.com/avatar/0d67da306b00861e781dbdafd331dfea.jpg?s=120&d=mm&r=g)
On 7/14/2014 8:43 PM, Peter Shute wrote:
The server26 machine accepted the mail from localhost at 18:50:48 . The NUWVICMS2 machine accepted the mail from server26 at 09:11:01 The time difference is 9:12 + 11:01 = 20:12. Twenty minutes seems a long time for greylisting. You would have to look at the mail logs from the NUWVICMS2 machine to see what it was doing from 08:50 until 09:11 (GMT+1000) to know why the mail was delayed. Also, the logs on the server16 machine would probably tell if server26 tried an earlier connection to the NUWVICMS2 machine.
--Barry Finkel
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/14/2014 06:55 PM, Barry S. Finkel wrote:
Greylisting may or may not show in headers depending on the software doing it. For example, Postgrey adds a header like
X-Greylist: delayed 427 seconds by postgrey-1.34 at sbh16.songbird.com; Sat, 12 Jul 2014 18:14:34 PDT
See below.
This could be due to greylisting. Intelligent greylisting keeps track of sending servers, and after a server has successfully retried a small number of messages, there is no point in further greylisting that server because the server is known to retry.
You are correct, the delay was in transmission from the upstream server to your exchange server. The headers tell you nothing more than that.
However, in this case, if greylisting is involved, it is your exchange server doing it and there should be evidence in the exchange server's logs of the initial connect and temporary reject at about the time the upstream server received the message and initially tried to relay it.
Of course, there can be other reasons such as network issues why the sending server's initial sending attempt failed, and these may not be logged in your server. You'd have to see the logs of the sending server to know what happened and why in these cases.
...
Twenty minutes seems a long time for greylisting.
There are two times involved in greylisting. The first is the recipient (greylisting) servers "early retry" time, i.e. the time before which the server says this retry is too soon. That is typically short, on the order of 5 minutes.
The second is the delay before the sending server retries. This depends on the retry strategy of the sending server and can easily exceed 20 minutes.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Thanks for that, Mark. I've discovered one possible reason - we're low on space on our Exchange server, which caused it to process external incoming mail erratically. The free space limit before delays on our old server was 1GB, the new one is higher than I expected at 2.7GB (I never knew it was a percentage of total disk space).
This doesn't explain though why SOME external mail (including most but not all from this list) was coming in quickly though. Might just be a coincidence. We've cleared some space, so I'll know if this was the problem when the next list message arrives.
Peter Shute
![](https://secure.gravatar.com/avatar/395215a635f89ee4fd6d9dfe8453afae.jpg?s=120&d=mm&r=g)
Barry S. Finkel writes:
On 7/14/2014 8:43 PM, Peter Shute wrote:
It might, depending on the receiving software. My system shows this:
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.6 (mx.example.org [10.0.0.1]); Mon, 14 Jul 2014 21:57:46 -0400 (EDT)
Not that I can see.
If so then the delay could be before that upstream server sent it on, or while it waited for my server to accept it.
Yes.
If it tried several times, would that be shown in the headers?
Normally, no.
Why? My host will continue to refuse mail for 15 minutes before autowhitelisting, but most mail gets delayed for 2-4 hours depending on the retry cycle of the sending machine (the host doesn't get a lot of mail from most sites).
This should also appear in the NUWVICMS2 machine logs if it was greylisting.
Steve
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Thanks for taking the time to reply to those points. Since my discovery and fixing of the diskspace problem that was causing Exchange to apply what it calls back pressure to incoming mail, the delays have continued. The disk space problem had only been adding to the problem, not causing it.
I've now enabled protocol logging on our Exchange server, a new world for me. I can see several possibly relevant events in yesterday's logs that look like this: 2014-07-17T07:02:03.914Z,NUWVICMS2\Default NUWVICMS2,08D145520008BC68,24,192.168.0.36:25,192.64.112.70:38732,>,550 5.7.1 Requested action not taken: message refused,
192.64.112.70 is the list's mail server, and I can see entries where mail has been delivered successfully from that address.
Googling that message found a few people blaming it on Symantec antispam, which we use here at work.
As a test, I subscribed myself a second time to the same list with a gmail address. I sent a test message to the list, and it came through to the gmail address within a minute or two, but took 66 minutes to reach my work address.
Then I subscribed a thrid time with an outlook.com address and sent another test message. Again it arrived in the gmail mailbox within a couple of minutes. It arrived in the outlook.com and my work mailboxes around the same time, 12 minutes later.
I believe outlook.com also used Symantec antispam, so this seems to be the common factor. It makes sense that this might suddenly start happening, coinciding with an antispam signature update.
But if the antispam software is refusing the messages, how do they eventually get through?
Peter Shute
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/17/2014 05:01 PM, Peter Shute wrote:
I've now enabled protocol logging on our Exchange server, a new world for me. I can see several possibly relevant events in yesterday's logs that look like this: 2014-07-17T07:02:03.914Z,NUWVICMS2\Default NUWVICMS2,08D145520008BC68,24,192.168.0.36:25,192.64.112.70:38732,>,550 5.7.1 Requested action not taken: message refused,
This is a 550 (extended 5.7.,1) status which is a permanent failure. This is a bounce and will (should) not be retried by the sending server.
I doubt that this specific log message has anything to do with your delayed messages.
But if the antispam software is refusing the messages, how do they eventually get through?
Exactly.
You could look at the logs on the 192.64.112.70 sending server to see what that server did with this message after it was bounced by the exchange server.
If the Mailman server is sending directly to the exchange server and that is where the delays are occurring, you need to look at the MTA logs of the Mailman server and see what's there relevant to sending failures and resends.
But, this thread no longer has anything to do with Mailman. Perhaps you could find another list/forum to discuss this that might be able to provide more expertise in this area.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/264565d0427825fe03128fd4e81fe8a4.jpg?s=120&d=mm&r=g)
Hi Peter, Mark and all
I think I may have the solution now (Peter is one of our list moderators). My web host is now telling me that there is a 200 emails per hour limit for my hosting plan. We have 1140 subscribers. That means we blow the limit out of the water EVERY time someone posts!
I'm not sure why they have taken so long to tell me this, as we've been running on this host for over 7 months, but it seems they throttle the outgoing mail volume, so it can take a while for all those recipients to get each message. I suppose it depends on overall server activity - if nothing else is happening, then maybe a new message does get straight to 1140 recipients.
Looks like we will need to shift to a new listserver and maybe even a new webhost - and maybe even a new domain registrar (I've had all my eggs in the Namecheap basket for some years now). Somehow I don't think I am going to get away with this volume of mail for the $50 a year I'm currently paying :-(
Russell Woodford Geelong, Australia birding-aus.org
On 18 July 2014 11:20, Mark Sapiro <mark@msapiro.net> wrote:
![](https://secure.gravatar.com/avatar/93c6947dbffe6ed121a34df0fa094a6d.jpg?s=120&d=mm&r=g)
I'm surprised that any web/email host would apply a rule intended for a personal email account to a listserve. I'm guessing that you are running MailMan on your own computer, then using mail server provided by your email hosting company to send the messages. So to the email host, you do look like a very busy personal account.
As I see it, your options include:
- Discuss this limitation with your email host & see if they will waive the message sending cap for your listserv.
- Use a mailman installation hosted by your email hosting company, which is not subject to a message sending cap.
- Changing email hosts & using a mailman installation hosted by your email hosting company, which is not subject to a message sending cap.
No need to change registrars. NameCheap is a good registrar, better than many. I haven't used their web/email hosting.
My email lists are all running on Mailman provided by my email host. You don't even need to install it, just choose a dedicated subdomain for it to run on. They do NOT limit message flow from Mailman, although they do limit the number of messages per hour sent from a personal mail account. No web/email host is perfect, but I'm pretty happy with DreamHost. Especially for about $100 a year for more services than I can possibly use. (And I'm giving it a good go!).
Here is a Dreamhost Coupon code & link that will give you $10 off now, plus 1 free LIFETIME domain registration. So that's a savings of about $11 a year for life. MACMEDIXFREEDOM What else is included? Tons! Check it out. http://www.dreamhost.com/r.cgi?250640/hosting.html
Best, Dave Nathanson Mac Medix
On Jul 20, 2014, at 4:38 AM, Russell Woodford <rdwoodford@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
No, it's all hosted via cpanel. Does this mail per hour limit seem odd with that sort of setup?
Does dreamhost keep their mailman up to date? We're still on 2.1.15, and when I asked about upgrading, they wouldn't commit to any date, only that it would be more likely to be months than a month.
Peter Shute
Sent from my iPad
![](https://secure.gravatar.com/avatar/af5f3a2ac097765617a652c2d0d3407d.jpg?s=120&d=mm&r=g)
Dreamhost also throttles their SMTP servers:
http://wiki.dreamhost.com/SMTP_quota
By not keeping their Mailman installation up to date is also VERY problematic since certain ISPs' DMARC policies impacts mailing lists everywhere. If you were serious about your mailing list(s), I would not use them. Using us on the other hand makes a lot of sense. :^)
Brian Carpenter EMWD.com
Providing Cloud Services and more for over 15 years.
T: 336.755.0685 E: brian@emwd.com www.emwd.com
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
That dreamhost page says there's an smtp limit of 100 recipients an hour, which would be unworkable for 1000 plus members, but also mentions "announce lists", which don't have limits. The announce lists page says these are different from "discussion lists", but the discussion lists page doesn't mention limits.
I assume when you mention not keeping mailman up to date, you're referring to our current provider, not dreamhost?
Peter Shute
![](https://secure.gravatar.com/avatar/aea419fad3a94f9e1d4ea51377f7b399.jpg?s=120&d=mm&r=g)
Always beware when businesses attempt to describe their competitor’s products.
That’s pretty disingenuous of you, Brian. On that page you mention, it plainly says:
I myself admin several mailing lists with them, one with 7800+ members, with roughly 14 messages/day. That’s on the order of 100K emails/day. I have never had any issues with DH throttling the outgoing messages from my lists. (I do have problems with the likes of Roadrunner/Time Warner having irresponsible reception policies so that their email users are constantly getting subscriptions disabled, but that’s another story).
Dreamhost is definitely not perfect, but this is not one of the problem areas.
(They are now running MM 2.1.17, as of a couple months ago.)
-Conrad
On Jul 20, 2014, at 5:49 PM, Brian Carpenter <brian@emwd.com> wrote:
-- Eternal vigilance is the price of prosperity.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
No, it's all hosted via cpanel. Does this mail per hour limit seem odd with that sort of setup?
To me it seems like a good way to chase away customers, but IIRC over the years many people have posted to this list about such limitations (usually under the subject of "how do I throttle Mailman to not overrun my host's SMTP limit?")
![](https://secure.gravatar.com/avatar/70dbe67e0eb08a96d695871292b27eef.jpg?s=120&d=mm&r=g)
<< On 7/20/2014 3:35 PM, Peter Shute wrote:
Does dreamhost keep their mailman up to date? >>
My 'understanding' is that above has a non-answer because there is allegedly distinct difference between an ISP offering MM 2.1.15.... and QUIETLY offering cPanel's "version" ALSO bearing the I.D. as above.
At least my Blue Host "Tech" person related to me.
And yep, just checked one (1) of my List Mails and "source" header info says BH using "Mailman-Version: 2.1.15".
This little "blurb" may be of interest to some of you <sigh>: <quote> With mailings lists larger than 100 users, it is not suggested to use the above mailing lists[1]. There is another free program, called DadaMail which is very robust, and can also throttle the email so the entire list is not sent at once. In the shared hosting environment, this is very much appreciated by the host as it lowers the server load for all. If you would like more information on DadaMail, please visit their website HERE <http://dadamailproject.com/>. </quote>
I have "mentioned" a few facts learned here (List) whilst either doing eMail (NON-Lists)"problems" and basically been told that "I" have zero clue(s) about Mailing Lists and 'mails' ! ! ! Each time has left me LMAO & shaking my head -:) -:) -:) ! ! !
But, since I have an extremely sweet deal, I stay.
Ed " Just Brits "
[1] above = MailMan (on "List Set-up Pages).
![](https://secure.gravatar.com/avatar/93c6947dbffe6ed121a34df0fa094a6d.jpg?s=120&d=mm&r=g)
Hi Peter, To answer your question, Dreamhost has the *almost* newest version of MailMan 2.1.17. They upgraded just as 2.1.18 came out and had already tested 2.1.17 so they went with that. And this version does have the most important DMARC mitigation features. So it is working for us.
I have never had any problem with DreamHost imposing a message sending cap on their "1-Click" installs of Mailman. I run several discussion lists there completely without incident, for 8 years.... Until this whole Yahoo/demarc mess. And we are back to normal. No host is perfect, but considering the low price & all the "unlimited everything" they offer, I'm very happy with mine. Considering the price you have been paying, you will most likely need to pay more to get out of this problem, but maybe not much more. http://www.dreamhost.com/r.cgi?250640/hosting.html
Best, Dave Nathanson Mac Medix
![](https://secure.gravatar.com/avatar/af5f3a2ac097765617a652c2d0d3407d.jpg?s=120&d=mm&r=g)
The latest version (which we offer) offers additional moderation features that gives list administrators more options in working with ISPs with poor DMARC policies.
https://mail.python.org/pipermail/mailman-announce/2014-April/000188.html
Brian Carpenter EMWD.com
Providing Cloud Services and more for over 15 years.
T: 336.755.0685 E: brian@emwd.com www.emwd.com www.mailmanhost.com
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
IIRC the big difference between 2.1.17 and 2.1.18-1[1] is that in 2.1.17 the DMARC-mitigation features[2] are applied to *all* posts, whereas in 2.1.18 you have the option of checking the DMARC policy and only making those ugly changes to posts *from domains with a "p=reject" DMARC policy* (requires an additional Python package to make the DNS check for the policy). You can also (in >= 2.1.18) "preemptively"[3] reject such posts before trying to distribute them, and thus distribute only posts that will not trigger DMARC rejects.
2.1.18-1 may also have some minor improvements in bounce handling, but as far is I know this is still problematic as many receiving hosts don't tell you that it's a DMARC reject, and even those that do have a wide variety of idioms for indicating that. So many DMARC rejects will increment subscribers' bounce counts, even though the reject was instigated by the poster's service provider.
Steve
Footnotes: [1] Avoid 2.1.18, it has a bug that is fatal on some systems.
[2] Encapsulation in a mini-digest which is From: mailman, or directly munging from so that the address that appears there is mailman's address, not the poster's. The Reply-To field is tweaked so that the poster can be addressed without copying the address by hand.
[3] Usually at the Mailman host the post will pass the DMARC check, and so the Mailman host's MTA may participate in DMARC protocols but it will still deliver to Mailman regardless of DMARC policy at the source. However, due to the nature of the protocol, a Mailman list which changes the post (even just a list tag in the Subject) will necessarily fail the check, so Mailman knows when a DMARC reject of distributed posts will occur.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
Well, I can get away with a policy of "Friends don't let friends use Yahoo!" and be ornery about it, so take my advice with a grain of salt. But I just blame Yahoo! and tell yahoo.com users (other yahoo.* domains don't have this policy) to lump it.
But you're right, people do report the difference. So it depends on how many users who prefer to post from Yahoo! you have. (In my case, most of my Yahoo! users say "I should have got rid of my Yahoo! account long ago.)
N.B. You're posting from edu.au. Do you really have that many yahoo.COM users that you care about a difference in their treatment? If the majority of your Yahoo!/AOL users are from a different country, they may very well *not* have "p=reject" policies. Eg:
$ dig +short _dmarc.yahoo.com.au TXT "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com\;"
Note the "p=none". Australian Yahoo! users don't have a reject policy in place (yet).
Steve
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
It's the people who don't notice the difference that I'm worried about. If someone has been relying on the fact that clicking Reply will create a private reply, they're going to try it on a munged one and not notice. Then it'll be them defending themselves for whatever inappropriate remark they've accicentally sent to the list, not the Yahoo user. I can see myself getting caught out by it, it's hard to remember to look how it's set up.
I'm still all for rejecting and forwarding them by hand, with an explanatory note at the top. Then at least the private replies will only go to me. But we need 2.1.18-1 to help us detect them reliably.
I did recently realise they weren't all affected, but most of our yahoo users are on yahoo.com.
Peter Shute
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/21/2014 06:50 PM, Peter Shute wrote:
That was my impression too. It sounds less disruptive, but I wonder if the resulting variability of behaviour of Reply and Reply all would just cause confusion.
In 2.1.18-1, with minor exceptions, 'reply' and 'reply all' do the same things on a munged message as on a non-munged message. The exceptions are due to the fact that in 2.1.18-1 the Munge From action always puts the original From: in Reply-To: so the original From: is always somewhere. The implication of this is that with list settings first_strip_reply_to = Yes and reply_goes_to_list = This List, in the unmunged case, reply goes only to the list and in the munged case, it goes to the list and the original From: which may mean the original From: gets a dupe or only a direct and not a list copy.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
We're now on a new list server, which is running v2.1.18-1. We've set from_is_list to munged, and it's now sending list messages from the list, and putting the original sender's address in Reply To as expected.
On my iPad, Reply sends a message back to the original sender, which is what we want. Reply To sends a message to both the original sender and also the list, which is what we want.
Apparently gmail web interface works the same way, but Outlook doesn't. Outlook sends Reply All to the original sender and anyone else that was Cc'd, but not the list.
Is there a fix? Which other variables affect this?
Peter Shute
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Further unwanted Reply All behaviour - a Lotus Notes user says when he sends a reply with Reply All, the list bounce address is Cc'd. It does include the list address too, which is good.
Can it cause any problems to Cc the list bounce address?
Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
Mark is on vacation for two weeks, so you'll probably have to wait for a definitive answer.
I believe that Mailman is smart enough to recognize that an ordinary post is not a bounce, so probably no harm is done. However, if the post happens to have a three-digit number starting with 4 or 5 near the start, I suppose it could be misclassified.
Either way, I'd keep an eye on user bounce counts. I think Mark has such a script in his contrib site (sorry, don't recall the URL). You can check for disabled members with "bin/list_members -n bybounce".
Steve
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 08/17/2014 07:46 PM, Peter Shute wrote:
Can it cause any problems to Cc the list bounce address?
It will probably (almost certainly unless someone purposely crafts a post that looks like some kind of DSN) be an unrecognized bounce which will either be ignored or forwarded to the list owner depending on the list's bounce_unrecognized_goes_to_list_owner setting. It won't cause any problems other than possibly annoying the list owner.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
No, there is no fix. Both behaviors are arguably RFC conforming (the RFC doesn't specify "Reply to All" behavior of MUAs, so the MUAs can do whatever they want), and Outlook's is arguably more conformant to the spirit of the RFC, since according to the RFC the configuration
From: list@example.com
Reply-To: person@example.org
has the semantics "the entity using the mailbox 'list@example.com' requests that you address mail intended for the entity to the mailbox 'person@example.org'". Since HMS Reply-To-Munging-Considered-Useful has long since sailed, I agree that the AppleMail/GMail behavior is more useful, but good luck getting existing installations of Outlook patched to do what's useful.
This ambiguity is I why I find the setting dmarc_moderation_action to 'wrap' to be preferable, since all relevant information is preserved on the "inside" message. However, folks using AppleMail on iOS (and maybe Mac OS too) have complained about this setting, and it's not intuitive to most subscribers.
Sorry to be the bearer of bad news.
Regards,
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
Thanks, I'll stop looking for one!
I don't think that's a good alternative then.
Sorry to be the bearer of bad news.
That's fine, I just want to know what the options are without having to experiment with all sorts of clients.
If we set from_is_list to No, how does the list behave when yahoo.com emails arrive? I'm under the impression it will send them to the moderation queue, and will offer extra options like munging. Is that correct, or am I confused? Do we have to change any other settings to make that happen?
Looking now at the description of dmarc_moderation_action, I think I'm confused.
Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
If we set from_is_list to No, how does the list behave when yahoo.com emails arrive?
That depends on the setting of dmarc_moderation_action. If it is set to Accept, it just passes them through, and lets the destination decide what to do. Almost certainly you will get many bounces.
I'm under the impression it will send them to the moderation queue, and will offer extra options like munging.
No. Neither of these options can cause a message to end up in the moderation queue as currently specified.
The logic is that the only reason for a per-message choice of policy is that the moderator is willing to edit some messages from Yahoo! addresses, and will reject or discard others. This seems like a very unusual case to us, as on lists with enough posters from those domains this should significantly increase moderator burden, as well as be likely to attract *strong* objections from folks whose messages get "less favorable" treatment.
It is "easily" worked around by simply flipping the moderation bit on members subscribed with yahoo.com or aol.com addresses. If somebody wants that option, it would be easy to script. In fact, the script could automoderate any domain with "p=reject" as of the time it was run. (Note: auto-unmoderation is problematic without further changes to Mailman, as we don't know *why* the address was moderated. You wouldn't want some miscreant with stalker tendencies unmoderated because her domain decided to behave like a responsible citizen.)
Adding options to munge or wrap to the moderator's control panel should not be hard, but they aren't available now. Note, however, that "Discard all messages tagged Defer" would now be more dangerous than ever because you've added a large class of messages that should not get trashed to the moderation queue.
Overall, I don't think it's worth it. However, if you have a use case, feel free to request the enhancement.
Looking now at the description of dmarc_moderation_action, I think I'm confused.
I think what you missed is that all DMARC moderation is done by a robot; no human intervention involved.
That is, when dmarc_moderation_action is set to something other than Accept, it looks up the From domain's current DMARC policy using the DNS. If this policy is "p=reject", Mailman will *automatically* take an action, which may be Munge From, Wrap Message, Reject, or Discard. (dmarc_quarantine_moderation_action works the same way for domains with policy "p=quarantine".)
This means that only messages from badly-behaved domains get altered in ways which make life difficult for readers. For me, this is great -- it gives my *very* few "p=reject" members a strong incentive to subscribe an address from a good citizen domain. :-) Obviously, most admins are nowhere near so fortunate, so I can't recommend making such a rationale public. ;-)
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
So if we set fom_is_list to No and dmarc_moderation_action to Munge From, non yahoo/aol emails will go through normally, and yahoo/aol emails will get munged? That's what we want. We're seeing too many side effects from munging them all.
Good, we don't need that. I've been reading the messages here about these options ever since yahoo made the change that prompted their creation, but without understanding properly because we were stuck on 2.1.15.
I think what you missed is that all DMARC moderation is done by a robot; no human intervention involved.
Yes. I somehow got the idea there was an addional "safety net" that would give moderators a last chance to choose to munge or wrap at approval time. Like if dmarc_moderation_action had a Hold option.
Very few of our yahoo/aol members ever post. Lots of those who did have already changed to gmail when we asked, but a couple remain. If they still won't change then they'll have to put up with this.
I've discovered another side effect of munging and iOS Mail, which I'll mention in another thread.
Thanks for your help, Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
Yes, that's what will happen. (Modulo bugs, of course. This is a very new feature, and only recently has it been possible to test it in the wild. We believe there are no bugs, of course, but if you observe anything you don't understand or don't like, let us know!)
Steve
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/20/2014 08:25 AM, Dave Nathanson wrote:
I'm surprised that any web/email host would apply a rule intended for a personal email account to a listserve.
Don Quixote says see the FAQ at <http://wiki.list.org/display/DOC/Mailman+is+not+Listserv>.
That said, if you search the archives of this list, you will find many reports of hosting services that provide Mailman list "support" and limit outgoing mail rates from those lists.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/20/2014 08:06 PM, Peter Shute wrote:
Is limiting normally applied strictly per recipient? Or does it reduce the problem if lots of the members are on one domain? 50% of our members are with just 5 domains.
It depends on the specific service and their policies. They could limit recipients or SMTP transactions. If they limit recipients, there's not much you can do.
If the limit is on transactions, you can leave Mailman's default settings for SMTP_MAX_RCPTS (500) VERP (No) and personalization (No) and Mailman will group domains into a few transactions with many RCPTs and this may help.
But the question remains. If MTA rate limiting is the answer, why did it only start not long ago (In one post you said 11 July).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
I think they said it was a recipient limit.
I don't think we'd have access to those settings with cpanel anyway, would we?
But the question remains. If MTA rate limiting is the answer, why did it only start not long ago (In one post you said 11 July).
They claim we were sending spam, and they noticed a huge spike in the amount of SMTP traffic (2.5GB vs the usual 10MB or so) on the 10th. they didn't show us stats for the numbers of emails, only the size. We think someone somehow hacked our account and really was sending spam, although we've only got their word for it. If they were sending it to list members that would explain the mail rejections I was seeing in my own logs.
Anyway, it's obvious that the topic of these limits is an old one, and the only new thing here is that we somehow got lucky and they didn't apply them for a long time. I think I'd have prefered if we'd known from the start. Time to concentrate on moving to a new provider.
Peter Shute
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Just for interest, the email below took 15 minutes to arrive back. I'm sure they normally come back way faster than that, which makes me think it's a problem with the Exchange server.
But what sort of problem makes a server take longer to receive a list message than a direct message?
Peter Shute
Sent from my iPad
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On July 14, 2014 4:29:16 AM PDT, Peter Shute <pshute@nuw.org.au> wrote:
Can I assume this has nothing to do with mailman?
Look at the Received: headers in the received message to determine where the delay is.
Could grey listing be involved?
-- Mark Sapiro <mark@msapiro.net> Sent from my Android phone with K-9 Mail. [Unpaid endorsement]
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Would grey listing show up in the headers? We haven't installed grey listing here, but who know what our anti spam does. If it's using it then it certainly isn't using it consistently. I can't see anything in the Exchange Message Tracking logs that shows anything unusual as they come in. They simply arrive late.
I dumped from Outlook the last few weeeks of send and received times for stuff I've received from this list. Some of the delays will be moderation time, but I can see that the number of messages delayed longer than a few minutes increased greatly on 11/7/14, but that there is still the occasional one that comes though within a minute.
These are the top two headers from a delayed message. Does this tell me anything other than it was received by the server upstream of mine 21 minutes before it was received by mine? If so then the delay could be before that upstream server sent it on, or while it waited for my server to accept it. If it tried several times, would that be shown in the headers?
Received: from s26.web-hosting.com (192.64.112.70) by NUWVICMS2.nuw.org.au (192.168.0.36) with Microsoft SMTP Server id 8.1.436.0; Fri, 11 Jul 2014 09:11:01 +1000 Received: from localhost ([127.0.0.1]:37183 helo=server26.web-hosting.com) by server26.web-hosting.com with esmtp (Exim 4.82) (envelope-from <birding-aus-bounces@birding-aus.org>) id 1X5NAu-001sA8-Fw; Thu, 10 Jul 2014 18:50:48 -0400
![](https://secure.gravatar.com/avatar/0d67da306b00861e781dbdafd331dfea.jpg?s=120&d=mm&r=g)
On 7/14/2014 8:43 PM, Peter Shute wrote:
The server26 machine accepted the mail from localhost at 18:50:48 . The NUWVICMS2 machine accepted the mail from server26 at 09:11:01 The time difference is 9:12 + 11:01 = 20:12. Twenty minutes seems a long time for greylisting. You would have to look at the mail logs from the NUWVICMS2 machine to see what it was doing from 08:50 until 09:11 (GMT+1000) to know why the mail was delayed. Also, the logs on the server16 machine would probably tell if server26 tried an earlier connection to the NUWVICMS2 machine.
--Barry Finkel
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/14/2014 06:55 PM, Barry S. Finkel wrote:
Greylisting may or may not show in headers depending on the software doing it. For example, Postgrey adds a header like
X-Greylist: delayed 427 seconds by postgrey-1.34 at sbh16.songbird.com; Sat, 12 Jul 2014 18:14:34 PDT
See below.
This could be due to greylisting. Intelligent greylisting keeps track of sending servers, and after a server has successfully retried a small number of messages, there is no point in further greylisting that server because the server is known to retry.
You are correct, the delay was in transmission from the upstream server to your exchange server. The headers tell you nothing more than that.
However, in this case, if greylisting is involved, it is your exchange server doing it and there should be evidence in the exchange server's logs of the initial connect and temporary reject at about the time the upstream server received the message and initially tried to relay it.
Of course, there can be other reasons such as network issues why the sending server's initial sending attempt failed, and these may not be logged in your server. You'd have to see the logs of the sending server to know what happened and why in these cases.
...
Twenty minutes seems a long time for greylisting.
There are two times involved in greylisting. The first is the recipient (greylisting) servers "early retry" time, i.e. the time before which the server says this retry is too soon. That is typically short, on the order of 5 minutes.
The second is the delay before the sending server retries. This depends on the retry strategy of the sending server and can easily exceed 20 minutes.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Thanks for that, Mark. I've discovered one possible reason - we're low on space on our Exchange server, which caused it to process external incoming mail erratically. The free space limit before delays on our old server was 1GB, the new one is higher than I expected at 2.7GB (I never knew it was a percentage of total disk space).
This doesn't explain though why SOME external mail (including most but not all from this list) was coming in quickly though. Might just be a coincidence. We've cleared some space, so I'll know if this was the problem when the next list message arrives.
Peter Shute
![](https://secure.gravatar.com/avatar/395215a635f89ee4fd6d9dfe8453afae.jpg?s=120&d=mm&r=g)
Barry S. Finkel writes:
On 7/14/2014 8:43 PM, Peter Shute wrote:
It might, depending on the receiving software. My system shows this:
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.6 (mx.example.org [10.0.0.1]); Mon, 14 Jul 2014 21:57:46 -0400 (EDT)
Not that I can see.
If so then the delay could be before that upstream server sent it on, or while it waited for my server to accept it.
Yes.
If it tried several times, would that be shown in the headers?
Normally, no.
Why? My host will continue to refuse mail for 15 minutes before autowhitelisting, but most mail gets delayed for 2-4 hours depending on the retry cycle of the sending machine (the host doesn't get a lot of mail from most sites).
This should also appear in the NUWVICMS2 machine logs if it was greylisting.
Steve
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Thanks for taking the time to reply to those points. Since my discovery and fixing of the diskspace problem that was causing Exchange to apply what it calls back pressure to incoming mail, the delays have continued. The disk space problem had only been adding to the problem, not causing it.
I've now enabled protocol logging on our Exchange server, a new world for me. I can see several possibly relevant events in yesterday's logs that look like this: 2014-07-17T07:02:03.914Z,NUWVICMS2\Default NUWVICMS2,08D145520008BC68,24,192.168.0.36:25,192.64.112.70:38732,>,550 5.7.1 Requested action not taken: message refused,
192.64.112.70 is the list's mail server, and I can see entries where mail has been delivered successfully from that address.
Googling that message found a few people blaming it on Symantec antispam, which we use here at work.
As a test, I subscribed myself a second time to the same list with a gmail address. I sent a test message to the list, and it came through to the gmail address within a minute or two, but took 66 minutes to reach my work address.
Then I subscribed a thrid time with an outlook.com address and sent another test message. Again it arrived in the gmail mailbox within a couple of minutes. It arrived in the outlook.com and my work mailboxes around the same time, 12 minutes later.
I believe outlook.com also used Symantec antispam, so this seems to be the common factor. It makes sense that this might suddenly start happening, coinciding with an antispam signature update.
But if the antispam software is refusing the messages, how do they eventually get through?
Peter Shute
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/17/2014 05:01 PM, Peter Shute wrote:
I've now enabled protocol logging on our Exchange server, a new world for me. I can see several possibly relevant events in yesterday's logs that look like this: 2014-07-17T07:02:03.914Z,NUWVICMS2\Default NUWVICMS2,08D145520008BC68,24,192.168.0.36:25,192.64.112.70:38732,>,550 5.7.1 Requested action not taken: message refused,
This is a 550 (extended 5.7.,1) status which is a permanent failure. This is a bounce and will (should) not be retried by the sending server.
I doubt that this specific log message has anything to do with your delayed messages.
But if the antispam software is refusing the messages, how do they eventually get through?
Exactly.
You could look at the logs on the 192.64.112.70 sending server to see what that server did with this message after it was bounced by the exchange server.
If the Mailman server is sending directly to the exchange server and that is where the delays are occurring, you need to look at the MTA logs of the Mailman server and see what's there relevant to sending failures and resends.
But, this thread no longer has anything to do with Mailman. Perhaps you could find another list/forum to discuss this that might be able to provide more expertise in this area.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/264565d0427825fe03128fd4e81fe8a4.jpg?s=120&d=mm&r=g)
Hi Peter, Mark and all
I think I may have the solution now (Peter is one of our list moderators). My web host is now telling me that there is a 200 emails per hour limit for my hosting plan. We have 1140 subscribers. That means we blow the limit out of the water EVERY time someone posts!
I'm not sure why they have taken so long to tell me this, as we've been running on this host for over 7 months, but it seems they throttle the outgoing mail volume, so it can take a while for all those recipients to get each message. I suppose it depends on overall server activity - if nothing else is happening, then maybe a new message does get straight to 1140 recipients.
Looks like we will need to shift to a new listserver and maybe even a new webhost - and maybe even a new domain registrar (I've had all my eggs in the Namecheap basket for some years now). Somehow I don't think I am going to get away with this volume of mail for the $50 a year I'm currently paying :-(
Russell Woodford Geelong, Australia birding-aus.org
On 18 July 2014 11:20, Mark Sapiro <mark@msapiro.net> wrote:
![](https://secure.gravatar.com/avatar/93c6947dbffe6ed121a34df0fa094a6d.jpg?s=120&d=mm&r=g)
I'm surprised that any web/email host would apply a rule intended for a personal email account to a listserve. I'm guessing that you are running MailMan on your own computer, then using mail server provided by your email hosting company to send the messages. So to the email host, you do look like a very busy personal account.
As I see it, your options include:
- Discuss this limitation with your email host & see if they will waive the message sending cap for your listserv.
- Use a mailman installation hosted by your email hosting company, which is not subject to a message sending cap.
- Changing email hosts & using a mailman installation hosted by your email hosting company, which is not subject to a message sending cap.
No need to change registrars. NameCheap is a good registrar, better than many. I haven't used their web/email hosting.
My email lists are all running on Mailman provided by my email host. You don't even need to install it, just choose a dedicated subdomain for it to run on. They do NOT limit message flow from Mailman, although they do limit the number of messages per hour sent from a personal mail account. No web/email host is perfect, but I'm pretty happy with DreamHost. Especially for about $100 a year for more services than I can possibly use. (And I'm giving it a good go!).
Here is a Dreamhost Coupon code & link that will give you $10 off now, plus 1 free LIFETIME domain registration. So that's a savings of about $11 a year for life. MACMEDIXFREEDOM What else is included? Tons! Check it out. http://www.dreamhost.com/r.cgi?250640/hosting.html
Best, Dave Nathanson Mac Medix
On Jul 20, 2014, at 4:38 AM, Russell Woodford <rdwoodford@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
No, it's all hosted via cpanel. Does this mail per hour limit seem odd with that sort of setup?
Does dreamhost keep their mailman up to date? We're still on 2.1.15, and when I asked about upgrading, they wouldn't commit to any date, only that it would be more likely to be months than a month.
Peter Shute
Sent from my iPad
![](https://secure.gravatar.com/avatar/af5f3a2ac097765617a652c2d0d3407d.jpg?s=120&d=mm&r=g)
Dreamhost also throttles their SMTP servers:
http://wiki.dreamhost.com/SMTP_quota
By not keeping their Mailman installation up to date is also VERY problematic since certain ISPs' DMARC policies impacts mailing lists everywhere. If you were serious about your mailing list(s), I would not use them. Using us on the other hand makes a lot of sense. :^)
Brian Carpenter EMWD.com
Providing Cloud Services and more for over 15 years.
T: 336.755.0685 E: brian@emwd.com www.emwd.com
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
That dreamhost page says there's an smtp limit of 100 recipients an hour, which would be unworkable for 1000 plus members, but also mentions "announce lists", which don't have limits. The announce lists page says these are different from "discussion lists", but the discussion lists page doesn't mention limits.
I assume when you mention not keeping mailman up to date, you're referring to our current provider, not dreamhost?
Peter Shute
![](https://secure.gravatar.com/avatar/aea419fad3a94f9e1d4ea51377f7b399.jpg?s=120&d=mm&r=g)
Always beware when businesses attempt to describe their competitor’s products.
That’s pretty disingenuous of you, Brian. On that page you mention, it plainly says:
I myself admin several mailing lists with them, one with 7800+ members, with roughly 14 messages/day. That’s on the order of 100K emails/day. I have never had any issues with DH throttling the outgoing messages from my lists. (I do have problems with the likes of Roadrunner/Time Warner having irresponsible reception policies so that their email users are constantly getting subscriptions disabled, but that’s another story).
Dreamhost is definitely not perfect, but this is not one of the problem areas.
(They are now running MM 2.1.17, as of a couple months ago.)
-Conrad
On Jul 20, 2014, at 5:49 PM, Brian Carpenter <brian@emwd.com> wrote:
-- Eternal vigilance is the price of prosperity.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
No, it's all hosted via cpanel. Does this mail per hour limit seem odd with that sort of setup?
To me it seems like a good way to chase away customers, but IIRC over the years many people have posted to this list about such limitations (usually under the subject of "how do I throttle Mailman to not overrun my host's SMTP limit?")
![](https://secure.gravatar.com/avatar/70dbe67e0eb08a96d695871292b27eef.jpg?s=120&d=mm&r=g)
<< On 7/20/2014 3:35 PM, Peter Shute wrote:
Does dreamhost keep their mailman up to date? >>
My 'understanding' is that above has a non-answer because there is allegedly distinct difference between an ISP offering MM 2.1.15.... and QUIETLY offering cPanel's "version" ALSO bearing the I.D. as above.
At least my Blue Host "Tech" person related to me.
And yep, just checked one (1) of my List Mails and "source" header info says BH using "Mailman-Version: 2.1.15".
This little "blurb" may be of interest to some of you <sigh>: <quote> With mailings lists larger than 100 users, it is not suggested to use the above mailing lists[1]. There is another free program, called DadaMail which is very robust, and can also throttle the email so the entire list is not sent at once. In the shared hosting environment, this is very much appreciated by the host as it lowers the server load for all. If you would like more information on DadaMail, please visit their website HERE <http://dadamailproject.com/>. </quote>
I have "mentioned" a few facts learned here (List) whilst either doing eMail (NON-Lists)"problems" and basically been told that "I" have zero clue(s) about Mailing Lists and 'mails' ! ! ! Each time has left me LMAO & shaking my head -:) -:) -:) ! ! !
But, since I have an extremely sweet deal, I stay.
Ed " Just Brits "
[1] above = MailMan (on "List Set-up Pages).
![](https://secure.gravatar.com/avatar/93c6947dbffe6ed121a34df0fa094a6d.jpg?s=120&d=mm&r=g)
Hi Peter, To answer your question, Dreamhost has the *almost* newest version of MailMan 2.1.17. They upgraded just as 2.1.18 came out and had already tested 2.1.17 so they went with that. And this version does have the most important DMARC mitigation features. So it is working for us.
I have never had any problem with DreamHost imposing a message sending cap on their "1-Click" installs of Mailman. I run several discussion lists there completely without incident, for 8 years.... Until this whole Yahoo/demarc mess. And we are back to normal. No host is perfect, but considering the low price & all the "unlimited everything" they offer, I'm very happy with mine. Considering the price you have been paying, you will most likely need to pay more to get out of this problem, but maybe not much more. http://www.dreamhost.com/r.cgi?250640/hosting.html
Best, Dave Nathanson Mac Medix
![](https://secure.gravatar.com/avatar/af5f3a2ac097765617a652c2d0d3407d.jpg?s=120&d=mm&r=g)
The latest version (which we offer) offers additional moderation features that gives list administrators more options in working with ISPs with poor DMARC policies.
https://mail.python.org/pipermail/mailman-announce/2014-April/000188.html
Brian Carpenter EMWD.com
Providing Cloud Services and more for over 15 years.
T: 336.755.0685 E: brian@emwd.com www.emwd.com www.mailmanhost.com
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
IIRC the big difference between 2.1.17 and 2.1.18-1[1] is that in 2.1.17 the DMARC-mitigation features[2] are applied to *all* posts, whereas in 2.1.18 you have the option of checking the DMARC policy and only making those ugly changes to posts *from domains with a "p=reject" DMARC policy* (requires an additional Python package to make the DNS check for the policy). You can also (in >= 2.1.18) "preemptively"[3] reject such posts before trying to distribute them, and thus distribute only posts that will not trigger DMARC rejects.
2.1.18-1 may also have some minor improvements in bounce handling, but as far is I know this is still problematic as many receiving hosts don't tell you that it's a DMARC reject, and even those that do have a wide variety of idioms for indicating that. So many DMARC rejects will increment subscribers' bounce counts, even though the reject was instigated by the poster's service provider.
Steve
Footnotes: [1] Avoid 2.1.18, it has a bug that is fatal on some systems.
[2] Encapsulation in a mini-digest which is From: mailman, or directly munging from so that the address that appears there is mailman's address, not the poster's. The Reply-To field is tweaked so that the poster can be addressed without copying the address by hand.
[3] Usually at the Mailman host the post will pass the DMARC check, and so the Mailman host's MTA may participate in DMARC protocols but it will still deliver to Mailman regardless of DMARC policy at the source. However, due to the nature of the protocol, a Mailman list which changes the post (even just a list tag in the Subject) will necessarily fail the check, so Mailman knows when a DMARC reject of distributed posts will occur.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
Well, I can get away with a policy of "Friends don't let friends use Yahoo!" and be ornery about it, so take my advice with a grain of salt. But I just blame Yahoo! and tell yahoo.com users (other yahoo.* domains don't have this policy) to lump it.
But you're right, people do report the difference. So it depends on how many users who prefer to post from Yahoo! you have. (In my case, most of my Yahoo! users say "I should have got rid of my Yahoo! account long ago.)
N.B. You're posting from edu.au. Do you really have that many yahoo.COM users that you care about a difference in their treatment? If the majority of your Yahoo!/AOL users are from a different country, they may very well *not* have "p=reject" policies. Eg:
$ dig +short _dmarc.yahoo.com.au TXT "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com\;"
Note the "p=none". Australian Yahoo! users don't have a reject policy in place (yet).
Steve
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
It's the people who don't notice the difference that I'm worried about. If someone has been relying on the fact that clicking Reply will create a private reply, they're going to try it on a munged one and not notice. Then it'll be them defending themselves for whatever inappropriate remark they've accicentally sent to the list, not the Yahoo user. I can see myself getting caught out by it, it's hard to remember to look how it's set up.
I'm still all for rejecting and forwarding them by hand, with an explanatory note at the top. Then at least the private replies will only go to me. But we need 2.1.18-1 to help us detect them reliably.
I did recently realise they weren't all affected, but most of our yahoo users are on yahoo.com.
Peter Shute
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/21/2014 06:50 PM, Peter Shute wrote:
That was my impression too. It sounds less disruptive, but I wonder if the resulting variability of behaviour of Reply and Reply all would just cause confusion.
In 2.1.18-1, with minor exceptions, 'reply' and 'reply all' do the same things on a munged message as on a non-munged message. The exceptions are due to the fact that in 2.1.18-1 the Munge From action always puts the original From: in Reply-To: so the original From: is always somewhere. The implication of this is that with list settings first_strip_reply_to = Yes and reply_goes_to_list = This List, in the unmunged case, reply goes only to the list and in the munged case, it goes to the list and the original From: which may mean the original From: gets a dupe or only a direct and not a list copy.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
We're now on a new list server, which is running v2.1.18-1. We've set from_is_list to munged, and it's now sending list messages from the list, and putting the original sender's address in Reply To as expected.
On my iPad, Reply sends a message back to the original sender, which is what we want. Reply To sends a message to both the original sender and also the list, which is what we want.
Apparently gmail web interface works the same way, but Outlook doesn't. Outlook sends Reply All to the original sender and anyone else that was Cc'd, but not the list.
Is there a fix? Which other variables affect this?
Peter Shute
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Further unwanted Reply All behaviour - a Lotus Notes user says when he sends a reply with Reply All, the list bounce address is Cc'd. It does include the list address too, which is good.
Can it cause any problems to Cc the list bounce address?
Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
Mark is on vacation for two weeks, so you'll probably have to wait for a definitive answer.
I believe that Mailman is smart enough to recognize that an ordinary post is not a bounce, so probably no harm is done. However, if the post happens to have a three-digit number starting with 4 or 5 near the start, I suppose it could be misclassified.
Either way, I'd keep an eye on user bounce counts. I think Mark has such a script in his contrib site (sorry, don't recall the URL). You can check for disabled members with "bin/list_members -n bybounce".
Steve
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 08/17/2014 07:46 PM, Peter Shute wrote:
Can it cause any problems to Cc the list bounce address?
It will probably (almost certainly unless someone purposely crafts a post that looks like some kind of DSN) be an unrecognized bounce which will either be ignored or forwarded to the list owner depending on the list's bounce_unrecognized_goes_to_list_owner setting. It won't cause any problems other than possibly annoying the list owner.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
No, there is no fix. Both behaviors are arguably RFC conforming (the RFC doesn't specify "Reply to All" behavior of MUAs, so the MUAs can do whatever they want), and Outlook's is arguably more conformant to the spirit of the RFC, since according to the RFC the configuration
From: list@example.com
Reply-To: person@example.org
has the semantics "the entity using the mailbox 'list@example.com' requests that you address mail intended for the entity to the mailbox 'person@example.org'". Since HMS Reply-To-Munging-Considered-Useful has long since sailed, I agree that the AppleMail/GMail behavior is more useful, but good luck getting existing installations of Outlook patched to do what's useful.
This ambiguity is I why I find the setting dmarc_moderation_action to 'wrap' to be preferable, since all relevant information is preserved on the "inside" message. However, folks using AppleMail on iOS (and maybe Mac OS too) have complained about this setting, and it's not intuitive to most subscribers.
Sorry to be the bearer of bad news.
Regards,
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
Thanks, I'll stop looking for one!
I don't think that's a good alternative then.
Sorry to be the bearer of bad news.
That's fine, I just want to know what the options are without having to experiment with all sorts of clients.
If we set from_is_list to No, how does the list behave when yahoo.com emails arrive? I'm under the impression it will send them to the moderation queue, and will offer extra options like munging. Is that correct, or am I confused? Do we have to change any other settings to make that happen?
Looking now at the description of dmarc_moderation_action, I think I'm confused.
Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
If we set from_is_list to No, how does the list behave when yahoo.com emails arrive?
That depends on the setting of dmarc_moderation_action. If it is set to Accept, it just passes them through, and lets the destination decide what to do. Almost certainly you will get many bounces.
I'm under the impression it will send them to the moderation queue, and will offer extra options like munging.
No. Neither of these options can cause a message to end up in the moderation queue as currently specified.
The logic is that the only reason for a per-message choice of policy is that the moderator is willing to edit some messages from Yahoo! addresses, and will reject or discard others. This seems like a very unusual case to us, as on lists with enough posters from those domains this should significantly increase moderator burden, as well as be likely to attract *strong* objections from folks whose messages get "less favorable" treatment.
It is "easily" worked around by simply flipping the moderation bit on members subscribed with yahoo.com or aol.com addresses. If somebody wants that option, it would be easy to script. In fact, the script could automoderate any domain with "p=reject" as of the time it was run. (Note: auto-unmoderation is problematic without further changes to Mailman, as we don't know *why* the address was moderated. You wouldn't want some miscreant with stalker tendencies unmoderated because her domain decided to behave like a responsible citizen.)
Adding options to munge or wrap to the moderator's control panel should not be hard, but they aren't available now. Note, however, that "Discard all messages tagged Defer" would now be more dangerous than ever because you've added a large class of messages that should not get trashed to the moderation queue.
Overall, I don't think it's worth it. However, if you have a use case, feel free to request the enhancement.
Looking now at the description of dmarc_moderation_action, I think I'm confused.
I think what you missed is that all DMARC moderation is done by a robot; no human intervention involved.
That is, when dmarc_moderation_action is set to something other than Accept, it looks up the From domain's current DMARC policy using the DNS. If this policy is "p=reject", Mailman will *automatically* take an action, which may be Munge From, Wrap Message, Reject, or Discard. (dmarc_quarantine_moderation_action works the same way for domains with policy "p=quarantine".)
This means that only messages from badly-behaved domains get altered in ways which make life difficult for readers. For me, this is great -- it gives my *very* few "p=reject" members a strong incentive to subscribe an address from a good citizen domain. :-) Obviously, most admins are nowhere near so fortunate, so I can't recommend making such a rationale public. ;-)
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
So if we set fom_is_list to No and dmarc_moderation_action to Munge From, non yahoo/aol emails will go through normally, and yahoo/aol emails will get munged? That's what we want. We're seeing too many side effects from munging them all.
Good, we don't need that. I've been reading the messages here about these options ever since yahoo made the change that prompted their creation, but without understanding properly because we were stuck on 2.1.15.
I think what you missed is that all DMARC moderation is done by a robot; no human intervention involved.
Yes. I somehow got the idea there was an addional "safety net" that would give moderators a last chance to choose to munge or wrap at approval time. Like if dmarc_moderation_action had a Hold option.
Very few of our yahoo/aol members ever post. Lots of those who did have already changed to gmail when we asked, but a couple remain. If they still won't change then they'll have to put up with this.
I've discovered another side effect of munging and iOS Mail, which I'll mention in another thread.
Thanks for your help, Peter Shute
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Peter Shute writes:
Yes, that's what will happen. (Modulo bugs, of course. This is a very new feature, and only recently has it been possible to test it in the wild. We believe there are no bugs, of course, but if you observe anything you don't understand or don't like, let us know!)
Steve
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/20/2014 08:25 AM, Dave Nathanson wrote:
I'm surprised that any web/email host would apply a rule intended for a personal email account to a listserve.
Don Quixote says see the FAQ at <http://wiki.list.org/display/DOC/Mailman+is+not+Listserv>.
That said, if you search the archives of this list, you will find many reports of hosting services that provide Mailman list "support" and limit outgoing mail rates from those lists.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/20/2014 08:06 PM, Peter Shute wrote:
Is limiting normally applied strictly per recipient? Or does it reduce the problem if lots of the members are on one domain? 50% of our members are with just 5 domains.
It depends on the specific service and their policies. They could limit recipients or SMTP transactions. If they limit recipients, there's not much you can do.
If the limit is on transactions, you can leave Mailman's default settings for SMTP_MAX_RCPTS (500) VERP (No) and personalization (No) and Mailman will group domains into a few transactions with many RCPTs and this may help.
But the question remains. If MTA rate limiting is the answer, why did it only start not long ago (In one post you said 11 July).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/124f9bd3a2e84570d136e3d4be795943.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
I think they said it was a recipient limit.
I don't think we'd have access to those settings with cpanel anyway, would we?
But the question remains. If MTA rate limiting is the answer, why did it only start not long ago (In one post you said 11 July).
They claim we were sending spam, and they noticed a huge spike in the amount of SMTP traffic (2.5GB vs the usual 10MB or so) on the 10th. they didn't show us stats for the numbers of emails, only the size. We think someone somehow hacked our account and really was sending spam, although we've only got their word for it. If they were sending it to list members that would explain the mail rejections I was seeing in my own logs.
Anyway, it's obvious that the topic of these limits is an old one, and the only new thing here is that we somehow got lucky and they didn't apply them for a long time. I think I'd have prefered if we'd known from the start. Time to concentrate on moving to a new provider.
Peter Shute
participants (10)
-
Barry S. Finkel
-
Brian Carpenter
-
Conrad G T Yoder
-
Dave Nathanson
-
Ed Kaler
-
Mark Sapiro
-
Peter Shute
-
Russell Woodford
-
Stephen J. Turnbull
-
Stephen J. Turnbull