Re: [Exim] -t and Resent- header lines

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: WJCarpenter
Data:  
Para: exim-users
Asunto: Re: [Exim] -t and Resent- header lines
gaw> My patch to the emacs sendmail.el tools removed some broken
gaw> half-assed attempts to parse message headers in an attempt to
gaw> discover the destination addresses instead of just letting the
gaw> MTA do it. The latter is of course the right thing to do for all
gaw> sendmail-compatible MTAs, except for Exim when there are resent-*
gaw> headers present, as we've since discovered.


Well, yeah, but... Doing anything that propagates the notion of
sendmail as a defacto standard just adds to the agony of the ages.

(My hosting provider just recently upgraded my site's sendmail install
to a newer point release. [This was done to get past a serious
security hole. I'm sure it's the last one sendmail has, and it's not
like sendmail has a history of security problem.] Anyhow, due to some
billion other Unix things thinking that there must be a sendmail-like
think located at /usr/lib/sendmail, I had exim symlinked in there.
The upgrade replaced my symlinked exim with the new sendmail binary,
and for four hours all email to my site got bounced with a 550
permanent error [since my sendmail.cf knows nothing of my site's real
configuration].)

So, yeah, using "let sendmail figure out the envelope" is convenient,
but the right thing to do is let the MUA components figure out the
envelope and explicitly tell the MTA. Of course, I agree that it
shouldn't be done half-assed (alas, a frequent occurence in the email
biz).

(Even in the olden days, when you could always count on there being a
/bin/rmail, emacs preferred to call sendmail directly.  I suppose this
was out of a sense of efficiency [more important in those days] and
also because of better support for background mailing.  Still, calling
/bin/rmail would have been more portable [even though it doesn't work
in many environments today, as things have drifted].)
--
bill@??? (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3