Skip Menu |

This queue is for tickets about the POE-Component-Client-SMTP CPAN distribution.

Report information
The Basics
Id: 24541
Status: resolved
Priority: 0/
Queue: POE-Component-Client-SMTP

People
Owner: george [...] upg-ploiesti.ro
Requestors: domm [...] cpan.org
Cc:
AdminCc:

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



Subject: Incorrect handling of SMTP return codes
Hi! I'm currently starting to use POE-Component-Client-SMTP, and think I discovered a bug (at least when talking to our mail server, which seems to be ESMTP Sendmail 8.13.4/8.13.0) In line 182 of PoCo::Client::SMTP.pm, you check the return value via a regular expression. But if the return value indicates an error (according to RFC 2821 Section 4.2.1 if the retrun value starts with 5xx), you still continue to post the data. And in the end, the SMTP_Failure event is never called. I'm not sure at the moment how to solve this (I haven't looked at the code that close..), but I think it's not that hard. Oh, and thanks for the nice module, BTW!
Hi, indeed, I've left room for checking SMTP codes, but somehow I forgot to do it :( <--- yup pretty stupid of me :) Attached you'll find a patch for v0.13 (that is v0.14) Also, you can find some test files for it here: http://cvs.savannah.nongnu.org/viewcvs/POE-Component-Client-SMTP/t/?root=pococlsmtp 015-receive-5XY-code.t 015-receive-DATA-5XY-code.t 017-unknown-code.t v0.13 should fail them, v0.14 should pass I'll set this to "RESOLVED", and to CLOSED in case you're satisfied with it. thanks for the feedback -- Dodge this!
? SMTP.pm. Index: SMTP.pm =================================================================== RCS file: /cvsroot/pococlsmtp/POE-Component-Client-SMTP/lib/POE/Component/Client/SMTP.pm,v retrieving revision 1.7 diff -u -r1.7 SMTP.pm --- SMTP.pm 6 Feb 2006 08:31:55 -0000 1.7 +++ SMTP.pm 25 Jan 2007 12:01:17 -0000 @@ -13,7 +13,7 @@ use warnings; use strict; -our $VERSION = '0.13'; +our $VERSION = '0.14'; use Carp; use Socket; @@ -179,21 +179,50 @@ print "INPUT: $input\n" if $self->debug; + # allright, received something in the form XXX text if ( $input =~ /^(\d{3})\s+(.*)$/ ) { - my $to_send = $self->command; - if ( !defined($to_send) ) { - $kernel->post( - $self->parameter("Caller_Session"), - $self->parameter("SMTP_Success"), - $self->parameter("Context"), - ); - $self->_smtp_component_destroy; + # is the SMTP server letting us know there's a problem? + my ( $smtp_code, $smtp_string ) = ( $1, $2 ); + if ( $smtp_code =~ /^(1|2|3)\d{2}$/ ) { + + # we're ok + # and also stupid, don't know estmp, don't know 1XY codes + my $to_send = $self->command; + if ( !defined($to_send) ) { + $kernel->post( + $self->parameter("Caller_Session"), + $self->parameter("SMTP_Success"), + $self->parameter("Context"), + ); + $self->_smtp_component_destroy; + } + else { + print "TO SEND: $to_send\n" if $self->debug; + + $self->store_rw_wheel->put( $to_send . $EOL ); + } + } + elsif ( $smtp_code =~ /^(4|5)\d{2}$/ ) { + carp "Server Error! $input \n" if $self->debug; + + # the server responder with 4XY or 5XY code; + # while 4XY is temporary failure, 5XY is permanent + # it's unclear to me whether PoCoClientSMTP should retry in case of + # 4XY or the user should. In case is PoCoClientSMTP's job, then I + # should define for how many times and what interval + my %hash; + $hash{'SMTP_Server_Error'} = $input; + $kernel->yield( "return_failure", \%hash, ); } else { - print "TO SEND: $to_send\n" if $self->debug; - $self->store_rw_wheel->put( $to_send . $EOL ); + # oops! we shouldn't end-up here unless the server is buggy + carp "Error! I don't know the SMTP Code! $input \n" + if $self->debug; + my %hash; + $hash{'SMTP_Server_Error'} = $input; + $kernel->yield( "return_failure", \%hash, ); } } elsif ( $input =~ /^(\d{3})\-(.*)$/ ) { @@ -768,6 +797,10 @@ The point is you shouldn't send email messages having bare LF characters. See: http://cr.yp.to/docs/smtplf.html +=head1 ESMTP error codes 1XY + +ESMTP error codes 1XY are ignored and considered as 2XY codes + =head1 ACKNOWLEDGMENTS =over 4
Subject: Re: [rt.cpan.org #24541] Incorrect handling of SMTP return codes
Date: Mon, 29 Jan 2007 10:33:19 +0100
To: George Nistoric?? via RT <bug-POE-Component-Client-SMTP [...] rt.cpan.org>
From: Thomas Klausner <domm [...] cpan.org>
Hi! On Thu, Jan 25, 2007 at 07:13:52AM -0500, George Nistoric?? via RT wrote: Show quoted text
> indeed, I've left room for checking SMTP codes, but somehow I forgot to > do it :( <--- yup pretty stupid of me :) > > Attached you'll find a patch for v0.13 (that is v0.14) > > Also, you can find some test files for it here: > http://cvs.savannah.nongnu.org/viewcvs/POE-Component-Client-SMTP/t/?root=pococlsmtp > 015-receive-5XY-code.t > 015-receive-DATA-5XY-code.t > 017-unknown-code.t > > v0.13 should fail them, v0.14 should pass > > I'll set this to "RESOLVED", and to CLOSED in case you're satisfied > with it.
Thanks, I'll test it tomorrow (I have a day full of meetings today...) Thanks for the quick reply! -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Subject: Re: [rt.cpan.org #24541] Incorrect handling of SMTP return codes
Date: Tue, 30 Jan 2007 11:51:17 +0100
To: George Nistoric?? via RT <bug-POE-Component-Client-SMTP [...] rt.cpan.org>
From: Thomas Klausner <domm [...] cpan.org>
Hi! On Thu, Jan 25, 2007 at 07:13:52AM -0500, George Nistoric?? via RT wrote: Show quoted text
> Attached you'll find a patch for v0.13 (that is v0.14)
works like a charm! Show quoted text
> v0.13 should fail them, v0.14 should pass
all the test pass. Show quoted text
> I'll set this to "RESOLVED", and to CLOSED in case you're satisfied > with it.
IMO you can now close the ticket. Oh, and I'd appreciate a new CPAN release, because our operations team doesn't fancy deploying patched versions ... Thanks again for your effort! -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
On Tue Jan 30 05:51:47 2007, DOMM wrote: [snip] Show quoted text
> IMO you can now close the ticket. Oh, and I'd appreciate a new CPAN > release, because our operations team doesn't fancy deploying patched > versions ... > > Thanks again for your effort! > >
hi, it should be on your favourite CPAN mirror anytime soon :) have fun :P -- Dodge this!