Re: Possible problem with qmail-qmtpc patch
On Sun, 14 Jan 2001 20:25:44 +0100, Jurjen Oskam wrote: On Sun, 14 Jan 2001 13:39:01 -0500 (EST), Russell Nelson [EMAIL PROTECTED] wrote: That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of ... delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. But isn't that a bit in contradiction with the concept of backup MX'es? If the goal is to deliver E-mail securely and quickly, falling back to (a presumed functional) SMTP server fits the bill. If the goal is to use QMTP "just because its there", then Russ' comments make more sense. -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/
Re: Possible problem with qmail-qmtpc patch
* Ian Lance Taylor [EMAIL PROTECTED] [010116 19:36]: Now I see it. You can't call connect twice on the same socket. This patch, on top of Russ's patch, fixes it. This patch very much fixes it for my patch, too. Thanks a bunch, Ian! This leads me to the next thing (concerning my patch): If someone specifies QMTP to a certain port in control/mailroutes, and that fails - what'd I do? Try SMTP to port 25, give up temporarily (which would happen if it were an SMTP route) of give up permanently (don't think so...) At the moment, SMTP to port 25 will be attempted. If that fails, there'll be a tempoary error. -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: Possible problem with qmail-qmtpc patch
Ian Lance Taylor writes: Ian Lance Taylor [EMAIL PROTECTED] writes: I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running) this failure will be logged as deferral: Connected_to_194.47.249.19_but_connection_died._(#4.4.2)/ which means that the message will not be retried at the next best MX but go back to the queue. I don't see it. Now I see it. You can't call connect twice on the same socket. This patch, on top of Russ's patch, fixes it. Thanks for catching and fixing this bug. I'm glad *you* knew that you can't call connect twice on the same socket. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: Possible problem with qmail-qmtpc patch
On Wed, Jan 17, 2001 at 10:21:53AM -0500, Russell Nelson wrote: [snip] Thanks for catching and fixing this bug. I'm glad *you* knew that you can't call connect twice on the same socket. Actually you can, but only under specific circumstances, being: the first connect being done nonblocked and not having reached a final state (either connected or failed), and the second connect being to the exact same host and port. So much for educational value. Glad it got fixed. Greetz, Peter.
Re: Possible problem with qmail-qmtpc patch
* 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!)
-Johan
--
Johan Almqvist
http://www.almqvist.net/johan/qmail/
PGP signature
Re: Possible problem with qmail-qmtpc patch
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
Re: Possible problem with qmail-qmtpc patch
Ian Lance Taylor [EMAIL PROTECTED] writes:
I think there may be a problem with the patches to qmail-remote that make
it speak QMTP based on MXPS.
If the QMTP connection fails (because the remote host doesn't have a qmtpd
running) this failure will be logged as
deferral: Connected_to_194.47.249.19_but_connection_died._(#4.4.2)/
which means that the message will not be retried at the next best MX but
go back to the queue.
I don't see it.
Now I see it. You can't call connect twice on the same socket. This
patch, on top of Russ's patch, fixes it.
Ian
--- qmail-remote.c.~1~ Sat Jan 6 22:49:02 2001
+++ qmail-remote.c Tue Jan 16 10:30:29 2001
@@ -531,6 +531,9 @@
partner = ip.ix[i].ip;
qmtp(); /* does not return */
}
+ close(smtpfd);
+ smtpfd = socket(AF_INET,SOCK_STREAM,0);
+ if (smtpfd == -1) temp_oserr();
}
if (timeoutconn(smtpfd,ip.ix[i].ip,(unsigned int) smtp_port,timeoutconnect) ==
0) {
tcpto_err(ip.ix[i].ip,0);
Re: Possible problem with qmail-qmtpc patch
Russell Nelson [EMAIL PROTECTED] writes: Johan Almqvist writes: Hi! I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of the MXPS standard (which admittedly includes 99.99% of the world's population) could have set their MX priority to 12801. If so, it's best to ask them to change their MX priority. I think that's probably the opposite of what the user who sent the message wants. Far better to deliver the message, and include an option for mail administrators who are concerned about these things to log the "downshift" to SMTP. If they're concerned, they can look through their logs (perhaps from a script run from cron), and fix their own system, or contact the administrator of the misconfigured system. The sender, who will receive the bounce message, can do nothing to correct misconfiguration on their side or the recipient's side. It does no good to send a message to *them* about the misconfiguration, which probably will never reach any of the involved mail administrators. And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. The idea of multiple vendors introducing incompatible extensions to the mail delivery process, and having messages bounce if their conditions are not met, makes me very uncomfortable. A mail sysadmin should be able to read their own system's documentation, and all relevant mail RFCs, and have a complete working system. They should not be required to read the documentation of every existing mail system to find out about incompatible extensions. If MXPS was a standards-track RFC, the situation would be different, but I still see no reason to bounce messages that can be delivered. It's much more likely that someone intends that the email be delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. Then provide a script to analyze these logs and email the concerned parties. -ScottG.
Re: Possible problem with qmail-qmtpc patch
Scott Gifford [EMAIL PROTECTED] writes on 15 January 2001 at 17:24:13 -0500 And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. I think that's the clinching argument; it's vital that people using MX in full accordance with the RFCs who happen to hit our magic numbers not get screwed. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: Possible problem with qmail-qmtpc patch
David Dyer-Bennet writes: Scott Gifford [EMAIL PROTECTED] writes on 15 January 2001 at 17:24:13 -0500 And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. I think that's the clinching argument; it's vital that people using MX in full accordance with the RFCs who happen to hit our magic numbers not get screwed. Why not ask him to change his MX number? There can be at most one host which has port 209 bound AND an MX priority in the 12800-13056 range. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Possible problem with qmail-qmtpc patch
Hi! I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running) this failure will be logged as deferral: Connected_to_194.47.249.19_but_connection_died._(#4.4.2)/ which means that the message will not be retried at the next best MX but go back to the queue. There is also a minor glitch in my patch that would make qmail-remote try SMTP if a QMTP connection can't be established, even if QMTP is forced by control/mailroutes. I think this is NOT what people would expect? -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: Possible problem with qmail-qmtpc patch
Johan Almqvist writes: Hi! I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of the MXPS standard (which admittedly includes 99.99% of the world's population) could have set their MX priority to 12801. If so, it's best to ask them to change their MX priority. It's much more likely that someone intends that the email be delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Government is the Crynwr sells support for free software | PGPok | fictitious entity by which 521 Pleasant Valley Rd. | +1 315 268 1925 voice | everyone seeks to live at Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | everyone else's expense.
Re: Possible problem with qmail-qmtpc patch
* Russell Nelson [EMAIL PROTECTED] [010114 19:39] That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. Well, at the moment it'll only be bounced after queuelifetime... It could be that someone unaware of the MXPS standard (which admittedly includes 99.99% of the world's population) could have set their MX priority to 12801. If so, it's best to ask them to change their MX priority. Agreed. What happens if they don't? It's much more likely that someone intends that the email be delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. ...or look at their Received: lines from time to time. After setting up QMTP service and MXPS I suspect most people will watch their logs rather closely for a few days... -Johan PS: Love the double spacing... -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: Possible problem with qmail-qmtpc patch
On Sun, 14 Jan 2001 13:39:01 -0500 (EST), Russell Nelson [EMAIL PROTECTED] wrote: Johan Almqvist writes: If the QMTP connection fails (because the remote host doesn't have a qmtpd running That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of What happens in the following case: quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12817 b.mx.quadpro.stupendous.org ...when qmtpd isn't reachable on a.mx.quadpro.stupendous.org? delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. But isn't that a bit in contradiction with the concept of backup MX'es? end -- Jurjen Oskam * carnivore! * http://www.stupendous.org/ for PGP key assassinate nuclear iraq clinton kill bomb USA eta ira cia fbi nsa kill president wall street ruin economy disrupt phonenetwork atomic bomb sarin nerve gas bin laden military -*- DVD Decryption at www.stupendous.org -*-
Re: Possible problem with qmail-qmtpc patch
* Jurjen Oskam [EMAIL PROTECTED] [010114 20:25] What happens in the following case: quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12817 b.mx.quadpro.stupendous.org ...when qmtpd isn't reachable on a.mx.quadpro.stupendous.org? That's the problem I tried to describe. In my experience, the message goes back to the queue and will be retried to a.mx.quadpro.stupendous.org by QMTP later. And this will happen until qmail-send decides the message has been in the queue too long, whereupon it will be bounced. However, I'm not 100% sure about this, as my network setup is a little too small and limited by university-controlled firewalls and university- administered DNS servers. delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. But isn't that a bit in contradiction with the concept of backup MX'es? Er, yes. -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: Possible problem with qmail-qmtpc patch
* Johan Almqvist [EMAIL PROTECTED] [010114 15:45]: I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running) this failure will be logged as deferral: Connected_to_194.47.249.19_but_connection_died._(#4.4.2)/ which means that the message will not be retried at the next best MX but go back to the queue. Ok, as I said, my test setup wasn't the best, so this only happens if the host is _there_ but not running qmtpd. That's probably what we want anyhow... -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
