Milter protocol deleting and adding the same recipient

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Milter protocol deleting and adding the same recipient

Mehmet Avcioglu

Hello,

It looks like there is difference in postfix implementation of milter protocol regarding adding and deleting recipients compared to sendmail.

The following results in one final recipient on sendmail but no recipients on postfix while still logging nrcpt=2

  del_rcpt "<[hidden email]>"
  add_rcpt "[hidden email]"
  del_rcpt "<[hidden email]>"
  add_rcpt "[hidden email]" 

Jun 28 16:15:00 server postfix/smtpd[264815]: connect from server.local[127.0.0.1]
Jun 28 16:15:14 server postfix/smtpd[264815]: 49vrhL14pvzBGTn: client=server.local[127.0.0.1]
Jun 28 16:15:21 server postfix/cleanup[264963]: 49vrhL14pvzBGTn: message-id=<[hidden email]>
Jun 28 16:15:21 server postfix/qmgr[264819]: 49vrhL14pvzBGTn: from=<[hidden email]>, size=378, nrcpt=2 (queue active)
Jun 28 16:15:21 server postfix/qmgr[264819]: 49vrhL14pvzBGTn: removed
Jun 28 16:15:22 server postfix/smtpd[264815]: disconnect from server.local[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5

From what I understand the duplicate filter suppresses the address. Is this desired behavior?

Thanks

--
Mehmet
Reply | Threaded
Open this post in threaded view
|

Re: Milter protocol deleting and adding the same recipient

Wietse Venema
Mehmet Avcioglu:

> Hello,
>
> It looks like there is difference in postfix implementation of milter
> protocol regarding adding and deleting recipients compared to sendmail.
>
> The following results in one final recipient on sendmail but no recipients
> on postfix while still logging nrcpt=2
>
>   del_rcpt "<[hidden email]>"
>   add_rcpt "[hidden email]"
>   del_rcpt "<[hidden email]>"
>   add_rcpt "[hidden email]"
>
> Jun 28 16:15:00 server postfix/smtpd[264815]: connect from
> server.local[127.0.0.1]
> Jun 28 16:15:14 server postfix/smtpd[264815]: 49vrhL14pvzBGTn:
> client=server.local[127.0.0.1]
> Jun 28 16:15:21 server postfix/cleanup[264963]: 49vrhL14pvzBGTn:
> message-id=<[hidden email]>
> Jun 28 16:15:21 server postfix/qmgr[264819]: 49vrhL14pvzBGTn: from=<
> [hidden email]>, size=378, nrcpt=2 (queue active)
> Jun 28 16:15:21 server postfix/qmgr[264819]: 49vrhL14pvzBGTn: removed
> Jun 28 16:15:22 server postfix/smtpd[264815]: disconnect from
> server.local[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>
> From what I understand the duplicate filter suppresses the address. Is this
> desired behavior?

Well we can't simply turn off duplicate filter when a recipient is
added (back) by a milter.

Incorrect solution:

Suppose you have an alias expansion:

    [hidden email] -> [hidden email], [hidden email], [hidden email]

You delete [hidden email] from the queue file, and then disable
the duplicate filter while adding it back with a milter.

Then, adding [hidden email] back would result in another alias
expansion:

    [hidden email] -> [hidden email], [hidden email], [hidden email]

and because the duplicate filter is turned off, all addresses would
be added again to the queue file. That is annoying when the alias
is small, but could be bad if there alias is large.  Postfix should
work for 'small' and 'large' alias expansions.

Also incorrect solution:

An alternative, disabling alias expansion AND duplicate filtering
while adding a recipient by milter, would break Postfix compatibility
for cases where people rely on virtual alias expansion of recipients
added by a milter.

Correct solution:

The correct fix would that the 'delete recipient' method reads the
to-be-deleted recipient from the queue file, and then requests that
the address be removed from the duplicate filter.

Then, adding back [hidden email]  will produce the expected result:
a new [hidden email] recipient and no duplicate [hidden email]
or [hidden email] address.

        Wietse