Lars Hecking <[EMAIL PROTECTED]> wrote:
>
> > Whatever MDA you are using, is at fault here. It has put the message
> > into your mailbox, with invalid headers. If you fix the MDA, the bounce
> > problem will go away.
>
> Possibly procmail or formail. But although escaping of bogus \nFrom
> lines is explained in the man pages, I cannot see how this possibly
> applies to this case.
Then think on this:
The message is placed in your mailbox looking like this:
From whoever Jan 21 09:10:11
>From some-sender Jan 21 09:10:04
Received by some-mailer at Jan 21 09:09:49
Recevedd ....
From: some-sender@somewhere
To: whoever
Subject: Test Message
This is a test message.
The first "From " line is the message separator for mbox messges. The
next line is the "original" message separator. A message should NOT
have a message separator until it is being placed for final delivery.
Procmail knows this, so when it tries to put the message into your
mailbox, it escapes the bogus separator and inserts its own. However,
this does not really make an RFC-compliant message. We'll see what
effect this has, later.
So, when Mutt goes to read the message, it wants to separate the message
into headers and body. It does this by scanning down the header section
until a non-compliant line is reached, which is usually the blank line
at the end of the header section. Mutt, you see, is a "smart" mailer
and has seen such bogusly-written messages before. There is a comment
to that effect in the source:
/* some bogus MTAs will quote the original "From " line */
if (mutt_strncmp (">From ", line, 6) == 0)
{
loc = ftell (f);
continue; /* just ignore */
}
So, Mutt ignores that. But that is simply Mutt's behavior. Other
programs touch mail messages, so their behavior may be different.
So anyway, Mutt shows the message correctly. The problem comes when you
bounce the message. During a bounce, the message text, exactly as-is,
will be piped to $sendmail, and sendmail will take that message and send
it to the intended bounced recipient. However, sendmail also knows what
constitutes an RFC-compliant message, but it apparently does NOT have
the above bit of code, like Mutt does... It sees the ">From " line in
the message, and says, "Hmm, that's not RFC-compliant, it must be part
of the message BODY!" And so everything below that is considered text
of the message, and the message essentially has NO headers. Then, since
there are no headers, sendmail automatically comes up with some basic
headers, including yourself as the From: header, and so on.
So, it is the original mis-formatting of the message that is at fault.
I suppose Mutt *could* try to get a little smarter, and not pass such a
bogus message to $sendmail, but really, isn't it best to fix the ROOT
cause of things? Your MDA is misconfigured, and that causes this whole
problem.
I imagine the problem is in the sendmail config, something like this:
Mlocal, P=/usr/bin/rmail, F=lsDFMAw5:/|@m, S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=rmail -d $u
This is my particular setting for the "local" MDA, in my sendmail.cf.
If I remember my sendmail configuration rightly, it is the "F" option in
the "F=" section which determines that a "From " header will be added to
the message before it is piped into the MDA. Now, for your case, you
probably have P=/usr/bin/procmail, and since procmail creates its own
message separator, having sendmail add it is superfluous; in that case,
removing the "F" might be the way to handle this.
At any rate, since this can be fixed at your site, perhaps it is best to
do that, rather than coerce Mutt to adapt to your broken mail system.
--
David DeSimone | "The doctrine of human equality reposes on this:
[EMAIL PROTECTED] | that there is no man really clever who has not
Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson
UX WTEC Engineer | PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
