[tpop3d-discuss] SSL and 7BIT enconding

[Dave Baker]

On Mon, Oct 27, 2003 at 02:42:47PM +0100, Jens Liebchen (ppp-design) wrote:
> I've seen a strange problem comming up with 1.5.2 with SSL:
> Fetchmail (on the client site) is unable to flush a specific mail
> 
> "fetchmail: socket error while fetching from example.com"
> "Query status=2 (SOCKET)"
> 
> tpop3d log:
> 
> "tpop3d[10190]: ioabs_tls_immediate_write: client
> [7]abc@example.com(123.123.123.123): bad write retry; closing connection"
> 
> This is a permanent error. The first mail in the mailbox gets retrieved
> again and again but is not flushed. All other mails don't get retrieved.
>

I saw this exact same error ... if you check back a couple of weeks in the
mail archive you'll see what I found out about it, but here's a summary
from memory.

1) Can duplicate it on freebsd 4.5 with openssl 0.9.6 or 0.9.7 (latest
openssl in each branch)
2) Can only duplicate it over ethernet, not over loopback
3) Seemed to be foreign spam that triggered it - one specific example mail
could be fetched ONCE with success but trying to fetch a second time
always produced the error.


So, having been ready to throw up my hands and figure I was unique in
having the problem, it now seems I'm not alone in the world.

What OS are you using?  What version of openssl?  (not that I think it
matters, but is it compiled static or dynamic?)  Also, are you using mbox
or maildir (I'm using mbox and have an itch to switch some test accounts
over to maildir just to see if it makes a difference ... again, I suspect
not but you never know ...)

For reference, I find (found) that using "openssl s_client" was a better
way to identify the problem than using fetchmail (even in verbose mode).



> I have take a deeper look into the mailbox and the only thing I have
> found out was a uncommon "Content-transfer-encoding: 7BIT" in the first
> message and in one more message of the mailbox. I am not sure if this is
> related to the error. After deleting the first message manually,
> everything runs fine again and the second message with the 7BIT
> enconding gets retrieved.
>

This ties in with my observation that it's the *SECOND* occurance of a
problematic email that triggers it.


> I'am not sure where excatly the problem is, fetchmail has been updated
> to the latest version 6.2.1+SSL+NLS. It may be a openssl or a tpop3d
> bug. Maybe someone can reproduce this behaviour or is seeing something
> similar.
>

Try to duplicate it with openssl like this, and then just "talk" pop3 to
the server (e.g. "user FOO" "pass FOO" "retr 1" "retr 2" "retr 3")

$ openssl s_client -connect your.host.name:995


Dave

-- 

-    Dave Baker      :      dave@dsb3.com      :      http://dsb3.com/    -
GnuPG:  1024D/D7BCA55D / 09CD D148 57DE 711E 6708  B772 0DD4 51D5 D7BC A55D