If I log in as any user on my machine and send a message to a bogus
address like so:
$ mail -s bogus notarealadddress@localhost < /dev/null
and then try to get the mail with fetchmail, the local exim chokes on
the (exim generated) bounce message:
$ fetchmail localhost
Enter password for stray@localhost:
fetchmail: 1 message for stray at localhost.
reading message 1 of 1 (512 header bytes) fetchmail: SMTP error: 501 <@localhost> : colon expected after route
fetchmail: SMTP error: 501 <stray> : sender address must contain a domain
fetchmail: SMTP transaction error while fetching from localhost
This seems to be because exim has inserted a header
Return-path: <>
Into the bounce message from MAILER-DAEMON that's waiting in the
queue. According to the info pages, this should only happen if you
use "-f <>" as an untrusted user. Perhaps /usr/bin/mail does that.
In any case, I was a little surprised exim couldn't handle its own
bounce messages (when handed back to it through fetchmail).
Note that I think this might not be a completely esoteric situation.
It should happen any time someone tries to retrieve bounce messages
generated on a remote (exim based) host to a local exim based host via
fetchmail.
Is this expected behavior, and is there a good solution?
Thanks
--
Rob Browning <rlb@???>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
*** Exim information can be found at
http://www.exim.org/ ***
