On Tue, Feb 03, 2015 at 03:45:21PM -0500, Wietse Venema wrote:
> System Support:
> > Feb 3 14:00:45 Falcon postfix/cleanup[10511]: A450A139221:
> > message-id=<54d11add.13406.1e4...@editor.wpny.us>
> > Feb 3 14:00:45 Falcon postfix/qmgr[9871]: A450A139221:
> > from=<edi...@wpny.us>, size=717, nrcpt=1 (queue active)
> > Feb 3 14:00:45 Falcon postfix/local[10512]: A450A139221:
> > to=<w...@maila.myserver.com>, orig_to=<WPNY>, relay=local, delay=0.12,
> > delays=0.08/0.01/0/0.03, dsn=2.0.0, status=sent (forwarded as B7B19139238)
>
> Viktor drew my attention to the "orig_to=<WPNY>" part of the logging.
>
> This looks like a bug that I fixed last October (change date:
> 20141024).
>
> Your list manager is configured to send mail to "WPNY" (no domain).
>
> If you could change this to send mail to "w...@maila.myserver.com",
> then that could take care of the "missing @domain" problem.
>
> On the other hand, if the problem is with missing domains in the
> email message content, that will have to be fixed at the source.
Perhaps making sure that the sending client matches
$local_header_rewrite_clients
http://www.postfix.org/postconf.5.html#local_header_rewrite_clients
might help, by qualifying the original input address with @$myorigin.
Something like:
local_header_rewrite_clients = permit_mynetworks
or similar, might do the trick. This would address unqualified
addresses in message headers, not sure how this interacts with DSN
"ORCPT".
--
Viktor.
