[spambayes-bugs] [ spambayes-Bugs-797316 ] Extra CRLF to smtp server causes garbage error.

[SourceForge.net]

Bugs item #797316, was opened at 2003-08-30 02:29
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498103&aid=797316&group_id=61702

Category: pop3proxy
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dudley Fox (grieve)
Assigned to: Tony Meyer (anadelonbrin)
Summary: Extra CRLF to smtp server causes garbage error.

Initial Comment:
In version 1.0a4 of smtpproxy.py on line 200 it reads
     self.serverSocket.push(cooked + '\r\n')
It should read
     self.serverSocket.push(cooked)

The first line sends an empty command to the smtp
server, and causes it to return an error. Different
smtp servers and mail clients handle it differently,
but Eudora will complain that when it sent the QUIT
command an error was returned. Agent will just fail
silently. In both cases the message is actually sent.

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2003-09-02 12:38

Message:
Logged In: YES 
user_id=552329

Confirmed that it does fix it.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-09-01 17:23

Message:
Logged In: YES 
user_id=552329

Bah.  Forget all that.  I was making the change in the wrong
place, because I didn't look up the line number in 1.0a4 and
there wasn't any context code around the change.  I made the
change (it's in smtpproxy v1.13) and my smtpproxy still
works, so 1.0a5 should work for you.  Hopefully this will
fix it for everyone.

I *think* that the problem was not actually anything to do
with the QUIT command.  The extra \r\n was sent after the
end of the data (which is usually immediately followed by
the QUIT), which is handled in a different place, and did
have an extra \r\n.  The error response just came back after
the QUIT was sent.  This explains a lot.

I'm changing this to pending - if anyone does have this
problem with smtpproxy v1.13 or 1.0a5 then please reopen. 
I'll close it once I've confirmed that it fixes it for the
other people.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-09-01 15:03

Message:
Logged In: YES 
user_id=552329

One other thing: two of the people that have reported this 
have been using Norton Anti-Virus to scan mail.  One suspects 
that the problem lies with the Norton-spambayes relationship 
(although I'm not convinced).  Are you using Norton?

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-09-01 14:26

Message:
Logged In: YES 
user_id=552329

Bah.  I've had one other person tell me that they experienced 
this problem and that this fixed it, and one other person tell 
me that they experience this problem, and that this doesn't fix 
it (they get the same result as me).

I really need to know whether this was the only change made 
or not.  I don't see how it could possibly work!  If you could 
download 1.0a5 (probably out later today) and try it 
unchanged, and then (if necessary) with this alternation, that 
would be fantastic.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-08-30 20:14

Message:
Logged In: YES 
user_id=552329

You are correct that there is a problem that Eudora complains 
about an error after the QUIT command.

However, if the '\r\n' is removed, then *no* commands work 
(at least here).  Certainly this is the way that the RFC says 
that SMTP is meant to work (specifically, that there is a CRLF 
after each command, including QUIT).

Can you confirm for me that removing the '\r\n' means that 
you can still use smtpproxy?  If I remove it here, it hangs 
forever on the first command sent (ELHO, in this case).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498103&aid=797316&group_id=61702