On 28 Apr 1998, Rob Browning wrote:
>
> 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
That suggests that the message was addressed to <@localhost> rather than
<notarealaddress@localhost>. Are you sure there wasn't a space
inadvertantly inserted in your command line?
> 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.
All error messages always have a null sender (i.e. return path) in the
envelope. See RFC 821. However, you can configure Exim not to insert
Return-path headers if you want to. Check out the appendfile transport.
> 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).
I think something else is going on here, actually. The mangling of the
address is suspicious.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
--
*** Exim information can be found at
http://www.exim.org/ ***
