postfix-mailman: use of name+virtual@host fail since plesk 12

[Doeff_John]

Hello.
I'm migrating my mailman lists from a plesk 11.0.9 Ubuntu 12.04
to a Plesk 12.0.18 Ubuntu 14.04
Some of my lists which are functional on box 1 ( plesk 11 ) fails on box2 ( plesk 12 )
Those lists have a particularity: their names are [email protected] & [email protected]
It may sound rare, but the "+" sign in mail adress is totally licit.
Mailman is handling them flawlessly, plesk 12 seems to strip it from the mail adress, thus causing the postfix-mailman executable to fail like so:
--------------
<[email protected]>: Command died with status 1:
"/usr/lib/plesk-9.0/postfix-mailman". Command output: post script, list not
found: lista
---------------

I'm pointing here plesk 12 responsability because using those type of names for mailing list work flawlessly on Plesk 11.

/usr/lib/plesk-9.0/postfix-mailman seems to be the same on both hosts.

Where should I look for?
Thank you very much for your attention, and eventually giving me a pointer on that.
b.

 

[UFHH01]

Hi Doeff_John,

you are correct, some symbols are possible when you use maling lists, but if you use sciprts, which parse as well commands, then this usage can result in failures, if you use a symbol like "+" or several other possible symbols. Please stick to alphabetic letters and latin numbers, in possible combination with "-" and/or "_" only, to avoid failures.

 

[Doeff_John]

Well, not even close.
For future use / or people bumping in the same problem.
- Mark Sapiro ( mailman creator ) nailed it in like 5 sec -
There had been a change in postfix bundled with plesk or was it in last postfix version ( ? ):
---------------------
edit /etc/postfix/main.cf
- find conf directive named " recipient_delimiter "
- default conf found: " recipient_delimiter = + "
- simply remove the "+"
- save and reload postfix.
----------------------
And i'll let here some RFCs to my dear UFHH01 product expert,
Particularly this passage: " These quoted
forms are rarely recommended, and are uncommon in practice, but, as
discussed above, must be supported by applications that are
processing email addresses"
And that's exactly what postfix did: it forwarded 0+blah@ -> 0@

http://tools.ietf.org/html/rfc3696
"
Klensin Informational [Page 5]


RFC 3696 Checking and Transformation of Names February 2004


The exact rule is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character. For example

Abc\@[email protected]

is a valid form of an email address. Blank spaces may also appear,
as in

Fred\ [email protected]

The backslash character may also be used to quote itself, e.g.,

Joe.\\[email protected]

In addition to quoting using the backslash character, conventional
double-quote characters may be used to surround strings. For example

"Abc@def"@example.com

"Fred Bloggs"@example.com

are alternate forms of the first two examples above. These quoted
forms are rarely recommended, and are uncommon in practice, but, as
discussed above, must be supported by applications that are
processing email addresses. In particular, the quoted forms often
appear in the context of addresses associated with transitions from
other systems and contexts; those transitional requirements do still
arise and, since a system that accepts a user-provided email address
cannot "know" whether that address is associated with a legacy
system, the address forms must be accepted and passed into the email
environment.

Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters

! # $ % & ' * + - / = ? ^ _ ` . { | } ~

period (".") may also appear, but may not be used to start or end the
local part, nor may two or more consecutive periods appear. Stated
differently, any ASCII graphic (printing) character other than the
at-sign ("@"), backslash, double quote, comma, or square brackets may
appear without quoting. If any of that list of excluded characters
are to appear, they must be quoted. Forms such as

[email protected]"