OT: Explain Where Mailing List Bouncing Comes From ?

Home » Asterisk Users » OT: Explain Where Mailing List Bouncing Comes From ?
Asterisk Users 20 Comments

Hello,

I’m a faithful reader of this mailing list, for several years now.

Lately, I’m receiving emails asking me to re-enable my list subscription due to “excessive bouncing”.

What does this exactly mean and why am I receiving this ?
Beside re-enabling my subscription, what can I do to improve things ?

Regards

20 thoughts on - OT: Explain Where Mailing List Bouncing Comes From ?

  • I am also getting this, three or four times in the last month after years of no problems.

    I agree that Gmail is the likely common factor, but I would love to have access to these bounce messages to know whether it is actually an overly-paranoid list server!

    Steve

  • Me too, also gmail. I emailed the list owner a couple of days ago, but no reply.

    Is everyone else affected also forwarding to another email address
    (gmail or not)?

    Could be wrong, but I’m guessing there may be an incorrect DMARC
    policy somewhere – although this is the only fail I could find in the headers.

    bounces@lists.digium.com;
    dmarc

  • Not just gmail Happening as well with Comcast.net

    My Comcast address is set to forward to another domain, as Comcast seems to now block sending mail with a non Comcast “from” address. they turned that on a couple years ago with no notice.

    John Novack

    Jonathan H wrote:

  • Same about me – need to re-enable membership all the time. Annoying ((

    пн, 12 июн. 2017 г. в 15:59, John Novack :

  • We’ve seen this issue in the past on and off with a variety of random users. We were never able to pinpoint the issue.

    We’ll look into it again and see if we can find anything new. I’ve created a JIRA issue to track the issue for the moment. https://issues.asterisk.org/jira/browse/ASTERISK-27049

    Any further comments or information should go on that issue. Thanks!

  • Another “me too” (also Gmail).

    I just received my 4th “account suspended, too many bounces” email, after having several days of lost mailing list content over a short vacation break the last time. When I notified the admin email account of the failure, it seemed the responder missed the point about the emails, saying the link had expired (it had been more than three days since I had checked Gmail) – not seeming to notice that there was a problem with users having errant email bounce account suspensions.

    Whatever has been done, if anything, isn’t working effectively. At this point I’d like to see some response from the mailing list admin about any root-cause efforts, AFAIC this is starting to smear the Digium/Asterisk brand’s ability to handle IT related issues… No response = no confidence vote.

    -Tim

  • It’s hardly Digium’s fault, if Google have decided that playing nicely with syntactically-valid messages doesn’t fit their business model (which is to know everything about everyone; purely in order to push them the “right”
    advertisements, in spite of whatever uses less other actors with less benign intentions might make of this information, of course).

    The cure is to pay for a proper e-mail hosting service. “Free” services such as Gmail are overpriced.

  • Not really Gmail’s fault, either. Someone above said they had the same problem with Comcast.net.

    Gmail complies with the relevant RFCs just fine. It’s most likely simply because most people who use email, use Gmail.

    In addition, gmail properly implement SPF and DMARC checking.

    There’s over 1 billion gmail account as of 2016, so that’s why most people who are bouncing would be gmail.

  • Actually it is. They are pretending to send email from our/your/my emailadresses without taking the proper steps how to do this in a modern age.

    [snip google rant]

    DMARC reports inform me that most rejections come from Google (500+), Microsoft has far far less rejection (less than 10 IIRC), then comcast and some other mail providers. It is just that most people (choose) use Google, get over it.

    What Google (and many many others) is doing is for the benifit of reducing email spoofing and spam. Proper SPF/DKIM/DMARC are a must if you want to send mail to the big parties. The time you could simply run your own smtpd without any cares are long since gone, you need to comply to current SMTP related RFCs to get mail accepted.

    I’m still maintaining the idea that simply enabling DKIM signing on this list solves the problem. It is supported by the MTAs I can see in the headers and I linked to a howto in the past.

    But Digium doesn’t need to have this kind of knowledge, their business is not SMTP based but SIP based (and I think they are great at that business). But since the mailinglists are supplemental support services it would be in their best interest to fix this mess in some way.

  • Jonathan H wrote:
    Correct Had another one yesterday Am on several other mailing lists that have no such issue. Something related to the mailer Digium uses or their ISP

    John Novack

  • I’d hazard to say it probably is Digium’s “fault”, this was a recent and now consistent problem, which started within the last month or so. I’m on
    7 other Linux-related mailing lists which all use similar mailer daemons, and none have this issue. I have been subscribed to Asterisk Users/Developers for over two years without issue.

    Since the mailing-list system is seeing “bounces” on outbound, and I am not when transmitting INTO the mailing list – this tells me that outbound emails from the mailing-list system to Gmail are getting returned because of some characteristic (either content, TX security functionality, or mailer system configuration). Mail being sent by Digium (even as a conduit for user communications) can only be diagnosed by Digium. I’d imagine that if the mail admin looked at how many bounce emails have since been sent over time, there will be a spike that can be correlated to:
    * sender email addresses
    * email subject/body content,
    * a change they made in their system,
    * a change they were supposed to make to their system but failed to.

    And to the person who suggested using a non-free email, I do have those accounts on my own mail system – but I don’t use them for newsletters, re-occurring bulletins, or public Linux mailing lists where “everyone” is the receiver. Not good web hygiene IMHO – like a white picket fence around a yard, the general public can walk up and talk (to my Gmail), but I prefer to only let family and friends through the gate and in the front door
    (private email account). This also makes filtering and spam detection much easier while not sucking up my server time and storage space ;-).

    My other issue is the quarterly password email reminder where the password is sent in plain text… (facepalm). Probably why spam has been a problem on this board.

    -Tim

  • I’m not sure of the precise specifics of how Digium runs the list, but this sort of problem has been a “known issue” with mailing list distributions ever since SPF and similar technologies showed up, almost a decade ago. DomainKeys and DMARC makes it more of an issue, but the overall problem is not new.

    I had to switch mailing-list packages (from Majordomo to GNU Mailman)
    for the lists I run, and configure Mailman properly to avoid the worst of the problem.

    In my experience, the problems affect mailing lists where:

    – The mailing list software retransmits an incoming message to
    subscribers, using the same sender address (in the SMTP
    transaction and/or message headers) that the original sender used.

    and

    – The sending domain has some sort of anti-forgery technology in
    place – either SPF or DomainKeys can trigger the problem.

    When such a message is retransmitted, one of several things can happen when it hits a mail server that does anti-spoofing enforcement:

    (1) “Hmmm. This message says it comes from joe@example.com, but the
    example.com domain has an SPF record which says that only the
    following five IP addresses are authorized mailers for this domain,
    and suggests a policy of ‘reject’ for other IP addresses. This
    message is coming from an IP address which isn’t on that list.
    Reject it.”

    or

    (2) “Hmmm. This message says it comes from joe@example.com. It has
    a DomainKeys signature from that domain, which covers the sender ID,
    subject, and message body. The signature doesn’t match” [sotto
    voce, the Subject header was modified by the mailing list software
    to include the group name] “and example.com suggests rejecting
    messages which say they’re from example.com but have bad signature.
    Reject it.”

    There are almost certainly other, similar scenarios.

    As a result, messages of this sort will tend to “bounce” from hosts that implement forgery protection, and the mailing-list software will often react to a flurry of such bounces by unsubscribing the intended recipient from the list.

    None of the workarounds for this are perfect – they all have side effects.

    [A] Recipients who are being unsubscribed because gmail (e.g.) is
    bouncing such messages, can change their subscription to the
    mailing list to “daily digest”. Mailman (and I believe most other
    mailing list packages) send out digests as new messages, with their
    own domain as the return address, thus avoiding the problems.

    [B] For SPF, the mailing list software can be configured to “take
    ownership” of the message… rewriting the sender address into a new
    form which doesn’t break SPF rules. Examples for a message from
    joe@example.com might be

    Joe at example.com via Foobar mailing list
    Joe

    and so forth.

    GNU Mailman has the ability to do something along the lines of the
    first example. It’s the configuration I use on the small mailing
    list I run. I believe it also adds a Reply-To: header to the
    message to “point back to” the original sender.

    It’s possible to rewrite/substitute the message used in the SMTP
    session, but leave the original sender’s address intact in the
    message headers. This will be acceptable to many (but not all)
    systems that check SPF.

    [C] For DomainKeys… well, if the mailing list software is going to
    make any changes at all to the headers on messages it’s relaying,
    or change the message body at all, it should strip out any
    DomainKeys signature that might exist on the message.

    Or, it can send the whole inbound message (unmodified) as a MIME
    attachment within a new message it originates. This leaves the
    signature intact, but can be hard for many mail programs to handle
    gracefully.

    It would be up to Digium to do [B] and [C] for the mailing lists, if they so choose.

    Individual subscribers can do [A] to reduce the risk that they’ll be unsubscribed from the list whenever an SPF-protected message is sent through the list.

  • I believe that Digium is using Mailman already (hence the in-the-clear monthly password reminders). I suggest that whoever administers the Mailman system should probably be able to tell why Gmail is bouncing (sometimes), and if not, there’s plenty of active Mailman help available:

    Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3

    Adam Goldberg AGP, LLC
    +1-202-507-9900

    —–Original Message—

  • Whether it is intentional or not these messages railing against the list operators has a decided tone of condescension which is not warranted. The fact of the matter is that DMARC is broken by design and the unpleasant effects that adoption of it has on mailing-list traffic were well hashed out on the ITEF mailing lists before it was adopted anyway. What was predicted there has come to pass.

    DMARC conflicts with the existing SMTP RFCs in several ways, none of which I will elaborate here but all of which may be discovered by perusing the relevant threads on the ITEF mailing lists. Some mailing list management software, notably Mailman, since has been modified to
    ‘work around’ the problems with DMARC if so configured by the list owners. But only at the cost of violating the SMTP RFCs themselves. Do not take my word for it. Raise these issues on the Postfix mailing list and discover what response you get from Viktor and Wietse.

    The driving force behind DMARC was YAHOO’s shoddy security of their own users’ accounts. With Hotmail and similar ilk close behind. It is a completely inappropriate, and in my opinion ill-thought-out, technical solution to what is essentially an internal security problem at some email providers, albeit very large ones. In general it is an example of what is called ‘externalising your costs’.

    The appropriate answer has been provided: lose the gmail/hotmail/yahoo/freemail account and administer your own domain for personal email. Configure the spf and dkim settings on your own domain as required to suit your needs and not those of someone else.