[asterisk-users] OT: Explain where mailing list bouncing comes from ?

[Adam Goldberg]

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 at 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-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Dave Platt
Sent: Friday, June 16, 2017 1:34 PM
To: asterisk-users at lists.digium.com
Subject: Re: [asterisk-users] OT: Explain where mailing list bouncing comes from ?

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 at 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 at 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 at example.com might be

       Joe at example.com via Foobar mailing list <foobar at mailer.com>
       Joe <joe-at-example-dot-com at rewritten.mailer.com>

    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.


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
      https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users