[Mailman-Users] Messages addressed to Mailman lists are systematically diverted to predefined default email account

Fri Mar 21 00:54:23 CET 2014

MEMO RESENT with minor corrections 
-----Message d'origine-----
De : Jacques Setton [mailto:jsetton at waycast.com] 
Envoyé : vendredi 21 mars 2014 00:26
À : 'Mark Sapiro'
Cc : 'mailman-users at python.org'
Objet : RE: [Mailman-Users] Messages addressed to Mailman lists are
systematically diverted to predefined default email account

Hi Mark,

Thank you for your appreciated comments to which I responded individually :
see the embedded annotations further below...

I did modify some of the parameters you  highlighted. Unfortunately, at best
the previously observed problem still persists despite the modifications
made. In other instances, some modifications cause the alteration of
Postfix' operation which results in a non-delivery of all emails...

To further investigate the issue, I have decided to use two separate domains
attached to same VPS machine as follows :

1) 'domain.info' for incoming & outgoing messages addressed to and from
mails solely related to Mailman lists.

2) 'domain.net' for all non-Mailman lists incoming & outgoing regular
messages.  

The test results show - see the 1st attachment - that all messages addressed
to Mailman accounts (like testlist at domain.info and
testlist-request at domain.info )  are systematically diverted to the
previously specified default account admin at domain.fr . Whereas messages
addressed to standard email accounts (for ex. admin-lists at domain.net ) get
through without any problem...

In conclusion, it turns out that even domain differentiation does not solve
the problem. It thus seems as if  Plesk's supervision of Postfix does not
cope well with the standard operation Mailman's lists. 

This is very puzzling as Parallels claims that Mailman is officially
supported by Plesk V10+ . On such configured systems, Mailman is even
activated directly from Plesk's Control Pannel - see their Manual section
about this in the second attachment.

So my ultimate question will simply be : has anyone ever succeeded in
adequately deploying Mailman over a Plesk-based Linux server ? If this is
the case, I would invite anyone who has done it before to let us know how
they managed to make it work as expected.

Many thanks in advance for your and others help on this, as I have spent an
enormous amount of time trying to resolve the case without any success so
far...

Kind regards,

 Jacques Setton
 jsetton at waycast.com  

-----Message d'origine-----
De : Mark Sapiro [mailto:mark at msapiro.net] Envoyé : vendredi 14 mars 2014
03:13 À : mailman-users at python.org Objet : Re: [Mailman-Users] Messages
addressed to Mailman lists are systematically diverted to predefined default
email account

On 03/13/2014 11:59 AM, Jacques Setton wrote:
> 
> For example, in the below maillog trace we see that the memo initially 
> addressed to myslist at domain.net by admin-europe at waycast.eu is finally 
> delivered to the default account admin at domain.net instead of being 
> processed by '/usr/lib/mailman/mail/mailman post mylist' as it should 
> normally be the case :

>> But we don't see why? Strangely enough, there is no Postfix log entry
saying anything about the redirect from orig_to=<mylist at domain.net> to
to=<admin at domain.fr>. Also, there is a 2 and a half minute delay between
receipt of the message and delivery (delays=0.1/0.01/60/90) of which 60
seconds is connection setup time including DNS, HELO and TLS; and 90 seconds
is message transmission time. Does this seem OK?

I am not sure why there a such long delay before mail rejection and
rerouting. As previously indicated, this behavior seems to result from an
non recognition of a Mailman related recipient account which requires a
different treatment, as opposed to standard user email accounts.

>> Anyway, this can occur if there is a virtual mapping from 
>> mylist at domain.net to admin at domain.fr that is taking priority over 
>> /etc/mailman/virtual-mailman

To my knowledge, such mapping is not established. The only mapping that I am
aware of, in this respect, is one depicted in the 'aliases' file located in
the /var/spool/postfix/plesk directory and which contains the following
mapping :
 drweb	admin at domain.fr 
 kluser	admin at domain.fr 
 postmaster	admin at domain.fr 
 root	admin at domain.fr 
 anonymous	admin at domain.fr 
 drweb-daemon	admin at domain.fr 
 mailer-daemon	admin at domain.fr 

> - - -
> [root at vps12345 ~]# more /usr/local/psa/var/log/maillog | grep 
> 1A52911616E
> 
> Mar 11 23:12:27 vps12345 postfix/smtpd[19763]: 1A52911616E:
> client=relay6-d.mail.gandi.net[217.70.183.198]
> 
> Mar 11 23:12:27 vps12345 postfix/cleanup[19767]: 1A52911616E:
> message-id=<!&!AAAAAAAAAAAYAAAAAAAAAHqVdj4TMlNNnKyTMxcTrDTCgAAAEAAAABD
> lMhHAh
> X9PqvkRNi1Uq10BAAAAAA==@waycast.eu>
> 
> Mar 11 23:12:27 vps12345 postfix/qmgr[19671]: 1A52911616E:
> from=<admin-europe at waycast.eu>, size=17420, nrcpt=1 (queue active)
> 
> Mar 11 23:14:57 vps129345 postfix/smtp[19770]: 1A52911616E:
> to=<admin at domain.fr>, orig_to=<mylist at domain.net>, 
> relay=mx1.ovh.net[213.186.33.29]:25, delay=150, delays=0.1/0.01/60/90, 
> dsn=2.0.0, status=sent (250 ok 1394576096 qp 28763)
> 
> Mar 11 23:14:57 vps12345 postfix/qmgr[19671]: 1A52911616E: removed
> 
> [root at vps12345 ~]#
> 
> - - -
> 
> Despite skimming through this Mailman-Users list and many other source 
> publications, I haven't yet been able to figure out the exact origin 
> of this abnormal behavior. Though I suspect a poorly defined Postfix
'transport'
> specification (see item 7 further below), but this remains to be
confirmed.

>> The transport involved should be local.

I have removed all transport definitions, meaning that we fallback to the
default values applied for Postfix.

> Please note that I am using a hosted VPS running CentOS with, among 
> other things, Plesk, Postfix and Mailman. All software versions and 
> configuration details are communicated below. Another piece of useful 
> information : the 'admin at domain.fr' default account has been specified 
> at Plesk's web admin interface level.

>> See the FAQ at <http://wiki.list.org/display/DOC/Mailman+and+Plesk>

I have already seen this as well as other published docs, and have applied
all the recommendations applicable to using Mailman with Plesk, including
the related Admin Guide.

> 2.      Mailman Configuration File relevant excerpts (mm_cfg.py located in
> /usr/lib/mailman/Mailman/)
> 
> { . }
> 
> DEFAULT_URL_HOST   = 'lists.vps12345.ovh.net'
> 
> DEFAULT_EMAIL_HOST = 'vps12345.ovh.net'
> 
> MTA = 'Postfix'
> 
> VIRTUAL_HOSTS.clear()
> 
> add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
> 
> add_virtualhost('lists.domain.net', domain.net')
> 
> POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain.net']
> 
> VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost'

>> You may or may not need this, but if you do, you may need Mailman's
bin/genaliases to update virtual-mailman.

I have removed the 'VIRTUAL_MAILMAN_LOCAL_DOMAIN' above setting.

> # STANZA START: mylist
> 
> # CREATED: Mon Feb 24 21:00:44 2014
> 
> mylist at domain.net              mylist

>> With VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost', these should be
>> mylist at domain.net              mylist at localhost
>> and so on.

This is no longer applicable, since I am no longer using the
'VIRTUAL_MAILMAN_LOCAL_DOMAIN' setting.
However, after removing this parameter, no improvement was noticed...

> # *** Added 'virtual-mailman' reference in 'virtual_alias_maps'
> 
> virtual_alias_maps = $virtual_maps,
> hash:/var/spool/postfix/plesk/virtual,
> hash:/etc/mailman/virtual-mailman

>> virtual_alias_domains = domain.net

When I apply this setting, the regular Postfix mail operation stops to
function while this still does not resolve the previously reported
problem... 

> # *** Added Postfix Transport location to 'transport_maps' parameter

>> Why? This is probably only for postfix_to_mailman.

I am not using the postfix_to_mailman scheme. The related section was/is
left commented in the 'master.cf' configuration file.

> virtual_transport = plesk_virtual

>> This makes plesk_virtual the transport for all virtual mailbox domains.

For normal mail operation, the transport has to be 'plesk-virtual' (see the
1st attached document). Otherwise, I don't see what else could be specified
here which won't break the normal mail operation...

> plesk_virtual_destination_recipient_limit = 1
> 
> mailman_destination_recipient_limit = 1

>>This is for postfix_to_mailman

As previously indicated, we are not using the 'Postfix_to_Mailman' scheme.
Hence, this parameter has been dropped, however without seeing any
improvement of the original problem. 

> 7.       Postfix Added Transport Table scheme (transport and transport.db
> located in /etc/postfix/)
> 
> The below-specified transports remained commented out because they 
> cause a transport failure when uncommented. It seems that the 
> specifications used are probably invalid. These will need to be 
> reworked and we'd welcome suggestions as to what to specify instead...

>> See the FAQ at <http://wiki.list.org/x/EYDt>, in particular the paragraph
postfix_to_mailman.py is an alternative to and is incompatible with Mailman
delivery via aliases. If you are configuring both Mailman aliases and
postfix_to_mailman.py, you are making a mistake.

I have read mots FAQs on the subject and followed all related
recommendations. In addition, I restate that it was not, and is still not,
our intention to use the 'postfix_to_mailman.py' scheme...  

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan