Johan Almqvist <[EMAIL PROTECTED]> writes:
> * Ian Lance Taylor <[EMAIL PROTECTED]> [010115 23:53]:
> > I don't see it. Russ's patch looks like this (at least, in the
> > version I downloaded):
> > + if (qmtp_priority(ip.ix[i].pref)) {
> > + if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int)
>qmtp_port,timeoutconnect) == 0) {
> > + tcpto_err(&ip.ix[i].ip,0);
> > + partner = ip.ix[i].ip;
> > + qmtp(); /* does not return */
> > + }
> > + }
> > + if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) smtp_port,timeoutconnect)
>== 0) {
> > In other words, if the MX priority indicates QMTP, try to make a QMTP
> > connection. If that connection fails--if it times out, or if the
> > remote system does not accept the connect request--timeoutconn will
> > return -1 and qmail-remote will go on to try to make an SMTP
> > connection.
>
> timeoutconn seems to only return -1 when the attemt times out, NOT if the
> remote system doesn't accept the connection attempt. (That's what my
> experiments have shown, at least... I'd like very much for this to be
> seconded by others before I have another go at this!)
Interesting. What type of system are you running? The code in
timeoutconn.c uses getpeername to check whether the connect really
succeeded. This is as DJB suggests in
http://cr.yp.to/docs/unixport.html
When I look at timeoutconn.c, it looks to me like it should return -1
if the connect attempt fails. Any other result implies that
getpeername succeeds when the socket is not connected.
Ian
