On 16-Feb-00 at 17:15:22 Philip Hazel wrote:
> On Wed, 16 Feb 2000, John Horne wrote:
>> If the local (to us) user then forwards the message to one or more
>> people (which all go via the mailhub), and that new recipient may or
>> may not forward it again to one or more people, then if one of the new
>> recipients is an unknown user the mailhub sends the failure message
>> back to the very original sender - who obviously has no idea about the
>> failed user and never sent the message to them in the first place!
>
> This is a general problem with forwarding. There is no sensible answer.
> If A sends a message to B and B forwards to C but C does not exist, what
> should you do? I maintain that the only thing you can do is to tell A.
> At least she knows her message didn't get through.
>
But A didn't send the message to C; doesn't know who C is; and doesn't care
if they got the message or not. A only cares about B.
> Some people say you should put it in B's mailbox, ignoring the
> forwarding, but that doesn't seem sensible to me. B thinks nothing is
> going there, and won't look at it. You just waste disc space. Also,
> there is the case when B's account doesn't exist any more, but there's
> courtesy forwarding going on.
>
Point taken, and I would agree with you (which makes it all the more
confusing on deciding what to do since I would at first say send the message
to B!). However, in our case, and as pointed out by Jonathan Hunter,
'forwarding' here is referring to the user actually reading the message and
deliberately clicking the 'forward' button to send the message to another
user. I should have pointed that out. Users here, on the file servers, have
no '.forward' file and, hence, no forwarding (or courtesy forwarding) as
such. (Actually we do provide this but it is all through the mailhub, so any
mistake is due to the postmasters.)
In the light of that, and since mail to/from the file servers must go via
the mailhub, we could probably safely send the message back to B since any
'forwarding' would have to be done on the mailhub and thus the delivery
failure *would* be sent back to B's correct address - that is, it wouldn't
just be dumped in their mailbox ignoring any forwarding.
> What you could do is to arrange for errors to go to B's postmaster,
> assuming that they are prepared to handle this particular load.
>
...those postmasters are us I'm afraid. We handle mail errors on the file
servers.
>> We (the postmasters) then get the message sent back to us asking why we
>> had sent them a failure message about someone they don't know.
>
> At least some humans get involved and can sort the mess.
>
Trying to, trying to :-)
>> This has worked well for a long time now, but I am wondering if the
>> smartuser director needs a 'new_address' setting and if so, would the
>> $reply_address or $return_path be better?
>
> Er, "new_address" changes the *recipient* address. Do you mean
> "errors_address"?
>
No, I want to modify the envelope RCPT TO on the delivery failure message
sent out. So, I assume, I can specify this address in the smartuser director
and use the $reply_address which is the address (taken from Resent-from:,
From: header) of the user who sent the message (i.e. the user on the file
server) isn't it? E.g.: new_address = $reply_address
From Jonathan's reply $return_path seems to be definitely out.
>> My understanding is that the transport should be using the message
>> headers (which is the $reply_address) to send the failure message back,
>
> NO! NO! Only the envelope sender address ($sender_address) is ever used
> for sending bounce messages. What is in the headers is not relevant.
>
Apologies again, I meant that perhaps that is how we should be configuring
it, not that exim does this (or should be doing this) by default. (Although
that would be fun eh?? :-) )
>> Despite all of that, I thought that the message should have gone back to
>> the Resent-from: header address, which is a local user.
>
> Definitely not. MTAs work on envelopes only.
>
Yes, but I would have thought that the file server had set the envelope from
as itself. In that case there would at least be a correspondence between the
sender and the Resent-from: header - i.e. they are both from the file
server. And in that case the message should have gone back to the file
server; but it didn't. (I know this correspondence cannot be relied on, but
in this case it would be pretty safe since the file servers do no complex
header rewriting).
John.
--------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: jhorne@???
Finger for PGP key: john@???
