Re: bad (i.e. serious) mail problems

[Dmitry Yaitskov <dimas@home.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:

> * Dmitry Yaitskov <dimas@home.com>  on Tue, 30 Mar 1999
<snip>
> | When I retrieve mail via pop3 no mbox needs to be involved at all. Again,
> | pop3 protocol does *not* require "\n\nFrom " lines to be escaped in any
> | way, they do not have any special meaning for it.
> 
> Not entirely true.  If the mail host stores mail in mbox-style spool files,
> and the MTA or delivery agent does not generate Content-Length headers,
> then message body lines that resemble SMTP envelopes should be escaped by
> the MTA or local delivery agent on the mail host.  If that does not happen,
> the POP server or local mail clients could become confused.

Where (rfc#) does it say so? Note, the pop3 server (or rather, 3
different pop servers that I tested) did not become confused. It was
the local mail client (gnus) that got confused.

> The POP retrieveal mechanism cares not a whit about delimiters on the
> server, since the POP server has already done that work.

So?...

> [...]
> | It is the job of whoever builds the mbox to escape things having special
> | meaning for mbox (and for nothing else). So, it is gnus (or rather,
> | pop3-movemail) who screws things up in this case, because it
> | (pop3-movemail) builds an invalid mbox out of perfectly valid separate
> | messages.
> 
> FYI, pop3-movemail (and the rest of the innards of the code) generate a
> crashbox that is identical to the spool file on the server (or as close as
> I can get given a certain university's widely used POP server that has a
> tendency to strip trailing whitespace from messages).  If the mail host
> uses MMDF, an MMDF crashbox is generated.  If the mail host uses Babyl, a
> Babyl crashbox is generated.  If the mail host uses mbox, an mbox crashbox
> is generated.

Could you please explain - how on Earth do you *know* what the "spool
file on the server" (if by the server you mean the machine running the
pop3 you got the mail from) looks like? This info is certainly not
included in the pop3 protocol, is it?

> The only time pop3 generates an mbox-style crashbox is if the mail host
> uses none of these formats and/or the POP server is broken and strips away
> the message delimiters.  Then, and only then, will pop3 generate an SMTP
> envelope style delimiter derrived from RFC 822 headers.  And I have put
> much effort into making sure that the envelope-like delimiter is 100%
> accurate in format.  Look at pop3-munge-message-separator for specifics.
> 
> If after all that Gnus' spool file parsing code still barfs on a particular
> message, it means that the MTA or delivery agent on the mail host failed to
> either generate a Content-Length header or escape the envelope-like line.
> 
> If that is not the case (show us the Content-Length header in that
> message), then you have stumbled onto a Genuine Bug in Gnus.

Thank you. I did stumble upon a bug, that's for sure. Again, just in
case you missed my point. I tried sending and receiving the message
that got FUBAR thru *3* different machines, running in 3 different
organizations. Retrieving that message with pop3-movemail/gnus from 2
of them produced the error, while the third did effectively what my
patch does. Reading that same message directly on those hosts was ok.
Getting that same message from same pop3 hosts with MS outlook express
did *not* produce the error, obviously because it (MSOE) was smart
enough not to assume things about the servers it was getting mail from
it had no way of knowing. Tell me that's not a bug.

-- 
Cheers,
-Dima.