AW: [PEAR-DEV] Net_SMTP - deadlock / robustness
| From: | Matthias Pigulla | Date: | Fri, 24 Dec 2004 11:55:51 +0000 |
| Subject: | AW: [PEAR-DEV] Net_SMTP - deadlock / robustness | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-35239@lists.php.net to get a copy of this message | ||
I think qmail is a little broken here, maybe it should return an error code for the first RCPT TO.
However, that would make no difference as the problem is that we're sending two commands
(because of the newline) but expect/process only one answer.
I can't think of any other case where you might get two separate (that is, not the
"mulitline" kind of) return codes, so making sure there's not return code left in the
buffer seems to be overkill (that also might cause a lot of headache having to use nonblocking
operations?).
So, asserting (maybe at a very low level) that no command sent contains CRLF (except when in DATA
mode) was the solution I had in mind, too. I was just unsure wheter it might break something else.
Have nice holidays,
Matthias
> -----Ursprüngliche Nachricht-----
> Von: Chuck Hagenbuch [mailto:chuck@horde.org]
> Gesendet: Freitag, 24. Dezember 2004 01:58
> An: pear-dev@lists.php.net
> Betreff: Re: [PEAR-DEV] Net_SMTP - deadlock / robustness
>
>
> Quoting Matthias Pigulla <mp@webfactory.de>:
>
> > Otherwise, we might want to check parameters more carefully; or we
> > might even improve handling of the return codes to make sure no
> > "extra" replies keep hanging around in the buffers.
> Actually, having
> > the extra 502 return code hanging in the buffer is what makes us
> > running into this dead end street - if we would completely read the
> > return buffer after each command, we could see that the
> DATA command
> > actually succeeded.
>
> So, look at the code in _parseResponse(). I'm just not sure
> how to correctly interpret that response from Qmail. It's
> saying that part of the "address" succeeded, and then part
> failed - like 2 RCPT TO commands. _parseResponse() already
> handles regular multiline responses, so maybe the way to go
> is to make sure we don't send any commands that can be
> interpreted as multiple commands - i.e, disallow newlines in
> commands other than DATA (any others?).
>
> Does that sound like a workable solution?
>
> -chuck