Package spampd Tags 395355 + upstream thanks Vladislav Kurz wrote on 26/10/2006 16:41:
Note to Maxim: Full original mail available at http://bugs.debian.org/395355 > Version: 2.20-9 > I have spampd in the following config: > > exim 4.50-8sarge2 as MTA, local delivery is done by LMTP to spampd, > which in turn forwards local delivery to cyrus 2.1.18-1+sarge2. Note: I'm not sure when exactly Maxim implemented the full LTMP support (though I think that was before 2.20), but could you please try the 2.30-14 package from etch/sid, which also works on Sarge? > It seems to work fine, as long as there is only one recipient in each > message. If there are multiple recipients, LMTP server is supposed to > confirm delivery to every mailbox, so after the final . in DATA command > there should be as many replies as there were successfull RCPTs (see RFC > 2033, section 4.2). I debugged with tcpdump and cyrus correctly sent > multiple "250 Ok" lines, but spampd forwarded only one of them to exim. > Thus exim was waiting for more replies, cyrus was waiting for QUIT, and > spampd just timed out after 6 minutes producing this error: > WARNING!! Error in process_request eval block: Child server process timed out! It seems that Maxim's expectation to be fully LMTP compatible was wrong than. As far as I'm concerned, I would actually "fix" this by documenting the workaround and only supporting SMTP mode and single-recipient mode for LMTP. It might be possible to implement the LMTP mode completely, but I'm not sure about that. Maxim: Do you have any idea wether that is possible and how much work it would mean? > A workaround is to set max_rcpt = 1 in the SMTP/LMTP transport, so > messages are delivered to only one RCPT at a time. However this causes > spampd to analyze the same message multiple times, thus wasting CPU > power. > > I hope this info would help you to find the bug and fix it. To me it looks not really like a bug, but more like a missing feature which would be needed to live up to the expectations raised from the SpamPD docs/website. But I will look into this once I have some time (possibly this weekend, but more likely later). cu, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
