Bug 19038
| Summary: | The qpopper port accepts empty X-UIDL: headers in some cases, making retrieving email impossible in some cases | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | agifford |
| Component: | Individual Port(s) | Assignee: | Andrey A. Chernov <ache> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->freebsd-ports Should be in ports. I notice that this is still open and the problem still exists in the /usr/ports/mail/popper port (as of 16 FEB 2001). The solution I proposed in the original PR is still the correct fix. Delete line 757 from pop_dropcopy.c. I hope the port maintainer will take action. I wish there was a way to elevate this fix, since as long as this bug exists, in some cases e-mail is impossible to retrieve using POP unless someone manually edits the mailbox file. Is there a way to elevate the priority level of an open bug? Aaron out. -- InfoWest, Inc. * 596 E. Tabernacle * St. George, UT 84790 Voice: 435-674-0165 * FAX: 435-674-9654 Web: www.infowest.com * E-mail: support@infowest.com Responsible Changed From-To: freebsd-ports->ache Actually assign PR to maintainer... Responsible Changed From-To: ache->dannyboy Or not. Typo, yes, I relize -ports is the maintainer. Looking at it. State Changed From-To: open->feedback State Changed From-To: feedback->open Fun with GNATS! I think this actually does go to ache... Responsible Changed From-To: dannyboy->ache Sigh. ache IS the maintainer. pointy hat over here. State Changed From-To: open->closed Commited |
There's a bug in the current version of qpopper in the ports collection such that an email message containing a header "X-UIDL: " with ONLY the header name followed by a single space can cause a mailbox to be unreadable by some clients (Microsoft Outlook in particular) because client then chokes on the output of the XUIDL POP command. Fix: The fix is simple. Edit the patched ports version of pop_dropcopy.c and delete the following line (line 757): } else if (!strncasecmp("X-UIDL:", buffer, 7)) { if (!uidl_found) { int len; char *cp; uidl_found++; <<<<<DELETE THIS LINE RIGHT HERE (line 757)<<<< /* Skip over header */ cp = &buffer[7]; while (*cp && (*cp == ' ' || *cp == '\t')) cp++; if( (len = strlen(cp)) > MIN_UIDL_LENGTH && len < MAX_UIDL_LENGTH ) { uidl_found++; That one line change will force qpopper to generate a new X-UIDL: header when the X-UIDL: header is empty. I strongly suspect that this is a case where someone editing things just forgot to delete that line while adding functionality. In other cases, the code correctly checks for an X-UIDL: header whose length is > MIN_UIDL_LENGTH and < MAX_UIDL_LENGTH. This single case (zero length after the header and single space) slips through. How-To-Repeat: Hand edit a mailbox file and add an X-UIDL: header that ONLY includes the header name followed by a single white space (or send yourself such a message), then connect to the qpopper port, issue the USER <user> and PASS <pass> command, then send the UIDL command. Notice that when it lists the message with the faulty header, you see something like this (assuming the bad header is part of message #25): ... 24 e9939c998575720193ef864e906609ee 25 26 064976f286d27c205936a1d8ab8d832a 27 c7ba3d53f66c62b4a3bc5bb8f6c1e4a4 ... At least one email client is known to choke at this point (MS Outlook) and abort the POP session (there are most likely many more). I discovered it when a coworker's email client (Outlook) started freaking out so he couldn't retrieve his email.