Skip Menu |
 

This queue is for tickets about the libnet CPAN distribution.

Report information
The Basics
Id: 2607
Status: deleted
Priority: 0/
Queue: libnet

People
Owner: Nobody in particular
Requestors: gbarr [...] pobox.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Date: Tue, 20 May 2003 12:11:53 +0100
From: Graham Barr <gbarr [...] pobox.com>
To: bug-libnet [...] rt.cpan.org
Subject: [Fwd] Re: Using LMTP to feed content_filter
----- Forwarded message from Mark Martinec <Mark.Martinec@ijs.si> ----- Date: Mon, 26 Aug 2002 19:35:32 +0200 To: gbarr@pobox.com From: Mark Martinec <Mark.Martinec@ijs.si> Subject: Re: Using LMTP to feed content_filter Graham, | > Graham (the author of Net::SMTP) ... hint, hint! :) | It should be a simple subclass of Net::SMTP. The only complication I see is | that DATA provides multiple responses, but that should not be too difficult | to handle. | | I can have a go a writing it, but someone else will need to test it. Finally I found some time to continue our recently started discussion on Perl module for client-side LMTP. I checked the Net::LMTP by Les Howard, and it definitely does not provide what I would need for amavisd-new content filter. It does not even provide per-user SMTP responses to the application, let alone being able to get them as soon as they are available, which is one of the important points in the spirit of LMTP. So I would appreciate if you would do it better. I'm not sure what features does LMTP server of the Cyrus imap/pop3 support (http://asg.web.cmu.edu/cyrus/ - I'll check), but it is likely the authentication is needed. According to postfix/README_FILES/LMTP_README : With connections over TCP sockets, later Cyrus LMTP server implementations insist on SASL-style authentication. This means that Postfix must be built with SASL support (see SASL_README). The examples below show how to enable this in the Postfix LMTP client. Some Cyrus LMTP server implementations do not allow SASL-style authentication via plaintext passwords. You will have to jump some extra hoops in order to enable MD5 password support, or you will have to wait until this restriction is relaxed. I'm not sure how much burden that involves. Perhaps also the CHUNKING (rfc3030) would be beneficial. Btw, there are some details in NET::SMTP/NET::Cmd that are casing me problems (in amavisd-new) and I'm not sure how to do things properly. So far I seem to be able to make it useful and reasonably reliable, but I think there is something rotten still there: - I'm having problems properly sending mail as a PIPELINING client (rfc2920) The root cause I believe is that Net::Cmd::response only stores response text in a list (net_cmd_resp), but only the last response _code_ is saved. Few things I learned: - the subroutines mail, recipient and data should be called by the application _without_ checking for response (as it may not be available before a response to DATA); the same applies to dataend(), which definitely must not be called with return value checking to make things reliable; - when the time to check response codes finally comes, I can call message(), but unfortunately only the last response code is available (but all past text parts or response codes are available as an array). The right time to call message() is at a rfc2920 synchronization point, i.e. only after a QUIT (or NOOP) command. - many subroutines (such as _MAIL and _RCPT) unnecessarily slow down the pipelining transaction by insisting on calling response(), which can only obtain a response by relying on the server timeout (required by rfc2920 as a means of dealing with non-pipelining clients). another: - NET::SMTP::mail() calls Carp if some specified option is not supported by the server. This unnecessarily complicates the application, as it has to check first what option is supported (calling an undocumented subroutine 'supports'), before deciding how it may call mail(). IMO the specified but unsupported options should just be ignored. - It would be easier to remember if the options (hash keys) would be the same as ESMTP option names. Best regards Mark -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! Mark Martinec (system manager) tel +386 1 4773-575 !! !! J. Stefan Institute, Jamova 39 fax +386 1 2519-385 !! !! SI-1000 Ljubljana, Slovenia mark.martinec@ijs.si !! !!!!!!!!!!!!!!!!!!!!!!!!!! http://www.ijs.si/people/mark/ !!!! Show quoted text
----- End forwarded message -----


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.