RE: [imp] Problem sending mail using SMTP (was) Session timeout when loggingon

From: Date: Sat, 15 Feb 2003 02:05:40 +0000
Subject: RE: [imp] Problem sending mail using SMTP (was) Session timeout when loggingon
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-13312@lists.php.net to get a copy of this message
You're right! the function must check that the SIZE must be greater than 0 to disconnect. here I propose a patch to correct this and also verify that the contents of the SIZE parammeter is a numeric value (just for safety) Jon: please commit it function data($data) { if (isset($this->_esmtp['SIZE'])) { if (is_numeric($this->_esmtp['SIZE']) ) { //For safety if (strlen($data) >= $this->_esmtp['SIZE'] && $this->_esmtp['SIZE'] > 0) { $this->disconnect(); return new PEAR_Error('Message size excedes the server limit'); } } } On Fri, 2003-02-14 at 13:30, Jeff Graves wrote: > Further investigation found that the error was coming from the PEAR > module Mail::smtp, which was returning the generic error for > Net::smtp. Modification of Mail::smtp turn return the exact result of > Net::smtp error found this: > > There was an error sending your message: Message size exceeds the > server limit > > The response on my server on a EHLO command: > > 220 mailsrv.image-src.com ESMTP Sendmail 8.12.5/8.12.5; Fri, 14 Feb > 2003 10:59:05 -0500 > EHLO localhost > 250-mailsrv.image-src.com Hello samadams.image-src.com > [65.219.192.35], pleased to meet you > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-8BITMIME > 250-SIZE > 250-DSN > 250-DELIVERBY > 250 HELP > > >From RFC 1870: > > An SMTP client wishing to relay a large content may issue the EHLO > command to start an SMTP session, to determine if the server > supports > any of several service extensions. If the server responds with > code > 250 to the EHLO command, and the response includes the EHLO keyword > value SIZE, then the Message Size Declaration extension is > supported. > > If a numeric parameter follows the SIZE keyword value of the EHLO > response, it indicates the size of the largest message that the > server is willing to accept. Any attempt by a client to transfer a > message which is larger than this limit will be rejected with a > permanent failure (552) reply code. > > A server that supports the Message Size Declaration extension will > accept the extended version of the MAIL command described below. > When supported by the server, a client may use the extended MAIL > command (instead of the MAIL command as defined in [1]) to declare > an > estimate of the size of a message it wishes to transfer. The > server > may then return an appropriate error code if it determines that an > attempt to transfer a message of that size would fail. > > >From Net::smtp > > function data($data) > { > if (isset($this->_esmtp['SIZE'])) { > if (strlen($data) >= $this->_esmtp['SIZE']) { > $this->disconnect(); > return new PEAR_Error('Message size excedes the server > limit'); > } > } > ... > > And again from Net::smtp > > function _negotiate() > ... > foreach ($this->_arguments as $argument) { > $verb = strtok($argument, ' '); > $arguments = substr($argument, strlen($verb) + 1, > strlen($argument) - strlen($verb) - > 1); > $this->_esmtp[$verb] = $arguments; > } > > > Now, what seems to be happening here is that the _negotiate function > (which sends the ehlo command) is setting ehlo responses even though > they are empty, thus initializing the variable. Since the variable is > empty, the _esmtp['SIZE'] is 0 (my server doesn't have a maximum > message size). This is throwing the off the data function since it's > checking the size instead of letting the SMTP server decide if the > message exceeds the size limit. Instead of having the Net::smtp > function check the size, shouldn't we let the SMTP return a permanent > failure (552) reply code? Or, if the server doesn't give a value for > the SIZE parameter, shouldn't it not be set - in effect, unlimited? > > I've commented out the message size check of the data function, and I > can now send mail. > > Jeff Graves > Customer Support Engineer > Image Source, Inc. > 10 Mill Street > Bellingham, MA 02019 > > jeff@image-src.com - Email > 508.966.5200 X31 - Phone > 508.966.5170 - Fax > > -----Original Message----- > From: imp-bounces@lists.horde.org > [mailto:imp-bounces@lists.horde.org]On > Behalf Of Jeff Graves > Sent: Friday, February 14, 2003 10:26 AM > To: imp@lists.horde.org > Subject: [imp] Problem sending mail using SMTP (was) Session timeout > when loggingon > > > Well, I dumped the stable code and went for the latest CVS code (horde > 3.0 and imp 4.0). I got it working using Mike's tutorial: > > > http://www.graftonhall.co.nz/mikes/Apache-Mysql-Php-Horde/Apache-PHP-H > orde-Win2K.html > > Except that I am running on IIS and I have just 1 problem. I can't > send mail. It returns with a unable to send data message in the > compose window. I triple-checked my configuration and permissions on > php and horde temporary folders and enabled auditing to see if some > user was failing to gain access but didn't see anything. The horde log > gives this error: > > Feb 13 20:03:13 HORDE [warning] [imp] unable to send data [on line 780 > of "D:\Websites\test\horde\imp\compose.php"] > > I opened up Network Monitor to what was being sent and it sends a EHLO > localhost. It then sends the MAIL FROM: command and server responds > 250. Then it sends the RCPT TO: command and server responds 250. Then, > IMP sends QUIT and drops the connection. No errors of any kind from > the server. Not sure if anyone's seen this before, but before I > started troubleshooting, wanted to know if anyone knows what's going > on here. > > Thanks, > > Jeff Graves > Customer Support Engineer > Image Source, Inc. > 10 Mill Street > Bellingham, MA 02019 > > jeff@image-src.com - Email > 508.966.5200 X31 - Phone > 508.966.5170 - Fax > > -----Original Message----- > From: imp-bounces@lists.horde.org > [mailto:imp-bounces@lists.horde.org]On > Behalf Of Jeff Graves > Sent: Thursday, February 13, 2003 11:03 AM > To: IMP List > Subject: [imp] Session timeout when logging on > > > Well, lost a hard drive the other day on our mail server and after > building a new one and restoring mail for my users, I decided I needed > to make life harder for myself so I figured, what the hell, let's > install horde/imp on a windows box instead of putting it back on the > linux mail server. Anyway, here's the config > > Win2k with IIS SP3 > PHP4, MySQL, PEAR > > I've tested them and they seem to be working properly. I installed > horde and configured horde.php with proper settings and set up a sql > prefs database and imap authentication. Without IMP, horde logs on > properly and I can change options no problem. If I install IMP, I then > get this message after submitting user and password: > > CGI Error > The specified CGI application misbehaved by not returning a complete > set of HTTP headers. The headers it did return are: > > FATAL: emalloc(): Unable to allocate -1616738196 bytes > > If I let IMP do the authentication (make change in registry.php and > horde.php) then the session timeouts after i click login. If I click > imp icon in the menu after login, IMP works normally. If i turn of the > sql prefs database in horde.php, the session proceeds to the imp > screen after login. The horde.log file shows authentication succeeded > in redirect.php. I'm not sure where to start looking. Is this possibly > a horde configuration problem (it looks to me like a mysql problem > since when I turn off the prefs database, imp responds immediately. > But then why does the prefs database work without IMP???), or is this > Win specific issue? > > Thanks, > > Jeff Graves > Customer Support Engineer > Image Source, Inc. > 10 Mill Street > Bellingham, MA 02019 > > jeff@image-src.com - Email > 508.966.5200 X31 - Phone > 508.966.5170 - Fax > > > -- > IMP mailing list > Frequently Asked Questions: http://horde.org/faq/ > To unsubscribe, mail: imp-unsubscribe@lists.horde.org > > > -- > IMP mailing list > Frequently Asked Questions: http://horde.org/faq/ > To unsubscribe, mail: imp-unsubscribe@lists.horde.org

« previous php.pear.dev (#13312) next »