[Mailman-Users] Correct Mailman setup

[tlhackque]

On 22-Sep-17 16:50, Mark Sapiro wrote:
> At Fri, 22 Sep 2017 17:57:36 +0200 luscheina at yahoo.de wrote:
>>>
>>> Hi all
>>> [Snip]
>>> , but every now and then some people
>>> complain about something. The most annoying thing is that messages are
>>> processed but then queued for up to one hour before they go out. The
>>> mail system is on the same virtual server, and the provider has no idea
>>> what to do. Otherwise the mail server does not ause problems, any
>>> message submitted normally (not via Mailman) goes out nearly instantly. 
>>> I would appreciate if a knowledgeable person could guide me through the
>>> proper setup of these lists.
> [Snip]
>
> What I can tell you is there is nothing in normal list configuration
> that would cause delays in outgoing mail. The most likely cause of these
> delays is Mailman's 'out' queue being backlogged. There are multiple
> posts about this in this list's archives including
> <https://mail.python.org/pipermail/mailman-users/2016-July/081121.html>.
> There is also a FAQ at <https://wiki.list.org/x/17892002>.
>
> One thing you can check is if posts are archived almost immediately even
> though they aren't sent out for some time. This indicates a possibly
> backlogged 'out' queue or possibly other delays in outgoing mail. If the
> posts are not archived until they are ultimately sent out, that would
> indicate the delay is in incoming mail.

> It is also possible the outgoing mail server is throttling mail, i.e.
> limiting the number of messages sent per hour or some such.
Another common cause is that the RECEIVER is using 'greylisting'.  This
is an anti-spam
technique that some believe is effective.  The receiver sends a
"temporary failure"
when e-mail is received from an unknown or "suspicious" source.  If the
sender retries
in a "reasonable" window, it goes through.  Typically a delay of 15-30
minutes but not
more than a few hours works.  The theory is that spammers won't bother
to retry.
Usually subsequent e-mails from the same source go through without delay
- for a while.

Also, MTAs have timeouts - a common configuration is for the sending MTA
to attempt
sending with a short timeout for connect/greeting/helo response.  If
this times out,
the message is queued for a later attempt with longer timeouts.  The
reasons are that
some RECEIVERs intentionally delay responses to SMTP commands in the
belief that
spammers won't wait (or retry).  The sending MTAs with dual timeouts
don't want
these receivers to slow delivery to "normal" destinations.

If either of these is the case, the sending MTA may be running its queue
hourly.
Running it every 30 minutes may help.  Contacting the receivers to
whitelist your
sending IP may help. 

And there are various e-mail reputation services that will whitelist (or
blacklist)
senders.  Whitelisted senders may bypass greylisting.

All these are under the control of the operator of your sending MTA;
they happen
after Mailman has queued the mail.

For more on greylisting, see https://www.greylisting.org/ (or just do a
web search
on e-mail greylisting.
> The bottom line is if the hosting service won't help you with this,
> you're stuck. 
Unless you find someone willing to let you use a better-configured outgoing
mail server, or you run your own (which is not for the faint-hearted).

> You might find
> <https://wiki.list.org/DOC/Mailman%20and%20CPanel> of some interest.
>
> If there are other issues/complaints, please describe both the current
> and desired behaviors, and perhaps we can offer more advice.
>