Hi Sam, after reading the RFCs more careful and from another angle, I guess you're right. I'm no expert on RFCs nor on SMTP, so excuse me for my mistake.
In those RFCs they always talk about "the reply" (one reply... "Each line of the [multiline] response contains [...]") not many replies. I interpreted the reply as one single reply as such... Well anyway, at least I finally know what's causing the problem! I appreciate your patience, help and support! Thank you, Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sam Clippinger Sent: Monday, January 05, 2009 11:15 PM To: spamdyke users Subject: Re: [spamdyke-users] Bug found! Re: Disabling replace of LineFeed with CarriageReturn+LineFeed Looking at the RFCs you've indicated, I don't see the text you're quoting. Each of the documents shows how to send a multi-line response, but none of them (as far as I can see) says anything at all about the number of packets that can be sent. If I'm just not seeing the relevant text, could you post the paragraphs you're looking at? I do see that RFC 821's introduction section says this: SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Without more evidence to the contrary, I still believe the problem with Zarafa is unrelated to either the CRLF filter or the single/multi-line issue. -- Sam Clippinger Chris wrote: > (First off: Sry for previous spam, the last mail got stuck in outbox and sent > a few times by some error I am yet to find out) > > I have read (some of) the SMTP RFCs and they say, the SMTP server should send > _one_ reply consisting of _many_ lines after receiving the EHLO command. > See RFC 2821 Page 30 for example or RFC 0821 on Page 50 or RFC 5321 on Page > 50. > > Spamdyke sends _many_ replies consisting of _one_ line each, thus not > following the SMTP protocol correctly. > > My Mail client obviously can't handle that, while others like Outlook can. > > Hope to seeing a fix on this soon ;) > > Regards, > Chris > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Chris > Sent: Monday, January 05, 2009 10:13 PM > To: spamdyke users > Subject: Re: [spamdyke-users] Disabling replace of LineFeed with > CarriageReturn+LineFeed > > 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 _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
