11 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: pop3d miscalc...
FromSent OnAttachments
Joe LaffeyJun 6, 2003 3:14 pm 
Sam VarshavchikJun 6, 2003 3:50 pm 
Joe LaffeyJun 6, 2003 6:47 pm 
Sam VarshavchikJun 6, 2003 7:45 pm 
Joe LaffeyJun 6, 2003 8:25 pm 
Joe LaffeyJun 6, 2003 8:26 pm 
Sam VarshavchikJun 7, 2003 7:22 am 
Joe LaffeyJun 7, 2003 2:21 pm 
Bruce BroeckerJun 7, 2003 6:23 pm 
Systems AdministratorJun 17, 2003 6:52 pm 
Systems AdministratorJun 17, 2003 6:53 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Re: pop3d miscalculating msg lengthActions...
From:Joe Laffey (jo@laffeycomputer.com)
Date:Jun 6, 2003 8:25:39 pm
List:net.sourceforge.lists.courier-users

On Fri, 6 Jun 2003, Joe Laffey wrote:

On Fri, 6 Jun 2003, Sam Varshavchik wrote:

Joe Laffey writes:

Are there any know bugs in 0.4.2 where the pop3d some how miscalculates the size of certain (potentially mal-formatted) message?

There are no known bugs.

I ask because I keep having trashy Outlook choke on some messages. When I connect to the pop3d manually I see that the messages that cause the problem always show up with a zero length in the LIST output and a RETR gives: RETR 1 +OK 0 octets follow. <msg>

Since a RETR is nothing more than an fopen(), followed by getc(), this indicates that this is indeed an empty file.

I will sanitize the message removing anything confidential, and see if I can still reproduce the problem. If so I shall post the message here.

It seems I was barking up the wrong tree. The zero size came from a permissions issue. That has been resolved.

I have uncovered a problem, though. The problem lies with the message itself. Instead of following the headers with two new lines (courier seems to strip the CRs) it follows the headers with one new line (at the end of the last header) and then a line that has 3 tab characters followed by a newline.

So normal:

Subject: test\n \n <body>

This msg:

Subject: test\n \t\t\t\n <body>

This is obviously wrong. The message is a temp fail undeliverable warning from an SBC webhosting server: Connected to 216.173.237.164. Escape character is '^]'. 220 mail26a.sbc-webhosting.com SMTP RS ver 1.0.80vs

The problem is this: This message stops Outlook dead. Outlook cannot retrieve this message, and it cannot retrieve any messages after it. It requires admin intervention.

So the questions are: A) Who truly is to blame here? SBC's server for one, but which other program is viloating RFCs?

B) What can we do about it? Obviously this kind of thing is going to continue to happen. It has happened a number of times in the past. Outlook, although garbage, is the most popular email client. SBC is not going away any time soon. Can we either reject these bad messages at an SMTP level or fix them?

Thoughts?

Thanks,