I believe this output is demonstrating a problem with your program, not with spamdyke. According to the SMTP specification, the client should continue reading output from the server until it sees a line that begins with a three digit number, followed by a space, followed by some text, followed by a CRLF sequence.
Your program only reads from the network once and assumes the server's entire response will be contained in a single network packet. This is not a valid assumption. There are many reasons why the server's response could be broken into multiple packets and a well-behaved client must be ready for that to happen. spamdyke sends all of its data to the remote client line-by-line. Before you spend a bunch of time combing through the SMTP specification, let me assure you it is completely silent on the issue. SMTP is designed to be independent of specific network topologies, which means it cannot dictate how packets are transmitted when carrying its data. I'm not familiar with Zarafa, but if its code makes the same assumption as your program, this could be the problem. I expect it would cause problems with many other mail servers, however. When you run your test program against your server, do you see the same error message in your qmail logs as when you use Zarafa? My recommendation would be to continue testing with Zarafa and use a packet sniffer to watch the traffic as it works. You could also try compiling spamdyke with "excessive" output (run the "configure" script using the "--with-excessive-output" flag, then run "make" again) and capture a full log (with the "full-log-dir" option). spamdyke will print a ton of information about what data is being read from the network and the contents of its buffers as it works. If you send me the unedited log (privately, if you don't want to post it), I could probably tell you exactly what's happening. -- Sam Clippinger Chris wrote: > Hi Sam, > > thank's for your replies. > Your doubt proved correct: commenting out these lines did not work. > > After doing _a lot_ of research, I found the "bug" in spamdyke which is > causing this strange behavior (I actually don't know if it's a bug in > spamdyke or in my mail client, because I don't know the SMTP protocol > detailed enough). > > I programmed a small c program which connects to the smtp server and sends > following strings, one by one: > "EHLO someone\r\n" > "MAIL FROM: [email protected]\r\n" > "RCPT TO: [email protected]\r\n" > "DATA\r\n" > > After each String I send, I read the response ONCE and give it out. > > Here is what I get when Spamdyke is not installed (no suprises here, it's as > expected): > [r...@myserver testclient]# ./a.out localhost 25 > 220 myserver.de ESMTP > |out: |EHLO someone > | > |in: |250-myserver.de > 250-STARTTLS > 250-PIPELINING > 250 8BITMIME > | > |out: |MAIL FROM: [email protected] > | > |in: |250 ok > ð|0| > |out: |RCPT TO: [email protected] > | > |in: |250 ok > | > |out: |DATA > | > |in: |354 go ahead > H| > > > Now the same program, with Spamdyke installed: > [r...@myserver testclient]# ./a.out localhost 25 > 220 myserver.de ESMTP > |out: |EHLO someone > | > |in: |250-myserver.de > öG| > |out: |MAIL FROM: [email protected] > | > |in: |250-STARTTLS > @| > |out: |RCPT TO: [email protected] > | > |in: |250-PIPELINING > | > |out: |DATA > | > |in: |250-8BITMIME > H| > > > You can observe that qmail sends one long string after the client sends the > EHLO-Command. > Spamdyke however sends one short string for each line. > > I do not know if SMTP protocol dictates that you have to write the output at > once, but my mail client can't handle multiple outputs. > > Gonna do some more research on SMTP Protocol and get back. > > > I have attached the small c program. Run it with host and port as parameter > (as in examples above) if you want to test it yourself. > > Regards, > > Chris. > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Clippinger > Sent: Monday, January 05, 2009 1:17 AM > To: spamdyke users > Subject: Re: [spamdyke-users] Disabling replace of LineFeed with > CarriageReturn+LineFeed > > I seriously doubt spamdyke's CRLF feature is causing this issue. The > message you're seeing in the qmail logs is trying to tell you that > qmail-smtpd exited and it's speculating as to the reason. If CRLF was > an issue, you would see the pobox.com URL in the spamdyke log file (it > gets sent to the remote client). > > However, if you want to try running spamdyke without that feature, > remove the small if() block on lines 387-393 in log.c (version 4.0.10) > and run "make". NOTE: Removing those lines _should_ only remove the > CRLF filter, it shouldn't change anything else. I haven't tested it, > however, so please be careful. > > -- Sam Clippinger > > Chris wrote: > >> Hi folks, >> >> >> >> I have another problem with following feature: >> >> ?spamdyke silently helps mail clients avoid this error by inserting a >> carriage return before any bare line feed characters it sees.? >> (Spamdyke Documentation) >> >> >> >> Using zarafa (www.zarafa.com <http://www.zarafa.com>), all outgoing >> email gets bounced back with exactly the message which should be >> prevented by that feature: >> >> possible qmail-smtpd exited by timeout, reset connection or with "See >> http://pobox.com/~djb/docs/smtplf.html >> <http://pobox.com/%7Edjb/docs/smtplf.html>." (qmail log file) >> >> And it definitely isn?t because of timeout (log message appears >> instantly when tailing the logfile) or connection reset. >> >> >> >> My wild guess is that zarafa does not implement the SMT protocol >> correctly and sends LineFeeds where none should be. Qmail just ignored >> them, and now spamdyke changes those LineFeeds to >> CarriageReturn-LineFeed which get interpreted by qmail and cause this >> error. >> >> >> >> Can anyone tell me, in which c file and what line spamdyke replaces >> the LF character with CR LF? I then could comment this out and test if >> that works. >> >> >> >> Kind regards, >> >> >> >> Chris >> >> >> >> >> >> Anyway, here is an smtp log of the message of spamdyke (highest log level) >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 34 bytes >> >> 220 myserver.de ESMTP >> >> >> >> 01/04/2009 22:26:53 FROM REMOTE TO CHILD: 29 bytes >> >> EHLO myserver.de >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 28 bytes >> >> 250-myserver.de >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 14 bytes >> >> 250-STARTTLS >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 16 bytes >> >> 250-PIPELINING >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 14 bytes >> >> 250-8BITMIME >> >> >> >> 01/04/2009 22:26:53 FROM SPAMDYKE TO REMOTE: 3 bytes >> >> 250 >> >> 01/04/2009 22:26:53 FROM SPAMDYKE TO REMOTE: 1 bytes >> >> >> >> 01/04/2009 22:26:53 FROM SPAMDYKE TO REMOTE: 27 bytes >> >> AUTH LOGIN PLAIN CRAM-MD5 >> >> >> >> 01/04/2009 22:26:53 FROM REMOTE TO CHILD: 39 bytes >> >> MAIL FROM: <[email protected]> >> >> >> >> 01/04/2009 22:26:53 LOG OUTPUT >> >> DEBUG(filter_sender_whitelist()@filter.c:1747): searching sender >> whitelist(s); sender: [email protected] >> >> DEBUG(filter_sender_blacklist()@filter.c:1881): searching sender >> blacklist(s); sender: [email protected] >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 8 bytes >> >> 250 ok >> >> >> >> 01/04/2009 22:26:53 FROM REMOTE TO CHILD: 29 bytes >> >> RCPT TO: <[email protected]> >> >> >> >> 01/04/2009 22:26:53 LOG OUTPUT >> >> DEBUG(filter_recipient_relay()@filter.c:2183): checking relaying; >> relay-level: 0 recipient: [email protected] ip: 127.0.0.1 rdns: >> localhost local_recipient: false relaying_allowed: true >> >> DEBUG(filter_recipient_local()@filter.c:2154): checking for >> unqualified recipient; recipient: [email protected] >> >> DEBUG(filter_recipient_blacklist()@filter.c:2278): searching recipient >> blacklist(s); recipient: [email protected] >> >> DEBUG(filter_recipient_graylist()@filter.c:2342): checking graylist; >> recipient: [email protected] sender: [email protected] >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 8 bytes >> >> 250 ok >> >> >> >> 01/04/2009 22:26:53 LOG OUTPUT >> >> ALLOWED from: [email protected] to: [email protected] origin_ip: >> 127.0.0.1 origin_rdns: localhost auth: (unknown) >> >> >> >> 01/04/2009 22:26:53 FROM REMOTE TO CHILD: 6 bytes >> >> DATA >> >> >> >> 01/04/2009 22:26:53 FROM CHILD TO REMOTE: 14 bytes >> >> 354 go ahead >> >> >> >> 01/04/2009 22:26:53 FROM REMOTE TO CHILD: 6 bytes >> >> QUIT >> >> >> >> 01/04/2009 22:26:53 CLOSED >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > ------------------------------------------------------------------------ > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
