[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: is exim attempting to relay ???

"Michael D. Schleif" <mds@helices.org> writes:
> However, correct me if I'm wrong, it looks to me that -- initially --
> fetchmail gets an email message from one of my many remote mail servers,
> and passes it off to exim for local processing.
> The To: header is mangled, and noted, and 550 is returned.
> Then, somehow -- this is the part that I do not understand, and that I
> want to *STOP* happening -- FETCHMAIL-DAEMON@bragi.private.network
> attempts to send an email -- containing this 550 error -- to some
> address unknown to me.  Note: the URL is only one (1) of many
> _different_ examples I am seeing.

Keep in mind that there are SMTP envelope MAIL FROM and RCPT TO
addresses that often get stripped even from the "full" headers of a
message.  If they do appear, they will appear as "Return-Path" and
"Envelope-To" respectively.

In this case, it appears that the original message was sent with
envelope headers indicating a mail from <sophie.bourcier@wanadoo.fr>
and to <mds@helices.org>, but the actual "From" and "To" headers were
garbage.  Nonetheless, the mail server at "helices.org" accepted it
for delivery to the "mds" mailbox.

When your "fetchmail" (on "bragi", I gather) ran to grab mail from
your <mds@helices.org> mailbox, it ran across this message and
attempted it to deliver it via SMTP to the local mail server on
"bragi".  But "bragi"'s server didn't like the empty "To" header and
complained with a 550 error, so "fetchmail" tried to bounce the error
message back to the envelope "from" address, namely

It tried to send this bounce by connecting to your localhost's SMTP
port (on "bragi") and sending a bounce with an envelope indicating a
mail from <FETCHMAIL-DAEMON@bragi.private.network> and to
<sophie.bourcier@wanadoo.fr>.  Unfortunately, the "exim" on "bragi"
wasn't configured to rewrite the envelope "from" address of the
FETCHMAIL-DAEMON to something more useful.  It passed it on to "trout"
which passed it on to the qmail server on "mail.private.network", and
qmail attempted to deliver it via SMTP to the mail server on
"smtp.wanadoo.fr".  That host bitched about the invalid envelope
"from" address (because "bragi.private.network" is clearly invalid
outside your private network) during the SMTP exchange with
"mail.private.network", so "mail.private.network" tried to bounce it
back to <FETCHMAIL-DAEMON@bragi.private.network>.

To do this, it contacted the SMTP server on "bragi.private.network",
but "bragi" didn't have an account or matching alias for
"FETCHMAIL-DAEMON", so it refused the message.

The "qmail" program on "mail.private.network" was so fed up at having
its bounce bounce that it mailed the postmaster in frustration.

Got that?

You can easily head this off at the pass by passing "fetchmail" the
"--nobounce" command line option.  With this option, it'll just send
bounces to the postmaster on "bragi" instead of trying to deliver them
back to the message sender.

Kevin <buhr@telus.net>

Reply to: