On Sat, 20 Apr 2002 21:19:12 +1000
Martijn van Oosterhout <kleptog@svana.org> wrote:
> > > at the right place. i.e. you don't need to know the mail domain to
> > > send a mail to the local user.
> >
> > In that case, the mail message should *never* leave the local
> > domain.
>
> And if the target user has a .forward file? Are you suggesting the
> mailer bounce the message instead?
In that case, assuming the forwarding address is outside the domain, the
message would then be leaving the domain, and would need a correct From:
line ([EMAIL PROTECTED]). No bouncing involved.
My point is: The From: address rewriting should be done *only* on the
originating side, *never* when the message is in transit or arriving at
the destination.
> So the bug lies with the original transmitter, not with the receiving
> mailer. And what have you lost? If it hadn't been fixed, any reply
> would still not have arrived near its original sender.
The bug lies with the original transmitter for letting a message go out
without a From: line specifying the domain. The bug *also* lies with the
receiver because it has lied gratuitously about the origin of the email,
thus incurring in a mail forgery act.
It's better to say "I don't really know where this message came from,
but here it is" (honest), than to say "Look, here's a message for you,
coming from x.y.z" (outright lie).
> If the headers had been correct, they would not have been changed. I
> think the millions of messages where this is the correct behaviour far
> outweigh the half a dozen messages a year where it is wrong.
I can't see your point here. When is it correct behaviour for a relaying
MTA (not the originating one) to overwrite a mail message From: line
with it's own address? You must mean the millions of cases where the
*originating* MTA adds its domain address, and there we are in
agreement.
> Anyway, exim does have the behaviour you're looking for. What mailer
> does your ISP use?
Received: from svana.org ([EMAIL PROTECTED] [210.9.66.30])
by mail2.expernet.pt (8.11.4/8.11.4) with ESMTP id g3KB9pn18302
^^^^^^^^^^^^^
I'd say that's probably sendmail.
--
Carlos Sousa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
