On 05/26/2015 09:03 AM, EyeLand wrote:

postconf -n https://gist.githubusercontent.com/eyeland/c28256b0602679d4954d/raw/92e672f7... Mailman/mm_cfg.py https://gist.githubusercontent.com/eyeland/b3a2ede982b5db3ab3dc/raw/a1809682...

It looks like you are trying to follow the FAQ at <http://wiki.list.org/x/10715238>. Is there some reason you are doing this instead of just following the Debian docs?

What is the content of /var/lib/mailman/data/transport-mailman?

What are the Postfix log messages associated with the failed delivery?

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

On 05/26/2015 10:00 AM, EyeLand wrote:

/var/lib/mailman/data/transport-mailman https://gist.githubusercontent.com/eyeland/8836edc1edef4fb11ece/raw/c950ed0e...

I see two issues here:

First, entries like

mailman@list.mobilier.md local

should all be

mailman@list.mobilier.md local:

I.e., yours are all missing the : after local. See item 3) at <http://wiki.list.org/x/10715238> and compare that to your /etc/mailman/virtual_to_transport.sh.

More importantly, the undeliverable mail is addressed to mailman@list.ournet.biz, but the domain of the mailman list is list.mobilier.md.

The methods you are using only create the transport maps for the list's 'host_name' domain so Postfix can't deliver to the list @ a different domain.

Postfix log messages associated with the failed delivery is on file /var/log/mail.warn ?

/var/log/mail.log

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

On 05/26/2015 01:49 PM, EyeLand wrote:

/var/log/mail.log https://gist.githubusercontent.com/eyeland/84ca2edc3f07ca507a8d/raw/aae9c95e...

I see things like the following in the log.

May 26 14:44:30 vps1 postfix/local[12807]: 4B7BD80F0C: to=<mailman@vps1.ournet.biz>, relay=local, delay=0.37, delays=0.26/0.03/0/0.08, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post mailman)

This is a message To: mailman@vps1.ournet.biz which is delivered directly to mailman via the 'mailman' alias because vps1.ournet.biz is a local domain in Postfix, i.e., its in mydestination in Postfix.

May 26 14:44:50 vps1 postfix/smtpd[12792]: NOQUEUE: reject: RCPT from forward15o.cmail.yandex.net[37.9.109.212]: 550 5.1.1 <mailman@list.ournet.biz>: Recipient address rejected: User unknown in virtual mailbox table; from=<ournet-biz@yandex.com> to=<mailman@list.ournet.biz> proto=ESMTP helo=<forward15o.cmail.yandex.net>

This is a message to mailman@list.ournet.biz which is rejected because list.ournet.biz is not a Postfix local domain and the address mailman@list.ournet.biz is not mapped to the local transport in transport maps nor is it mapped to the local mailman address via virtual alias maps

May 26 14:45:25 vps1 postfix/local[12807]: 6460280F0C: to=<mailman@vps1.ournet.biz>, orig_to=<mailman@list.mobilier.md>, relay=local, delay=0.13, delays=0.05/0/0/0.07, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post mailman)

And this is a message to mailman@list.mobilier.md which is mapped to the local transport via transport maps and is thus accepted.

the main server domain is vps1.ournet.biz, secondary domains are test2.ournet.biz, list.ournet.biz, list.mobilier.md

You are using transport maps to map list addresses in non-local domains such as list.ournet.biz and list.mobilier.md to Postfix's local transport. The method you are using only generates mappings for the list's host_name domain which in the case of the mailman list is list.mobilier.md. Thus mail to mailman@list.mobilier.md is properly delivered to Mailman, but mail to mailman@list.ournet.biz is not deliverable because the address is not in transport maps or virtual alias maps and list.ournet.biz is not a local domain.

So the question is why are you trying to mail to mailman@list.ournet.biz in the first place. If you really want to be able to mail to mailman@ any of the domains, you could manually replicate the 'mailman' stanza in both data/virtual-mailman and data/transport-mailman changing the list.mobilier.md domain to list.ournet.biz in the replicated stanzas. That should work until you rebuild those files completely with bin/genaliases.

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

On 05/27/2015 12:35 AM, EyeLand wrote:

1. I want to receive mails to mailman@list.ournet.biz because subscribers view that email on info page http://r.ournet.biz/1Hue3k5

Yes, I understand. This is a situation that is not straightforward to deal with in installations with lists in multiple virtual domains. The mailman@domain address is displayed on admin and listinfo overviews with a domain based on the 'host' of the URL of the page which means ideally, the 'mailman' address should work in all supported domains, but Mailman's integration with Postfix doesn't do that.

Thinking about it, I have decided this is a bug. See <https://bugs.launchpad.net/mailman/+bug/1459236>.

2. today Mailman change file /var/lib/mailman/data/transport-mailman https://gist.githubusercontent.com/eyeland/5f2017044013cd94ffe2/raw/907d4860... and I not see now on file mailman@list.mobilier.md <mailto:mailman@list.mobilier.md> anyway that mail work fine

It looks like you ran bin/genaliases and before doing so, you changed the host_name attribute of the 'mailman' list so it is no longer either list.ournet.biz or list.mobilier.md.

3. I test again mailman@list.mobilier.md, mailman@vps1.ournet.biz, mailman@list.ournet.biz and mails to mailman@list.mobilier.md and mailman@vps1.ournet.biz was redirect to mailman@vps1.ournet.biz control panel Mailman http://vps1.ournet.biz/cgi-bin/mailman/admin/mailman, but mail sent to mailman@list.ournet.biz generate error https://gist.githubusercontent.com/eyeland/172404219786ce7902fc/raw/5f52e7fb...

The real question here is how is mail to mailman@list.mobilier.md being delivered. I suspect that address is in a virtual mapping somewhere. Your postconf -n shows

virtual_alias_maps = hash:/var/lib/mailman/data/virtual-mailman, proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, proxy:mysql:/etc/postfix/mysql-virtual_email2email.cf

Since you apparently ran genaliases and mailman@list.mobilier.md is not in your transport maps, it also isn't in /var/lib/mailman/data/virtual-mailman, but it may still be in /var/lib/mailman/data/virtual-mailman.db because your postfix map command doesn't update it.

This then again raises the question of why you are doing all the transport maps stuff at all when the straightforward virtual_alias_maps will apparently work

4. I create mailman lists on control panel ISPconfig, maybe the problem is on another place?

If you are dealing with control panels, you should take those issues to the people who provide them.

I will fix the bug at <<https://bugs.launchpad.net/mailman/+bug/1459236>> and provide a patch here when I do.

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

On 05/27/2015 08:09 AM, EyeLand wrote:

Maybe these files help for solve the bug

/var/lib/mailman/data/virtual-mailman https://gist.githubusercontent.com/eyeland/c4095804712e4af3f892/raw/88c951b3...

The bug is fixed. The attached patch to Mailman/MTA/Postfix.py will fix it. If you apply that patch and rerun bin/genaliases, it will add entries for the mailman@list.ournet.biz and mailman@list.mobilier.md addresses to data/virtual-mailman.

that is right on file /var/lib/mailman/data/virtual-mailman.db I found mailman@list.mobilier.md <mailto:mailman@list.mobilier.md>

So again, standard Mailman-Postfix integration without transport maps does appear to work in your case. That means you can remove

POSTFIX_MAP_CMD = '/etc/mailman/virtual_to_transport.sh'

from mm_cfg.py and change

transport_maps = hash:/var/lib/mailman/data/transport-mailman, proxy:mysql:/etc/postfix/mysql-virtual_transports.cf

in postfix/main.cf to just

transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf

and thus simplify your Postfix config and make it more standard, although it will continue to work as you have it.

Also the mm_cfg.py you posted previously does not contain the lines

add_virtualhost('list.ournet.biz', 'list.ournet.biz') add_virtualhost('list.mobilier.md', 'list.mobilier.md')

and it should.

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

On 06/04/2015 08:05 AM, EyeLand wrote:

2015-05-27 18:38 GMT+03:00 Mark Sapiro <mark@msapiro.net <mailto:mark@msapiro.net>>:

The bug is fixed.

I not have a pro on Debian, can you write a step by step instruction for resolve that issue with your recommendations?

If you still have the message you quote above, there was a file Postfix.py.patch.txt attached to that message.

Save that file somewhere and then run

patch /usr/lib/mailman/Mailman/MTA/Postfix.py < /path/to/saved/file

where /path/to/saved/file is the actual path to the patch file you saved.

If for some reason, you don't have that patch file or have difficulty with the 'patch' command, you can go to <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/Mailman/M...> and click the 'download file' link and then just copy the downloaded file to /usr/lib/mailman/Mailman/MTA/Postfix.py

After doing one or the other of the above, run Mailman's

bin/genaliases

to recreate the aliases and virtual mappings. You don't need to restart Mailman before running bin/genaliases, but it won't hurt if you do.

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