MEMO RESENT with minor corrections -----Message d'origine----- De : Jacques Setton [mailto:jsetton@waycast.com] Envoyé : vendredi 21 mars 2014 00:26 À : 'Mark Sapiro' Cc : 'mailman-users@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@domain.info and testlist-request@domain.info ) are systematically diverted to the previously specified default account admin@domain.fr . Whereas messages addressed to standard email accounts (for ex. admin-lists@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@waycast.com

-----Message d'origine----- De : Mark Sapiro [mailto:mark@msapiro.net] Envoyé : vendredi 14 mars 2014 03:13 À : mailman-users@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@domain.net by admin-europe@waycast.eu is finally delivered to the default account admin@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@domain.net> to to=<admin@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@domain.net to admin@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@domain.fr kluser admin@domain.fr postmaster admin@domain.fr root admin@domain.fr anonymous admin@domain.fr drweb-daemon admin@domain.fr mailer-daemon admin@domain.fr

---

[root@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@waycast.eu>, size=17420, nrcpt=1 (queue active)

Mar 11 23:14:57 vps129345 postfix/smtp[19770]: 1A52911616E: to=<admin@domain.fr>, orig_to=<mylist@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@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@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@domain.net mylist

...

With VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost', these should be mylist@domain.net mylist@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan