[tpop3d-discuss]Error in client (Outlook express)

[Chris Lightfoot]

On Tue, Jun 29, 2004 at 06:26:06AM -0700, Matthew Trent wrote:
> On Thursday 29 July 2004 01:17 am, James Gurney wrote:

> > We're using Maildir, so I went and started moving mails out of his
> > folder until the error went away. Identified the problem email.. Now,
> > when testing over telnet, I can retr the mail no problem. It appears to
> > return perfectly (the . terminator appears and everything). However,
> > looking at the file with less, the last character of the file seems odd
> > (shows up as ^@ ). Hexdump output of the last 3 lines follows:
> >
> > 1860  2d 2d 2d 2d 2d 3d 5f 4e  65 78 74 50 61 72 74 5f  -----=_N extPart_
> > 1870  30 30 30 5f 30 30 30 30  5f 41 34 45 43 45 36 42  000_0000 _A4ECE6B
> > 1880  37 2e 42 37 42 33 45 33  30 46 2d 2d 0a 00 0a     7.B7B3E3 0F--...
> >
> > I suspect the null character on the last line is the one causing the
> > problem, so here's the question..
> 
> Ahh, perhaps you're on to something. Can you generate a test case with a 
> different email so we know it's not some other characteristic of that email? 
> I've always noticed that same thing with these "clogged emails"; I can telnet 
> in and retr it fine, and no other client but OE exhibits the behavior.

Can you tell me the results when you do that? If it
genuinely is null characters then the (deeply horrible)
solution is probably to map them into something else (e.g.
character 128).

> > Whose job is it to deal with this, if it is the problem? I can't see any
> > reason for the smtpd or pop3d to arbitrarily remove characters, which
> > leads me to the conclusion that the problem is in the client (shock,
> > horror). Apart from telling users to not use Outlook express, what else
> > can I do about this?
> 
> I'm have no doubt that the client is the problem! Outlook Express and Outlook 
> are absolutely horrible. However, we have 10,000 addresses, and probably 90% 
> of them are checked with Outlook Express. Telling them to change clients is 
> not an option, and I'm sure we aren't the only ones in that situation. If 
> that character is the problem, perhaps it _would_ be wise to have tpop3d 
> sanitize it before sending it to the client.

Yeah. IMAP servers already have to do that -- the broken
behaviour is written into the standard.

-- 
``Jospin has the charisma and voter appeal which British voters have only
  encountered in the person of Michael Foot.'' (Ian Sykes on Lionel Jospin)