Re: patch combination: qmtp + outgoingip
Just FYI in case anyone was losing sleep over not being able to use the QMTP patch and the outgoing IP patche to qmail-remote.c at the same time. Well, and also to prevent my previous post from being an archive orphan. It turns out that the additional qmail_remote.c code for QMTP totally confuses the outgoingip patch, and even if the patch wasn't confused, it would have missed out on patching the additional call to the new flavor of timeoutconn(). With too few arguments passed in both cases, no wonder qmail_remote was choking. Case closed. Later, JS On Fri, May 18, 2001 at 05:31:19PM -0400, Jim Steele wrote: Does anyone have a qmail-remote.c that has been patched for qmtp AND outgoingip? I must have botched the patch combination, since I now get: qmail-remote2001-05-18 17:21:26.339297500 delivery 1: deferral: qmail-remote_crashed./ Thank goodness I backed up the binaries and use RCS on the source. Thanks, JS
patch combination: qmtp + outgoingip
Does anyone have a qmail-remote.c that has been patched for qmtp AND outgoingip? I must have botched the patch combination, since I now get: qmail-remote2001-05-18 17:21:26.339297500 delivery 1: deferral: qmail-remote_crashed./ Thank goodness I backed up the binaries and use RCS on the source. Thanks, JS
Re: qmtp
Hey just curious is anyone implementing qmtp presently? Yes, without problems. But also without big impact :) Regards, Frank
qmtp
Hey just curious is anyone implementing qmtp presently? I thought about giving it a whirl but wouldnt do much good if im the only one. Administrator Steve Hagerman [EMAIL PROTECTED] http://www.advancedisp.com/ Phone: 864-220-1594
Re: qmtp
On Fri, May 04, 2001 at 01:58:26PM -0400, Steve Hagerman wrote: Hey just curious is anyone implementing qmtp presently? Meaning the modified qmail-remote, running qmail-qmtpd and annoucing this via MXPS? We do it for everthing hosted here. I thought about giving it a whirl but wouldnt do much good if im the only one. You aren't. There are coming mails in via qmtp, though it's less then 1%. -- * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * * Roedingsmarkt 14, 20459 Hamburg, Germany * Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: qmtp
Steve Hagerman [EMAIL PROTECTED] wrote: Hey just curious is anyone implementing qmtp presently? Yes, many people on this list are using Dan's MXPS proposal. Russell Nelson and others have QMTP patches for qmail. See qmail.org for details. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: qmtp
On Fri, May 04, 2001 at 01:58:26PM -0400, Steve Hagerman wrote: Hey just curious is anyone implementing qmtp presently? I thought about giving it a whirl but wouldnt do much good if im the only one. I provide lists that deliver over qmtp if your MX records are MXPS-compliant. Go to http://www.dataloss.nl/services/ for more info. Greetz, Peter.
Re: qmtp
* Charles Cazabon [EMAIL PROTECTED] [010504 20:42]: Steve Hagerman [EMAIL PROTECTED] wrote: Hey just curious is anyone implementing qmtp presently? Yes, many people on this list are using Dan's MXPS proposal. Russell Nelson and others have QMTP patches for qmail. See qmail.org for details. There's also a set of patches on my page (address below). -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
QMTP
Hi! I'm running Qmail-1.03 (big-dns.patch, big-concurrency.patch, badmailfrom.patch, AND qmail-1.03-qmtpc.patch), daemontools, ucspi-tcp on testing servers. I add on my DNS: INMX12800mail.myserver.com. ; for SMTP service INMX12801mail.myserver.com. ; for QMTP service I'm running under the supervise script the qmtpd service ... when I send a mail to myserver.com, the qmail-remote communicate to SMTP instead of QMTP :( Why?? Thanks! :)
Re: QMTP
Federico Edelman Anaya [EMAIL PROTECTED] wrote: INMX12800mail.myserver.com. ; for SMTP service INMX12801mail.myserver.com. ; for QMTP service I'm running under the supervise script the qmtpd service ... when I send a mail to myserver.com, the qmail-remote communicate to SMTP instead of QMTP :( Because the SMTP-related MX has a lower distance than the QMTP-related MX. If you have one MX host that supports QMTP and SMTP (which it has to), just create one MX record with a distance of 12801. -- Dan Peterson [EMAIL PROTECTED] http://danp.net
Re: QMTP
On Thu, Mar 22, 2001 at 02:38:34PM +, Federico Edelman Anaya wrote: I'm running Qmail-1.03 (big-dns.patch, big-concurrency.patch, badmailfrom.patch, AND qmail-1.03-qmtpc.patch), daemontools, ucspi-tcp on testing servers. I add on my DNS: INMX12800mail.myserver.com. ; for SMTP service INMX12801mail.myserver.com. ; for QMTP service I'm running under the supervise script the qmtpd service ... when I send a mail to myserver.com, the qmail-remote communicate to SMTP instead of QMTP :( Read http://cr.yp.to/proto/mxps.txt. You want to remove the 12800 entry and leave only the 12801 entry. Hosts that support QMTP will see the 12801 preference and attempt to communicate via QMTP; hosts that don't will try SMTP. Chris PGP signature
qmtp
im looking for usage stats on qmtp. it sounds like something that i'm interested in however i wonder how many hosts use it ~kurth
Re: qmtp
On Thu, Mar 08, 2001 at 03:17:30PM -0500, Kurth Bemis wrote: im looking for usage stats on qmtp. it sounds like something that i'm interested in however i wonder how many hosts use it Few. Join us :) http://www.almqvist.net/johan/qmail/ for all the patches you need. Greetz, Peter.
QMTP/mail distribution
hi all- i currently have a setup where one central mail server receives all mail for a primary domain, then redistributes it to subdomains (eg satellite offices) as necessary. this is currently done with fastforward and SMTP. i'd like to try out QMTP, and use this to forward mail from the central server out to the satellites. is there an easy way to cofigure the cenral server to know who it can/should speak QMTP with? it seems very straightforward to receive QMTP messages, but i'm not sure if there's a great way to decide when to send QMTP mail. thanks- dan
Re: QMTP/mail distribution
On Sun, Mar 04, 2001 at 09:17:09PM -0500, Daniel Kelley wrote: i currently have a setup where one central mail server receives all mail for a primary domain, then redistributes it to subdomains (eg satellite offices) as necessary. this is currently done with fastforward and SMTP. i'd like to try out QMTP, and use this to forward mail from the central server out to the satellites. is there an easy way to cofigure the cenral server to know who it can/should speak QMTP with? it seems very straightforward to receive QMTP messages, but i'm not sure if there's a great way to decide when to send QMTP mail. Try this patch to qmail: http://www.almqvist.net/johan/qmail/qmail-qmtpc.html Or this one: http://www.qmail.org/qmail-1.03-qmtpc.patch in conjunction with: http://cr.yp.to/proto/mxps.txt Chris PGP signature
Re: QMTP/mail distribution
On Sun, Mar 04, 2001 at 09:17:09PM -0500, Daniel Kelley wrote: hi all- i currently have a setup where one central mail server receives all mail for a primary domain, then redistributes it to subdomains (eg satellite offices) as necessary. this is currently done with fastforward and SMTP. i'd like to try out QMTP, and use this to forward mail from the central server out to the satellites. is there an easy way to cofigure the cenral server to know who it can/should speak QMTP with? it seems very straightforward to receive QMTP messages, but i'm not sure if there's a great way to decide when to send QMTP mail. Go to http://www.almqvist.net/johan/qmail/qmail-qmtpc.html, download the patch and read man qmail-remote on mailroutes. Greetz, Peter.
QMTP/MXPS on cr.yp.to?
Because of having been offline for six weeks in December/January I totally missed the QMTP/MXPS discussions. After some reading in the archive I installed Johan Almqvists patch to enable QMTP through MXPS (I had running qmtpd for a long while). I just checked the logs and found that not a single message arrived through QMTP. Then I looked at a.mx.list.cr.yp.to if there is a qmtp port. It seems that Dan doesn't run QMTP - even for receiving. I think Dan's lists would be a good real life test for QMTP/MXPS - so does anybody know why Dan isn't running QMTP? Regards, Frank
Re: QMTP/MXPS on cr.yp.to?
On Fri, Feb 16, 2001 at 10:28:33AM +0100, Frank Tegtmeyer wrote: Because of having been offline for six weeks in December/January I totally missed the QMTP/MXPS discussions. After some reading in the archive I installed Johan Almqvists patch to enable QMTP through MXPS (I had running qmtpd for a long while). I just checked the logs and found that not a single message arrived through QMTP. Then I looked at a.mx.list.cr.yp.to if there is a qmtp port. It seems that Dan doesn't run QMTP - even for receiving. I think Dan's lists would be a good real life test for QMTP/MXPS - so does anybody know why Dan isn't running QMTP? No, we don't know. However, if you subscribe to [EMAIL PROTECTED] instead of [EMAIL PROTECTED], you'll get the list over QMTP. http://www.dataloss.nl/services/ for the whole set of lists I offer with QMTP support. Greetz, Peter.
QMTP
Where can I get help about qmail with qmtp?
Re: QMTP
* Federico Edelman Anaya [EMAIL PROTECTED] [010216 12:29]: Where can I get help about qmail with qmtp? http://www.almqvist.net/johan/qmail/qmail-qmtpc.html -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: QMTP
Where can I get help about qmail with qmtp? Describe your problem, then someone may be able to help you. If you want to run qmail-qmtpd - that's not different from qmail-smtpd. If you want to use one of the qmtp-patches to qmail-remote you have to get them first. Look at www.qmail.org for Russell's patch or at http://www.almqvist.net/johan/qmail/qmail-qmtpc.html for Johan ALmqvist's patch. Regards, Frank
Re: QMTP
On Fri, Feb 16, 2001 at 04:42:04PM +0100, Johan Almqvist wrote: * Federico Edelman Anaya [EMAIL PROTECTED] [010216 12:29]: Where can I get help about qmail with qmtp? http://www.almqvist.net/johan/qmail/qmail-qmtpc.html And when you have that set up, go to http://www.dataloss.nl/services/ to find out how to receive the qmail mailinglist and others via QMTP. Greetz, Peter.
Re: QMTP
I am running qmail-1.03 + big-concurrency.patch + qmail-1.03-big-dns.patch + badrcptto.patch + qmail-1.03-qmtpc-mailroutes-1.5.patch in two servers But.. I don't understand how qmail work with control/mailroutes.. I can't get help for this implementation.. Daemontools-0.70 qmail-conf-0.54 ucspi-tcp-0.88 The system run under supervise script ( service/qmail , service/qmail-smtpd , service/qmail-qmtpd) Well.. I sent a message to [EMAIL PROTECTED] to verify my configuration .. but I am under a firewall. I received a mail from this server. My server 1 send a mails to qmtp service. But, when I sent a mail from Server 1 to Server 2, the mail was sent to SMTP service .. I don't know what I do because I don't know exactly work the qmail qmtp service .. or mailroutes ..:((( Where I can get information about this problem? :) Thanks! Frank Tegtmeyer wrote: Where can I get help about qmail with qmtp? Describe your problem, then someone may be able to help you. If you want to run qmail-qmtpd - that's not different from qmail-smtpd. If you want to use one of the qmtp-patches to qmail-remote you have to get them first. Look at www.qmail.org for Russell's patch or at http://www.almqvist.net/johan/qmail/qmail-qmtpc.html for Johan ALmqvist's patch. Regards, Frank
Re: QMTP
But.. I don't understand how qmail work with control/mailroutes.. I can't get help for this implementation.. This is documented in the updated man page for qmail-remote. but I am under a firewall. I received a mail from this server. My server 1 send a mails to qmtp service. But, when I sent a mail from Server 1 to Server 2, the mail was sent to SMTP service .. I don't know what I do because I don't know exactly work the qmail qmtp service .. or mailroutes ..:((( If port 209 is firewalled at your site you will never send/receive with qmtp. qmail-remote always falls back to smtp in this case. Regards, Frank
Re: QMTP
Yeah.. the port 209 is firewalled .. but.. the server1 and server2 are locals machines .. Frank Tegtmeyer wrote: But.. I don't understand how qmail work with control/mailroutes.. I can't get help for this implementation.. This is documented in the updated man page for qmail-remote. but I am under a firewall. I received a mail from this server. My server 1 send a mails to qmtp service. But, when I sent a mail from Server 1 to Server 2, the mail was sent to SMTP service .. I don't know what I do because I don't know exactly work the qmail qmtp service .. or mailroutes ..:((( If port 209 is firewalled at your site you will never send/receive with qmtp. qmail-remote always falls back to smtp in this case. Regards, Frank
Re: QMTP
Yeah.. the port 209 is firewalled .. but.. the server1 and server2 are locals machines .. How do you route between them? If you used smtproutes before you have to use mailroutes now. server1.example.com:[192.168.1.1]:209:qmtp and server2.example.com:[192.168.1.2]:209:qmtp at the other machine. If you use DNS set the correct MX preferences (12801). Did you restart qmail after applying the patch? Just to be sure ... Regards, Frank
Re: QMTP
U.. I'd like the Qmail send to QMTP if the remote host have this service .. but if the remote host don't have running de QMTP service .. my sever send to SMTP service .. :) Is this way the qmail work? Frank Tegtmeyer wrote: Yeah.. the port 209 is firewalled .. but.. the server1 and server2 are locals machines .. How do you route between them? If you used smtproutes before you have to use mailroutes now. server1.example.com:[192.168.1.1]:209:qmtp and server2.example.com:[192.168.1.2]:209:qmtp at the other machine. If you use DNS set the correct MX preferences (12801). Did you restart qmail after applying the patch? Just to be sure ... Regards, Frank
Re: QMTP
U.. I'd like the Qmail send to QMTP if the remote host have this service .. but if the remote host don't have running de QMTP service .. my sever send to SMTP service .. :) Is this way the qmail work? No, this is only the fallback of the qmtp-patch. The actual patch implementation checks if QMTP is (better: could be) available at the destination. This is done through mailroutes or through MX preferences (see Dan's MXPS documentation at http://cr.yp.to/proto/mxps.txt). If that fails (f.e. because of firewalled port) the above mentioned fallback is activated. Regards, Frank
Re: qmtp and spammers.
On Tue, 6 Feb 2001, Sam Trenholme wrote: On Thu, 1 Feb 2001, Faried Nawaz wrote: With QMTP, you get C: message and sender and recipients sent before the server says anything, tying up the connection for 30 seconds and wasting bandwidth S: 7:Dgo away, This also wastes the Spammer's time and bandwidth. If you really want to make spammers waste their time and bandwidth (and you have got bandwidth to waste yourself), you should pretend to accept their junk and discard it. And of course, you should also fool their scans testing whether the mail server acts as an open relay or not by sending a real short message (making the difference between early and late refusal irrelevant from their pov). --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation."
qmtp and spammers.
QMTP may be faster than SMTP for sending mail, but it seems less powerful in our spam-happy Internet era. How would one go about rejecting incoming QMTP mail? The protocol suggests that there is no way of writing some equivalent of rblsmtpd. The shipped qmail-qmtpd.c in qmail 1.03 doesn't even read control/badmailfrom. This means that servers running QMTP will have to do more processing after accepting mail to weed out spammers and other undesirable mail senders.
Re: qmtp and spammers.
Faried Nawaz writes: QMTP may be faster than SMTP for sending mail, but it seems less powerful in our spam-happy Internet era. I think you mean Dan's implementation is 'less powerful'; it has nothing to do with the protocol. Has anyone seen spam enter their network via qmail-qmtpd? Vince.
Re: qmtp and spammers.
Vincent Schonau wrote: I think you mean Dan's implementation is 'less powerful'; it has nothing to do with the protocol. With SMTP, you get S: 220 hi, it's me! C: mail from: [EMAIL PROTECTED] S: 551 go away With QMTP, you get C: message and sender and recipients sent before the server says anything, tying up the connection for 30 seconds and wasting bandwidth S: 7:Dgo away, Has anyone seen spam enter their network via qmail-qmtpd? I don't want to wait until it's commonplace before doing something to keep it out.
QMTP protocol spec question
the QMTP spec includes: 8. Examples A client opens a connection and sends the concatenation of the following strings: "246:" 0a "Received: (qmail-queue invoked by uid 0);" " 29 Jul 1996 09:36:40 -" 0a "Date: 29 Jul 1996 11:35:35 -" 0a "Message-ID: [EMAIL PROTECTED]" 0a "From: [EMAIL PROTECTED]" 0a "To: [EMAIL PROTECTED] (D. J. Bernstein)" 0a 0a "This is a test." 0a "," "24:" "[EMAIL PROTECTED]" "," "30:" "26:[EMAIL PROTECTED]," "," "356:" 0d "From: [EMAIL PROTECTED]" 0d 0a "To:" 0d 0a " Hate." 22 "The Quoting" 22 "@SILVERTON.berkeley.edu," 0d 0a " " 22 "\\Backslashes!" 22 "@silverton.BERKELEY.edu" 0d 0a 0d 0a "The recipient addresses here could" " have been encoded in SMTP as" 0d 0a "" 0d 0a " RCPT TO:Hate.The\ [EMAIL PROTECTED]" 0d 0a " RCPT TO:\\[EMAIL PROTECTED]" 0d 0a 0d 0a "This ends with a partial last line, right here" "," "0:" "," "83:" "39:Hate.The [EMAIL PROTECTED]," "36:\[EMAIL PROTECTED]," "," The server sends the following response, indicating acceptance: "21:Kok 838640135 qp 1390," "21:Kok 838640135 qp 1391," "21:Kok 838640135 qp 1391," The client closes the connection. I am confused. Why are there three responses for two recip. addrs? The zero length is the envelope sender -- Is that acceptable? Is the is the second server response doubled in the http://cr.yp.to/proto/qmtp.txt document? -- David Nicol 816.235.1187 [EMAIL PROTECTED] "gorkulator borked. Please investigate."
Re: QMTP protocol spec question
On Thu, Feb 01, 2001 at 05:23:07PM -0600, David L. Nicol wrote: [snip] The server sends the following response, indicating acceptance: "21:Kok 838640135 qp 1390," "21:Kok 838640135 qp 1391," "21:Kok 838640135 qp 1391," The client closes the connection. I am confused. Why are there three responses for two recip. addrs? Looks like a duplication by accident. Test: $ echo -ne '10:\nhoihoihoi,0:,15:5:peter,4:root,,' | nc localhost 209 20:Kok 981074304 qp 404,20:Kok 981074304 qp 404, Two recipients, two responses. Looks like a bug in the document. The zero length is the envelope sender -- Is that acceptable? Yes, that's normal for mails from MAILER-DAEMON (bounces and the like) Is the is the second server response doubled in the http://cr.yp.to/proto/qmtp.txt document? I think the first one shouldn't be there, because it will usually give the same response for each recipient. Either way, there's one response too many in there. Greetz, Peter.
Re: QMTP protocol spec question
Peter van Dijk [EMAIL PROTECTED] wrote: Two recipients, two responses. Looks like a bug in the document. There are three recipients across two messages. The first has one, the second has two. -- Dan Peterson [EMAIL PROTECTED] http://danp.net
Re: qmtp and spammers.
On Thu, Feb 01, 2001 at 03:08:32AM +0459, Faried Nawaz wrote: QMTP may be faster than SMTP for sending mail, but it seems less powerful in our spam-happy Internet era. How would one go about rejecting incoming QMTP mail? The protocol suggests that there is no way of writing some equivalent of rblsmtpd. The shipped qmail-qmtpd.c in qmail 1.03 doesn't even read control/badmailfrom. I wrote a patch to make badmailfrom work in qmail-qmtpd. It's on Johan Almqvist's QMTP page. An rblqmtpd should be very possible, I see no real problems there. Just reply 'deferred' for every recipient. Greetz, Peter.
Re: QMTP MX-question
On Tue, Jan 16, 2001 at 05:16:45AM -, D. J. Bernstein wrote: Johan Almqvist writes: Quoting http://cr.yp.to/proto/mxps.txt Don't believe everything you read. :-) My original design made QMTP-only mail exchangers easier but made QMTP+SMTP mail exchangers harder. This was a bad tradeoff. Clients should interpret a QMTP priority as ``try QMTP, then try SMTP.'' Which is my interpretation of part of the spec, but another part contradicts this. Then a typical SMTP host that adds QMTP support can keep its single MX record but change the priority. Could you please revise the spec? Greetz, Peter.
Re: QMTP MX-question
D. J. Bernstein writes: Johan Almqvist writes: Quoting http://cr.yp.to/proto/mxps.txt Don't believe everything you read. :-) My original design made QMTP-only mail exchangers easier but made QMTP+SMTP mail exchangers harder. This was a bad tradeoff. Clients should interpret a QMTP priority as ``try QMTP, then try SMTP.'' Then a typical SMTP host that adds QMTP support can keep its single MX record but change the priority. That's what I intended to do. Ian Lance Taylor has pointed out that I failed to test the case of a host having a QMTP priority but no QMTP server. I'll reissue the patch in a day or so after I finish off with a customer's deadline. -- -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: QMTP MX-question
On Sun, Jan 14, 2001 at 03:05:16PM +0100, Jurjen Oskam wrote: [snip] However, when I query for crynwr.com, I get: crynwr.com 86354 MX 12801 pdam.crynwr.com crynwr.com 86354 MX 12816 pdam.crynwr.com This set of MX records compensates for a bug in Russell's QMTP implementation (that has not been fixed in Johan Almqvist's patches yet either). Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me 'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me
Re: QMTP MX-question
Johan Almqvist writes: Quoting http://cr.yp.to/proto/mxps.txt Don't believe everything you read. :-) My original design made QMTP-only mail exchangers easier but made QMTP+SMTP mail exchangers harder. This was a bad tradeoff. Clients should interpret a QMTP priority as ``try QMTP, then try SMTP.'' Then a typical SMTP host that adds QMTP support can keep its single MX record but change the priority. ---Dan
QMTP MX-question
Situation: The primary MX for quadpro.stupendous.org is capable of accepting mail via QMTP, and regularly does so. Of course, it is also capable of accepting mail via SMTP. The 'secondary' MX is only capable of doing SMTP. What are the correct MX-records I should create? I made: quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 b.mx.quadpro.stupendous.org However, when I query for crynwr.com, I get: crynwr.com 86354 MX 12801 pdam.crynwr.com crynwr.com 86354 MX 12816 pdam.crynwr.com Here you have two MX-priorities (or distances) for the same name. Is it a good idea to change the MX records for quadpro.stupendous.org so that the result is: quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 b.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12832 a.mx.quadpro.stupendous.org or quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12832 b.mx.quadpro.stupendous.org ? 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: QMTP MX-question
On Sun, Jan 14, 2001 at 03:05:16PM +0100, Jurjen Oskam wrote: What are the correct MX-records I should create? I made: quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 b.mx.quadpro.stupendous.org That is correct. quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12832 b.mx.quadpro.stupendous.org Quoting http://cr.yp.to/proto/mxps.txt " Example: [...] B.EXAMPLE.ORG IN MX 12801 A.EXAMPLE.ORG IN MX 12816 C.EXAMPLE.ORG [...] A sender with a message for B.EXAMPLE.ORG will try A.EXAMPLE.ORG by QMTP, then C.EXAMPLE.ORG by SMTP. If it does not support QMTP, it may try SMTP instead of QMTP, or it may skip A.EXAMPLE.ORG." Note the "...or it may skip..." part. -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: QMTP MX-question
On Sun, 14 Jan 2001 15:12:09 +0100, Johan Almqvist [EMAIL PROTECTED] wrote: Quoting http://cr.yp.to/proto/mxps.txt " Example: [...] B.EXAMPLE.ORG IN MX 12801 A.EXAMPLE.ORG IN MX 12816 C.EXAMPLE.ORG [...] A sender with a message for B.EXAMPLE.ORG will try A.EXAMPLE.ORG by QMTP, then C.EXAMPLE.ORG by SMTP. If it does not support QMTP, it may try SMTP instead of QMTP, or it may skip A.EXAMPLE.ORG." Note the "...or it may skip..." part. I've read that page a few times myself. Since I'm not a native English speaker, I'm having trouble figuring out what it *exactly* means. In particular, the "it" in "If it does not support QMTP, ...". Does "it" refer to "a sender with a message for B.EXAMPLE.ORG"? (That would make sense.) In that case, you have the possibilities: 1) MXPS-aware sender with *no support* for QMTP. Such a sender would most likely skip A.EXAMPLE.ORG. (But it could just as well deliver via SMTP) 2) A 'normal' sender, without MXPS or QMTP. Such a sender would just deliver to the lowest preference using SMTP only. But I'm interested in the case where an MXPS-aware QMTP-capable sender tries to deliver a message to quadpro.stupendous.org (with MX records set according to [1], but finds port 209 (QMTP) unavailable. Will such a sender then (directly after the failure to deliver to a.mx.stupendous.org using QMTP): 1) try to deliver to b.mx.quadpro.stupendous.org using SMTP or 2) try to deliver to a.mx.stupendous.org using SMTP? And if I change the MX-records to [2], will that behaviour change? [1] quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 b.mx.quadpro.stupendous.org [2] quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12832 b.mx.quadpro.stupendous.org 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: QMTP MX-question
On Sun, Jan 14, 2001 at 03:38:40PM +0100, Jurjen Oskam wrote: But I'm interested in the case where an MXPS-aware QMTP-capable sender tries to deliver a message to quadpro.stupendous.org (with MX records set according to [1], but finds port 209 (QMTP) unavailable. Will such a sender then (directly after the failure to deliver to a.mx.stupendous.org using QMTP): 1) try to deliver to b.mx.quadpro.stupendous.org using SMTP or 2) try to deliver to a.mx.stupendous.org using SMTP? And if I change the MX-records to [2], will that behaviour change? In theory you option no. 2 is the best way, it says "try a.mx via qmtp, on failure try a.mx via smtp, on failure use b.mx via smtp". In practice you could also use option 1, as the only MXPS capable sender is Russels patched qmail-remote AFAIK, and everbody using it will support qmtp (everything else, e. g. the port is closed within the firewall, i would call a misconfiguration). Anyway I'd vote for option 2, it's the clearest ;-) [1] quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 b.mx.quadpro.stupendous.org [2] quadpro.stupendous.org 86323 MX 12801 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12816 a.mx.quadpro.stupendous.org quadpro.stupendous.org 86323 MX 12832 b.mx.quadpro.stupendous.org -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg http://www.bsws.de | Germany
Re: QMTP running on sources.redhat.com
On Wed, Jan 10, 2001 at 11:38:23PM -0500, Russell Nelson wrote: Now, who wants to work on cqmtp (compressed quick mail transport protocol)? :) No reason why you couldn't run gzip on the whole chunk before sending it off. Save the children! Save Dave and Virginia! http://cr.yp.to/sarcasm/modest-proposal.txt -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
QMTP sublist
QMTP-delivering sublist up and running. Send to [EMAIL PROTECTED] to use it. The host does SMTP too, if you feel like just using a closer sublist and not even care about QMTP. Will create more sublists as people show demand. Greetz, Peter.
QMTP running on sources.redhat.com
I installed QMTP on sources.redhat.com. sources.redhat.com, formerly sourceware.cygnus.com, is the host of a number of free software projects, including gcc, gdb, and the GNU binutils. It sends out over 100,000 e-mail messages per day. The system has received exactly one mail message via QMTP (from me). It has sent maybe twenty mail messages via QMTP, mostly to me, but also a couple to one other person. Russ, thanks for writing the QMTP patches. Now, when are you going to start using QMTP to send out FSB? Ian
Re: QMTP running on sources.redhat.com
Ian Lance Taylor writes: Russ, thanks for writing the QMTP patches. Now, when are you going to start using QMTP to send out FSB? :) Good point. Okay, the [EMAIL PROTECTED] list, the [EMAIL PROTECTED] list, the [EMAIL PROTECTED] list, and the mgetty list are all being delivered via qmtpd. I've got a customer who's delivering ten million messages a day or so. Once we've got more confidence in the code I'll install it on his server. Or servers, rather. :) Now, who wants to work on cqmtp (compressed quick mail transport protocol)? :) No reason why you couldn't run gzip on the whole chunk before sending it off. -- -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: Suggestion regarding qmtp patch to qmail-remote.c
On Fri, Jan 05, 2001 at 07:05:02PM +, Mark Delany wrote: Russ offers: http://qmail.org/qmail-1.03-qmtpc.patch Feedback: Given a sample of one, this patch seems to work. Nice work. Suggestion: What about making the log file entries more consistent with the current format? Current smtp: success: 192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_22711/ Current qmtp: success: qmtp:_ok_978720977_qp_22786/All_received_okay_by_192.203.178.8/ Suggested qmtp: success: qmtp:192.203.178.8_accepted_message./Remote_host_said:_ok_978720977_qp_22786/ Then a triv change to the smtp output and we have parsing consistency. Do we want smtp to say: success: smtp:192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_22711/ and qmtp as suggested above? Thoughts, anyone? BTW: Done with mailroutes vs smtproutes. I just want to fix this too before I rerelease the patch again... -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
QMTP over SMTP connection
I started writing a qmail version who use a new SMTP syntax to start a QMTP conversation over a SMTP protocol: S 220 ready C HELO mail.test S 250 mail.test C PROTO QMTP After this command, a standard smtp server returns a 5xx reply: sendmail: 500 Command unrecognized: "PROTO QMTP" qmail: 502 Unimplemented My qmail-smtpd start a patched qmail-qmtpd (responding "421 failure" if exec fail); qmail-qmtpd then reply S 220 switching to QMTP and then start the new protocol. I identified the sources to patch: qmail-smtpd.c, qmail-qmtpd.c, and qmail-remote.c . The patch for qmail-smtpd.c is trivial: a new smtpcommands[] entry, a new procedure smtp_proto who check the argument and execute "bin/qmail-qmtpd" (and print 421 if exec fails). I then tried to patch qmail-qmtpd adding only an option to send the 220 reply, but qmail-qmtpd does not implement some useful features that must be present on a public mail exchanger (i.e. no relay control ...). May be it's a good idea, but the task is too big for me. Someone interested? -- Tullio Andreatta Logicom S.r.l. (Gruppo Finmatica) http://www.logicom.it/ Sede operativa: Via Vergnano, 2 - I-25100 Brescia ITALY
Re: Suggestion regarding qmtp patch to qmail-remote.c
Am Dienstag, 9. Januar 2001 11:36 schrieb Johan Almqvist: Do we want smtp to say: success: smtp:192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_ 22711/ I'd not change the this, it makes smtp log entries incompatible with stock qmail. Even if it's more logical. -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg www.bsws.de| Germany
Re: QMTP over SMTP connection
Am Donnerstag, 1. Januar 1970 00:59 schrieb Tullio Andreatta: I started writing a qmail version who use a new SMTP syntax to start a QMTP conversation over a SMTP protocol: May be it's a good idea, but the task is too big for me. Someone interested? It's no good idea to start a SMTP conversion and switch to QMTP later. MXPS (http://cr.yp.to/proto/mxps.txt) is the better solution. Russel Nelson has released a patch for qmail-remote to do that. -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg www.bsws.de| Germany
Re: Suggestion regarding qmtp patch to qmail-remote.c
On Tue, Jan 09, 2001 at 01:13:07PM +0100, Henning Brauer wrote: Am Dienstag, 9. Januar 2001 11:36 schrieb Johan Almqvist: Do we want smtp to say: success: smtp:192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_ 22711/ I'd not change the this, it makes smtp log entries incompatible with stock qmail. Even if it's more logical. I definitely see your point. However, I've included it in the latest patch... I'd really like too see some feedback... About the logging: There should be a way to see what proto was used for delivery... but smtp is 'the default' in other parts of the patch, so it could here too. However, the log will be incompatible anyhow, because right now, an eventual analysis tool will just not see the qmtp deliveries at all. To fix that, my patch minus the protocol information must be used, and maybe (depending on the log analysis tool ;-) I'd even have to fake an SMTP status code for the qmtp transfers. Yuck! How do you want it? -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
Re: Suggestion regarding qmtp patch to qmail-remote.c
Am Dienstag, 9. Januar 2001 13:13 schrieb Johan Almqvist: However, the log will be incompatible anyhow, because right now, an eventual analysis tool will just not see the qmtp deliveries at all. To fix that, my patch minus the protocol information must be used, and maybe (depending on the log analysis tool ;-) I'd even have to fake an SMTP status code for the qmtp transfers. Yuck! No, don't fake smtp status codes. If you wan't a new feature (qmtp deliveries) you'll have to upgrade, if you wan't to anylyse them. you'll have to upgrade too. How do you want it? -Johan Content-Type: application/pgp-signature; charset="us-ascii"; name="Anhang: 1" Content-Transfer-Encoding: 7bit Content-Description: -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg www.bsws.de| Germany
Getting this list via QMTP
Hi! I'm very keen on getting this list via qmtp, as to not abuse the SMTP gateway I'm currently using. Unless we can get DJB to replace his qmail-remote, I can see one solution: someone "close" to the cr.yp.to machines puts up a sublist and uses the patched qmail-remote. Any offers? -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/ PGP signature
RE: control/mailroutes (was: QMTP autoreply tester)
Greg Owen [EMAIL PROTECTED] wrote: It also seems to me that one of the design traits of qmail is simplicity of config files - I can't find the reference, but I thought somewhere DJB said that having to parse complex config files is a cause of problems. See: http://cr.yp.to/qmail/guarantee.html particularly, item #5. -Dave
Re: QMTP over SMTP connection
On Tue, Jan 09, 2001 at 12:15:16PM +0100, Tullio Andreatta wrote: [snip] May be it's a good idea, but the task is too big for me. It's not a good idea. - by the time your method has started QMTP, all or most of the latency that QMTP tries to avoid has been introduced by the negotiation. - your method adds another roundtrip to SMTP conversations with hosts that don't suport QMTP (this can be solved by only reacting if the initial SMTP greeting contains the QMTP word, just like ESMTP) Anyway, MXPS is the way to go until somebody comes up with something *better*. Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me 'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me
Re: Getting this list via QMTP
On Tue, Jan 09, 2001 at 08:11:30PM +0100, Johan Almqvist wrote: Hi! I'm very keen on getting this list via qmtp, as to not abuse the SMTP gateway I'm currently using. Unless we can get DJB to replace his qmail-remote, I can see one solution: someone "close" to the cr.yp.to machines puts up a sublist and uses the patched qmail-remote. Doesn't even need to be close, just well-connected. I'd be happy to do that on my server (to which I will move my qmail.org mirror soon, too). If you could provide me in private mail with concise instructions for setting up a sublist (I'm no ezmlm guru) I'll have a look. Could take a few days tho. Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me 'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me
Re: Getting this list via QMTP
On Wed, Jan 10, 2001 at 12:13:24AM +0100, Peter van Dijk wrote: [snip] Doesn't even need to be close, just well-connected. I'd be happy to do that on my server (to which I will move my qmail.org mirror soon, too). Everything seems to be up and running now, *but* list.cr.yp.to refuses to reply to any lists.dataloss.nl address. dataloss.nl works fine, lists.dataloss.nl works fine for anything but list.cr.yp.to. I'm confused. Blaming DNS TTLs and friends, I will try again tomorrow. Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me 'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me
Re: control/mailroutes (was: QMTP autoreply tester)
On Sat, Jan 06, 2001 at 10:28:26PM -0700, Andy Bradford wrote: Thus said Ricardo Cerqueira on Sun, 07 Jan 2001 01:50:16 GMT: Hmmm... OK, disregard my previous mail. Personally, I'd rather have one file for SMTP, and another for QMTP. Does anyone else here agree with me? I'd really like to discuss this further... Could you please elaborate on This seems more logical to me as it allows finer control over the entire system. Oh well, I suppose it isn't critical as qmail-remote will just have to determine which to use by probing I guess---unless of course it is accompanied by a port number on which QMTP runs. The format I propose for control/mailroutes is the following: --- snip --- Two example lines looks like this: almqvist.net:beta.lunds.lu.se:209:qmtp propellerheads.org:mail-relay.df.lth.se In the first case, QMTP will be used to transfer messages for the almqvist.net domain to beta.lunds.lu.se, port 209. In the second case, SMTP will be used to transfer messages for the propellerheads.org domain to mail-relay.df.lth.se, port 25. PLEASE NOTE that SMTP will be assumed as protocol even if you specify 209 as the port, but no protocol. In fact, SMTP will be used in all cases except if the last field is exactly 'qmtp'. PLEASE NOTE that you cannot specify only a protocol. If you wish to specify a protocol, you MUST specify a port. Bad things may happen. --- snap --- If there were two files, I'd basically have to "merge" them internally anyway... Or one file would have to have precedence over the other - but what happens if I specify a wildcard in one file but one of that domain's subdomains in the other? -Johan -- Johan Almqvist
RE: control/mailroutes (was: QMTP autoreply tester)
Andy Bradford said: Thus said Ricardo Cerqueira on Sun, 07 Jan 2001 01:50:16 GMT: Personally, I'd rather have one file for SMTP, and another for QMTP. Does anyone else here agree with me? This seems more logical to me as it allows finer control over the entire system. It also seems to me that one of the design traits of qmail is simplicity of config files - I can't find the reference, but I thought somewhere DJB said that having to parse complex config files is a cause of problems. Parseing two files, one for SMTP and one for QMTP, seems more in line with that philosophy than having one file that must be parsed for meaning rather than just correctness. Just my .02. -- gowen -- Greg Owen -- [EMAIL PROTECTED] SoftLock.com is now DigitalGoods!
Re: control/mailroutes (was: QMTP autoreply tester)
On Sat, 6 Jan 2001, Andy Bradford wrote: Thus said Ricardo Cerqueira on Sun, 07 Jan 2001 01:50:16 GMT: Hmmm... OK, disregard my previous mail. Personally, I'd rather have one file for SMTP, and another for QMTP. Does anyone else here agree with me? This seems more logical to me as it allows finer control over the entire system. Oh well, I suppose it isn't critical as qmail-remote will just have to determine which to use by probing I guess---unless of course it is accompanied by a port number on which QMTP runs. the difficulty with two files is precidence... if you have files like this: smtproutes: .com:mail-relay1.internal mail.example.com:mail-relay1.internal qmtproutes: :mail-relay2.internal example.com:mail-relay2.internal mail.example.com:mail-relay2.internal then you have to read the files at the same time to determine which route to use; what do you do if you have two entries for the same domain in both files - which one takes priority? would you notice mail.example.com appears in both files? Added complexity makes for more bugs. RjL
QMTP autoreply tester
Hi! Having caught the qmtp virus, I set up a service for qmtp testing - hey, it'd been a lot easier for me to set this up if there'd been such a service. If anyone dinks around with it too much, it will disappear without further notice. The following four addresses exist: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] has-mxps means that the MX records comply with MXPS, ie Russell's patch to qmail-remote will do the trick. no-mxps means no MXPS, ie my patch and an entry in the mailroutes file (replacement for smtproutes) are necessary. The -verbose variants will return the headers from the incoming message. The return message will only be sent by QMTP if you use MXPS. IMPORTANT: The return message will be sent to the ENVELOPE SENDER. Use qmail-inject [EMAIL PROTECTED] [EMAIL PROTECTED] to get it right if you're in doubt. -Johan -- Johan Almqvist
control/mailroutes (was: QMTP autoreply tester)
On Sat, Jan 06, 2001 at 01:59:18PM -0700, Andy Bradford wrote: Not to be picky, but why not call the file qmtproutes instead of mailroutes? :-) Because it contains both SMTP and QMTP routes. I figured that would be a better idea, and so did other people. Quoting Alex: I like the mailroutes idea. The relationship between nested wildcard entries may be more difficult to manage when such relationships span smtproutes and qmtproutes. ...and I can only agree. 'twas easier to implement, too :- -Johan -- Johan Almqvist
Re: QMTP autoreply tester
On Sat, Jan 06, 2001 at 04:12:11PM -0600, Timothy Legant wrote: The following four addresses exist: [EMAIL PROTECTED] [EMAIL PROTECTED] I couldn't get a correct response from the first one - just a bounce from MAILER-DAEMON with the qmail-send message "Sorry, no mailbox here by that name." Oops, I had a faulty conception of how .qmail-foo-default works. Fixed. -Johan -- Johan Almqvist
Re: control/mailroutes (was: QMTP autoreply tester)
On Sun, Jan 07, 2001 at 01:56:47AM +0100, Johan Almqvist wrote: On Sat, Jan 06, 2001 at 01:59:18PM -0700, Andy Bradford wrote: Not to be picky, but why not call the file qmtproutes instead of mailroutes? :-) Because it contains both SMTP and QMTP routes. I figured that would be a better idea, and so did other people. Hmmm... OK, disregard my previous mail. Personally, I'd rather have one file for SMTP, and another for QMTP. Does anyone else here agree with me? RC -- +--- | Ricardo Cerqueira | PGP Key fingerprint - B7 05 13 CE 48 0A BF 1E 87 21 83 DB 28 DE 03 42 | Novis Telecom - Engenharia ISP / Rede Tcnica | P. Duque Saldanha, 1, 7 E / 1050-094 Lisboa / Portugal | Tel: +351 2 1010 - Fax: +351 2 1010 4459 PGP signature
Re: control/mailroutes (was: QMTP autoreply tester)
Thus said Ricardo Cerqueira on Sun, 07 Jan 2001 01:50:16 GMT: Hmmm... OK, disregard my previous mail. Personally, I'd rather have one file for SMTP, and another for QMTP. Does anyone else here agree with me? This seems more logical to me as it allows finer control over the entire system. Oh well, I suppose it isn't critical as qmail-remote will just have to determine which to use by probing I guess---unless of course it is accompanied by a port number on which QMTP runs. Andy -- [---[system uptime]] 10:28pm up 66 days, 48 min, 4 users, load average: 1.25, 1.15, 1.10
Suggestion regarding qmtp patch to qmail-remote.c
Russ offers: http://qmail.org/qmail-1.03-qmtpc.patch Feedback: Given a sample of one, this patch seems to work. Nice work. Suggestion: What about making the log file entries more consistent with the current format? Current smtp: success: 192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_22711/ Current qmtp: success: qmtp:_ok_978720977_qp_22786/All_received_okay_by_192.203.178.8/ Suggested qmtp: success: qmtp:192.203.178.8_accepted_message./Remote_host_said:_ok_978720977_qp_22786/ Then a triv change to the smtp output and we have parsing consistency. Regards.
Re: QMTP
On Wed, Sep 06, 2000 at 01:02:39PM +0200, Peter van Dijk wrote: [snip] It's clear that djb's talking about 0a/LF EXCEPT in line end designators (which can either be CRLF or LF). So basically every message that does not contain LFs that are not line feeds is "safe". I couldn't gather the "that are not line feeds" part from the docs. I like that explanation but I still can't make it out of qmtp.txt. qmtp.txt states 'a message is a sequence of lines' and 'a *message* is called safe if none of its bytes are 0a.' Greetz, Peter -- dataloss networks
Re: QMTP
Peter van Dijk [EMAIL PROTECTED] writes on 7 September 2000 at 14:27:21 +0200 On Wed, Sep 06, 2000 at 01:02:39PM +0200, Peter van Dijk wrote: [snip] It's clear that djb's talking about 0a/LF EXCEPT in line end designators (which can either be CRLF or LF). So basically every message that does not contain LFs that are not line feeds is "safe". I couldn't gather the "that are not line feeds" part from the docs. I like that explanation but I still can't make it out of qmtp.txt. qmtp.txt states 'a message is a sequence of lines' and 'a *message* is called safe if none of its bytes are 0a.' The line terminator (conventionally a linefeed on Unix) isn't a part of the line in this definition, I think. At least, taking it that way makes it all come together. Then it ends up saying that the message is safe so long as no line contains an embedded linefeed. -- Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
Re: QMTP
On Thu, Sep 07, 2000 at 11:58:04AM -0500, David Dyer-Bennet wrote: [snip] The line terminator (conventionally a linefeed on Unix) isn't a part of the line in this definition, I think. At least, taking it that way makes it all come together. Then it ends up saying that the message is safe so long as no line contains an embedded linefeed. Hmm. Terminator not part of line. Good point there. But I think you do agree the text could use some more clarity :) Greetz, Peter -- dataloss networks
Re: QMTP
On Wed, Sep 06, 2000 at 02:06:00AM +0200, Claus Färber wrote: Austad, Jay [EMAIL PROTECTED] schrieb/wrote: I am glancing over qmtp.txt and it's mostly quite clear to me, except the stuff about 'safe messages'. If none of the bytes in a safe message can be 0a, when the hell *do* we see a safe message? It's clear that djb's talking about 0a/LF EXCEPT in line end designators (which can either be CRLF or LF). So basically every message that does not contain LFs that are not line feeds is "safe". I couldn't gather the "that are not line feeds" part from the docs. If a message is not safe, the worst that can happen is that bare LFs are converted to CRLF. This is also true for most SMTP MTAs. Correct. Greetz, Peter. -- [ircoper][EMAIL PROTECTED] - Peter van Dijk / Hardbeat [student]Undernet:#groningen/wallops | IRCnet:/#alliance [developer]_ [disbeliever - the world is backwards](__VuurWerk__(--*-
QMTP
Where would I find detailed specs on the QMTP protocol? I've found some stuff at http://cr.yp.to/proto/qmtp.txt, but I need more. We're writing a little piece of code that's going to sit on a couple of hundred Win2000 webservers that can talk QMTP to our qmail box for faster delivery. Users come to our site and sign up for automatically generated charts and other such things and the webservers generate the content for the email and send it off using SMTP right now. We need to speed this up as much as possible, and QMTP looks like the best way to do it since we already have a qmail box sending most of our other subscriber mail. We also have several QMQP servers. Would it maybe be better to make it talk QMQP to the boxes running qmail-qmqpd? = Here's my setup below in case anyone is wondering (warning: may be confusing without a picture): I have one main machine that runs ezmlm and a full version of qmail, it also runs a second copy of qmail (actually mini-qmail, we'll get to that in a minute). qmail-qmqpc is modified on the machine to load balance between all of my QMQP servers. I can add QMQP servers as necessary if the load gets to high on the rest of them. The full version of qmail is running to handle bounces, and to accept mail from webservers. Ezmlm-idx is set up to use QMQP for delivery, so messages being sent out get distributed to multiple QMQP servers. If the email comes in from a webserver, box running ezmlm would try to send it off itself... I didn't want that to happen because I want to keep the disk activity and other resources down as much as possible, so the logical choice would be to offload all mail not destined for the local box to the QMQP servers. Since I couldn't figure out a better way to do it, I installed a copy of mini-qmail with qmail-smtpd listening on port 26, and my modified qmail-qmqpc. smtproutes is set up so all outgoing mail goes to mini-qmail (on port 26) which distributes it to the QMQP servers. I wish smtproutes would let you specify a protocol to use... :) So the way this is set up, all outgoing mail gets sent to QMQP servers to let them handle the queueing and sending. Main destined for the local machine is still accepted and processed normally. Right now, I have 2 bottlenecks... The SMTP connection that the webservers use to send mail through it, and the SMTP connection to port 26 that the main copy of qmail redirects outgoing mail to. -- Jay Austad Network Administrator CBS Marketwatch 612.817.1271 [EMAIL PROTECTED] http://cbs.marketwatch.com http://www.bigcharts.com
Re: QMTP
The code for serialmail comes with code to send via qmtp. - Original Message - From: "Austad, Jay" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 11:35 AM Subject: QMTP Where would I find detailed specs on the QMTP protocol? I've found some stuff at http://cr.yp.to/proto/qmtp.txt, but I need more. We're writing a little piece of code that's going to sit on a couple of hundred Win2000 webservers that can talk QMTP to our qmail box for faster delivery. Users come to our site and sign up for automatically generated charts and other such things and the webservers generate the content for the email and send it off using SMTP right now. We need to speed this up as much as possible, and QMTP looks like the best way to do it since we already have a qmail box sending most of our other subscriber mail.
RE: QMTP
I understand it fine. I just have to get as much info as possible for our developers so they can code it up. Just want to make sure they don't have to do a ton of debugging due some subtle mistake somewhere. Jay -Original Message- From: Peter van Dijk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 05, 2000 12:51 PM To: '[EMAIL PROTECTED]' Subject: Re: QMTP On Tue, Sep 05, 2000 at 10:35:08AM -0500, Austad, Jay wrote: Where would I find detailed specs on the QMTP protocol? I've found some stuff at http://cr.yp.to/proto/qmtp.txt, but I need more. What part of that document is unclear to you, or what don't you understand? You might want to read serialqmtp.c (in serialmail) and qmail-qmtpd.c (in qmail) I am glancing over qmtp.txt and it's mostly quite clear to me, except the stuff about 'safe messages'. If none of the bytes in a safe message can be 0a, when the hell *do* we see a safe message? Looking at serialqmtp, it seems to just *disregard* this problem and pump the message into the packet. Cool, no more CRLF/LF conversions :) If it's netstrings that confuse you, read http://cr.yp.to/proto/netstrings.txt Greetz, Peter -- dataloss networks
Re: QMTP
On Tue, Sep 05, 2000 at 01:47:38PM -0500, Austad, Jay wrote: I understand it fine. I just have to get as much info as possible for our developers so they can code it up. Just want to make sure they don't have to do a ton of debugging due some subtle mistake somewhere. QMTP is too simple to make subtle mistakes :) Greetz, Peter -- dataloss networks
Re: QMTP
On Tue, Sep 05, 2000 at 10:35:08AM -0500, Austad, Jay wrote: Where would I find detailed specs on the QMTP protocol? I've found some stuff at http://cr.yp.to/proto/qmtp.txt, but I need more. What part of that document is unclear to you, or what don't you understand? You might want to read serialqmtp.c (in serialmail) and qmail-qmtpd.c (in qmail) I am glancing over qmtp.txt and it's mostly quite clear to me, except the stuff about 'safe messages'. If none of the bytes in a safe message can be 0a, when the hell *do* we see a safe message? Looking at serialqmtp, it seems to just *disregard* this problem and pump the message into the packet. Cool, no more CRLF/LF conversions :) If it's netstrings that confuse you, read http://cr.yp.to/proto/netstrings.txt Greetz, Peter -- dataloss networks
Re: QMTP MX encoding
Your arguments are interesting in so far as they pertain to the use of QMTP, but my concern is more that at some point the Qmail community may want to have QMTP as RFCxyz and used as a standard feature of mail exchange. With that goal (in my mind, maybe not yours), my proposal seemed to have more comatibility and standards potential than the MX magic, especially when DJB mentionned not using the MX magic preference values. Russell Nelson wrote: Michael T. Babcock writes: (stuff) I think that's a silly idea. Better to pick a "magic" MX preference,
Re: QMTP via EHLO type command
To make this a little more QMTP compatible, and to agree with some of Peter
Norton's comments from late 1998, the sending MTA could also immediately
'transfer' the request to the QMTP by opening a new connection on the QMTP
port when it 'saw' the QMTP response from the foreign SMTP MTA. It would
not have to wait for the TCP session to close, etc. (this could be done in a
non-blocking manner) and the QMTP session could begin almost as quickly as
it would if it knew the foreign server supported QMTP to start with.
As someone else said over a year ago (and I'm sure its been repeated since),
the knowledge that a foreign MTA supports QMTP could be temporarily cached,
if it were desired (and proved faster than not) and reused instead of
opening new SMTP requests to those servers.
This would have the added benefit of using QMTP more often when
communicating with servers that receive a lot of repeated traffic.
I wrote:
{ Syntax: "" from server ... "" to server }
220 IP ESMTP QMTP
QHLO
(data stream)
(response)
I see this last one as being best, since the opening message can be
customised to mention QMTP in it easily, and once that is parsed by the
sending MTA, no further foreign responses are required until the QMTP
dialog is finished. The initial "QHLO" would be added to inform the
foreign MTA of our intentions.
QMTP MX encoding
DJB mentions on his 'future of qmail' page that a way to encode that a host supports QMTP into its MX data is in the works. What method for doing so is proposed?
Re: QMTP MX encoding
On Mon, Jul 24, 2000 at 05:32:17PM -0400, Michael T. Babcock wrote: DJB mentions on his 'future of qmail' page that a way to encode that a host supports QMTP into its MX data is in the works. What method for doing so is proposed? http://cr.yp.to/proto/mxps.txt, I imagine. Regards, james -- James Raftery (JBR54) - Programmer Hostmaster - IE TLD Hostmaster IE Domain Registry - www.domainregistry.ie - (+353 1) 706 2375 "Managing 4000 customer domains with BIND has been a lot like herding cats." - Mike Batchelor, on [EMAIL PROTECTED]
Re: QMTP MX encoding
Actually, searching for MXPS (thank-you) in the archives, I found: http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/01/msg00791.html ... by DJB (in January, 1999): -X- I'm going to use a special MX host name format instead of special MX preferences. The basic options will be _magic.s.* I can receive mail by SMTP _magic.q.* I can receive mail by QMTP _magic.qs.* I can receive mail by QMTP or SMTP with the possibility of future extensions such as _magic.abcdqrsz.* -X- James Raftery wrote: On Mon, Jul 24, 2000 at 05:32:17PM -0400, Michael T. Babcock wrote: DJB mentions on his 'future of qmail' page that a way to encode that a host supports QMTP into its MX data is in the works. What method for doing so is proposed? http://cr.yp.to/proto/mxps.txt, I imagine.
QMTP via EHLO type command
I was wondering if it wouldn't be smart to use an extension to EHLO as a
way to detect QMTP availability on an MX. I decided to check and 'QMTP'
'EHLO' only appear together 4 times. Chuck Foster seems to be the
first to have asked whether it wouldn't be smart to add a "250 QMTP"
(later corrected to "250 XQMTP" by L. Widdifield) to the EHLO response.
Janos Farkas felt that this (rightfully) adds a couple round-trips at
least to the communication, instead of reducing it as much as QMTP does
by definition. At this point the discussion died.
However, isn't it worth having some method in place for actually using
this more efficient protocol? The round-trips required by "Mail from:"
and "Rcpt To:" and "Data" are all eliminated, and the "250 XQMTP" could
be given as the first 250 response, allowing the QMTP compatible MTA to
immediately send a confirmation, not reading / parsing the remainder of
the TCP stream (which may be a slight improvement).
{ Syntax: "" from server ... "" to server }
220 IP ESMTP
EHLO
250 IP
250 XQMTP
QMTP
(data stream)
(response)
I see this as adding two potential delays (over straight QMTP); the
initial connection response by the foreign MTA, and the delay of waiting
for the EHLO round-trip.
As with RFC 1869 (introducing ESMTP) though, one of these could be
eliminated by simply changing "EHLO" to "QHLO" leaving us with a 500
response if the remote MTA does not understand QMTP. This adds a
round-trip every time we communicate with a non-QMTP MX, but that might
not concern many people. 'QMTP' could of course also be added to the
initial connection string to reduce things further.
Option #2:
220 IP ESMTP
QHLO
2000 QMTP ready
(data stream)
(response)
Option #3:
220 IP ESMTP QMTP
QHLO
(data stream)
(response)
I see this last one as being best, since the opening message can be
customised to mention QMTP in it easily, and once that is parsed by the
sending MTA, no further foreign responses are required until the QMTP
dialog is finished. The initial "QHLO" would be added to inform the
foreign MTA of our intentions.
Comments?
Re: QMTP MX encoding
Michael T. Babcock writes: Actually, searching for MXPS (thank-you) in the archives, I found: http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/01/msg00791.html ... by DJB (in January, 1999): -X- I'm going to use a special MX host name format instead of special MX preferences. The basic options will be I think that's a silly idea. Better to pick a "magic" MX preference, and try qmtp. If it fails, then fall back to smtp. The number of people who happen to use that preference AND who have something listening on the qmtp port is either zero now, or will become zero once all hosts running qmail attempt to talk to all other qmail hosts using qmtp. I'd really like to see a qmail 1.04 which uses qmtp. It would let qmail hosts talk *much* faster to each other. The other thing I'd like to see is for qmtp to implement VERP. So that instead of expanding list-@host-@[], qmtp would *transmit* list-@host-@[] and the receiving host would expand the verp. That also means that the qmail qmtpd would transmit all the recipients of a piece of email whose hostname was textually equal, ignoring case differences. This would allow people concerned about qmail's single-RCPT feature to implement a qmtpd, and set their MX priority to the magic value. There's no reason why you couldn't implement a qmtpd for sendmail. And it would save sites like aol or hotmail MANY SMTP connections. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Tornadoes, earthquakes, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | hurricanes and government: Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | uncontrollable forces
Trying to get QMTP protocol to work....
I've read the information in the four page printout that covers Quick Mail Transfer Protocol (QMTP-19970201). Qmail and Qmtp has been set up on a linux machine. I can telnet into port 209 (no problems). The problem is, while writing a piece of software, I cannot "QMTP" e- mail to the linux box. I have and can very easily SMTP'd e-mail. Does QMTP have a "verbose" setting for troubleshooting? When I send off the requested 8 bit transmission, I do not receive any response back. Obviously this is great for security reasons, but when developing it has become a problem. "Why use QMTP?" I've read how much faster it is (and agree with the concept), and we are migrating our mail servers from an NT environment to Linux to utilize Linux's power! ;) The back-end program will be a windows app, and obviously the QMTP port accessible only from our network. I have begun to look that the qmtpd.c (source code), and find out why it is not working. Thank you for any help (updated documents and/or code samples).
QMQP and QMTP: differences ?
Hi, I'd like to know whether there are significant differences between QMQP and QMTP. I know that qmail-qmqpc is used in place of qmail-queue so mail isn't safely stored on the QMQP client, whereas a QMTP client could be used in place of qmail-remote ( I'm thinking about writing a patch to qmail-rspawn to allow that ) and mail is securely stored on the client before the QMTP session. My question is : from a network point of view, why are there 2 protocols ? As far as I can see, qmail-qmqpc could speak QMTP to the remote server instead of QMQP, and that would make no difference at all. So why don't null clients / mini-qmail setups just speak QMTP ? Thanks in advance, -- Ska
Re: QMQP and QMTP
Brian Baquiran [EMAIL PROTECTED] wrote: What's the difference between QMTP and QMQP? When and where should I use them? QMTP (Quick Mail Transfer Protocol) is a modified, high-performance SMTP replacement. See http://cr.yp.to/proto/qmtp.txt. QMQP (Quick Mail Queueing Protocol) is a mail queuing protocol. See http://cr.yp.to/proto/qmqp.html. QMQP is much simpler, and is intended only for private service. -Dave
QMQP and QMTP
What's the difference between QMTP and QMQP? When and where should I use them? Brian -- [EMAIL PROTECTED] http://www.baquiran.com US Fax: (603) 908-0727 AIM: bbaquiran
QMTP forward program and maildir IMAP
The Problem: I recently subscribed to a cable modem service. My home machine is now online almost 100% of the time. I also got a free domain name. I wanted by email to be forwarded to my home machine if possible otherwise spooled normally. My university department recently upgraded to qmail (from sendmail). The Solution: Write a small QMTP fowarding program (serialmail wasn't really what I wanted). Add the following two lines to my .qmail file: |if $HOME/bin/tcpclient my.domain 209 $HOME/bin/qmtp $SENDER neil; then exit 99; else exit 0; fi $HOME/qmtp.log 21 ./Maildir/ The source for qmtp is here: http://www.ucalgary.ca/~nascheme/qmtp.c Please let me know if you find any security holes. So far things are working great. I also have a patch to add maildir support to the pine imap server. I based it on Mattias Larsson's patch but fixed some problems with multiple folders on the server. http://www.ucalgary.ca/~nascheme/maildir-nas.diff Perhaps someone will find this information useful. Thanks for qmail, tcpclient, and QMTP Dan. Neil -- "The percentage of users running Windows NT Workstation 4.0 whose PCs stopped working more than once a month was less than half that of Windows 95 users." -- microsoft.com/ntworkstation/overview/Reliability/Highest.asp
QMTP
Title: QMTP Are there any NT implementations of QMTP available? I'd like to drastically speed the time that it takes our MS SMTP Server to populate the qmail queue and this is one logical and probably most efficient way to do it. If there's no such thing available, are there any open source SMTP servers available for NT? I'd like to take it and mutilate it into a QMTP server. It's not very practical for us to develop all the failsafe mechanisms of a good mail server and SMTP should only require modifications in the transmission of the message itself to turn it into a QMTP server. Cris Daniluk MicroStrategy
Re: qmtp and smtp coexisting
On Wed, 18 Aug 1999 13:21:52 -0400, Daniluk, Cris wrote: We want to speed the time it takes to inject mail into the qmail queue. Currently with smtp we can only inject ~500 messages per second. To speed this up, based on the recommendation of many on the list, I want to implement QMTP. Will the messages queued via QMTP be stored identically to those queued via SMTP? The messages will be received from the machine that generates the mails via QMTP, but it will still need to send via SMTP. Yes, stored identically. Look at qmail-qmqpc/qmqpd instead. If you have a good network (local hosts, on phone lines, no sporadic interruptions between the hosts) QMQP is excellent and all the programming has already been done for you. Also, I know this thread has come up before, but what are the ramifications of bypassing the concurrencyremote limit of 255? This concurrency limit prevents us from being able to fully utilize 100mbit per network card in the machines. Running more qmails doesn't seem to be the most logical decision because we're already running 4 on the machine as it is (1 per nic). What would the damages by of doubling this hard limit? We use P133/64MB/SCSI machines. Increasing concurrency from 255 to 500 gets a 60% increase in performance for lists with 15000 or so recipients. It's not better since the box becomes processor/disk limited. There is no difference in performance when concurrency is 255, i.e. no penalty. For your hardware, I'd expect a larger increase in performance up to considerably higher performances (note that kernel 2.2.5 doesn't do it, unless you have the ac=3 patches. Don't know if later kernels support this (earlier ones have a 1024 limit per process). What would be interesting to know is the difference (assuming queues are on the same drive) or 4 qmail installations of 250 each vs one with a concurrecy of 1000. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: QMTP suggestion
On Tue, Apr 06, 1999 at 07:40:59PM -0400, Peter C. Norton wrote: On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote: netstat -a |fgrep '*:qmtp' or the low-level C equivalent. I'm not concerned with this. I'm concerned with Fred's proposal relying on the status of the remote smtp and qmtp server. If I'm "local" and someone else is "remote" and remote's qmtp service is down, but remote's smtp server is still advertising qmtp then I shouldn't have my queue grow because of it. There should be some local communication about bum servers if this database is used, to prevent it from severely slowing down email. Well extend it a bit to ignore qmtp in smtp banners for like one hour if qmtp turns out to be _not_ available. No big deal. Greetz, Peter -- | 'He broke my heart,| Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognixz - As the sun |Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
Re: QMTP suggestion
On Wed, Apr 07, 1999 at 08:53:29AM -0500, Fred Lindberg wrote: Since SMTP and QMTP are linked anyway, the advertizing of QMTP by the SMTP server could easily be linked to QMTP being up. Thus, a working smtpd with a failed qmtpd (admin forgot to start?) would not advertize QMTP. This would also make this part of config automatic, i.e. if you choose not to use qmail-qmtpd, you won't advertize it. Why not just implement QMTP in qmail-smtpd? qmail-smtpd would advertise QMTP in its banner, and then the host connecting would be free to start firing away in QMTP lingo. There would never be any question of QMTP being up, since qmail-smtpd would know how to talk QMTP itself. The fact that a particular host talked QMTP on its SMTP port could be cached so that one wouldn't even have to wait for the banner next time. If the remote host sent some kind of magic string to indicate that it was about to start QMTPing, the above could be implemented with a simple patch to qmail-smtpd that exec'ed qmail-qmtpd upon reception of the magic string. Or it could be done in the qmail-popup fashion--a program could answer the connection, advertising QMTP, and exec qmail-smtpd or qmail-qmtpd depending on whether it received a HELO command or a QMTP command. Chris
Re: QMTP suggestion
On Tue, 6 Apr 1999, Peter C. Norton wrote: On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote: netstat -a |fgrep '*:qmtp' or the low-level C equivalent. I'm not concerned with this. I'm concerned with Fred's proposal relying on the status of the remote smtp and qmtp server. If I'm "local" and someone else is "remote" and remote's qmtp service is down, but remote's smtp server is still advertising qmtp then I shouldn't have my queue grow because of it. There should be some I think Chris' point was the remote SMTP server monitors the state of the remote qmtp socket/listener on itself. if there is something listening on the QMTP port isn't it fairly reasonable for qmail-smtpd to [configureabley] assume it's qmail-qmtpd ? Richard
Re: QMTP suggestion
From: Richard Letts [EMAIL PROTECTED] Date: Wed, 7 Apr 1999 19:06:04 +0100 (BST) On Tue, 6 Apr 1999, Peter C. Norton wrote: On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote: netstat -a |fgrep '*:qmtp' or the low-level C equivalent. I'm not concerned with this. I'm concerned with Fred's proposal relying on the status of the remote smtp and qmtp server. If I'm "local" and someone else is "remote" and remote's qmtp service is down, but remote's smtp server is still advertising qmtp then I shouldn't have my queue grow because of it. There should be some I think Chris' point was the remote SMTP server monitors the state of the remote qmtp socket/listener on itself. if there is something listening on the QMTP port isn't it fairly reasonable for qmail-smtpd to [configureabley] assume it's qmail-qmtpd ? Bingo. Certainly Peter's concern is legitimate to a point: as the sender, if the remote claims qmtp is there and it isn't, I have a problem. But as someone else pointed out, right now any remote end that supports qmtp will be qmail, so if we can make sure qmail only claims to have qmtp available if it really is, his concern shouldn't arise. Also, didn't the original proposal include the idea that if a host that we thought had qmtp on it doesn't respond to the qmtp port, we fall back to smtp? In the worst case of a system that claims to have qmtp but doesn't, we contact them via smtp; they say they support qmtp; we cache this information and send the one message via smtp; on the next message we contact them via qmtp; they timeout; we fall back to smtp and remove them from the qmtp cache (not putting them back in the cache). We repeat the cycle. Half their mail goes directly via SMTP, the other half attempts QMTP and then falls back to SMTP. Of course, this is pathological, and mail to most hosts will either always go SMTP or the first message will go SMTP and the rest will go QMTP. Chris -- Chris Garrigues virCIO +1 512 432 4046 4314 Avenue CO- http://www.DeepEddy.Com/~cwg/ Austin, TX 78751-3709 +1 512 374 0500 My email address is an experiment in SPAM elimination. For an explanation of what we're doing, see http://www.DeepEddy.Com/tms.html Nobody ever got fired for buying Microsoft, but they could get fired for relying on Microsoft. PGP signature
Re: QMTP suggestion
On Wed, 7 Apr 1999 10:37:48 -0400, Chris Johnson wrote: Why not just implement QMTP in qmail-smtpd? qmail-smtpd would advertise QMTP in its banner, and then the host connecting would be free to start firing away in QMTP lingo. There would never be any question of QMTP being up, since qmail-smtpd would know how to talk QMTP itself. The fact that a particular host talked QMTP on its SMTP port could be cached so that one wouldn't even have to wait for the banner next time. QMTP doesn't BS: Connect, (send package, wait for reply)*, disconnect. Package=message,from,to*. Starting with a SMTP handshake would be a lot of overhead. To be efficient, the sender must (for a session) know that the recipient does QMTP without connecting via SMTP first. I as just suggesting that that knowledge come from a previous SMTP session (only one needed per host) rather than a special MX record. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: QMTP suggestion
On Wed, Apr 07, 1999 at 10:37:48AM -0400, Chris Johnson wrote: On Wed, Apr 07, 1999 at 08:53:29AM -0500, Fred Lindberg wrote: Since SMTP and QMTP are linked anyway, the advertizing of QMTP by the SMTP server could easily be linked to QMTP being up. Thus, a working smtpd with a failed qmtpd (admin forgot to start?) would not advertize QMTP. This would also make this part of config automatic, i.e. if you choose not to use qmail-qmtpd, you won't advertize it. Why not just implement QMTP in qmail-smtpd? qmail-smtpd would advertise QMTP in its banner, and then the host connecting would be free to start firing away in QMTP lingo. There would never be any question of QMTP being up, since qmail-smtpd would know how to talk QMTP itself. The fact that a particular host talked QMTP on its SMTP port could be cached so that one wouldn't even have to wait for the banner next time. Just one point.. the qmtp protocol would then need to be adapted so that it would ignore this banner. If the remote host sent some kind of magic string to indicate that it was about to start QMTPing, the above could be implemented with a simple patch to qmail-smtpd that exec'ed qmail-qmtpd upon reception of the magic string. Or it could be done in the qmail-popup fashion--a program could answer the connection, advertising QMTP, and exec qmail-smtpd or qmail-qmtpd depending on whether it received a HELO command or a QMTP command. Also very feasible, but this too would require a change to the QMTP standard. I think if we want this, we should do it right now, while qmail is still the only qmtp-supporting mta. Your point with the caching is very good. I don't know which of the mentioned approaches would be the best, but this is one good possibility. Greetz, Peter -- | 'He broke my heart,| Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognixz - As the sun |Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
Re: QMTP suggestion
On Wed, Apr 07, 1999 at 09:42:18AM +0200, Peter van Dijk wrote: Well extend it a bit to ignore qmtp in smtp banners for like one hour if qmtp turns out to be _not_ available. No big deal. Right. I just wanted to throw that into the proposal. An hour is probably a good long time. -Peter
QMTP suggestion
Instead of MX magic, would it be possible to use a local cache to keep track of QMTP-capable hosts? QMTP is most useful for hosts that we talk to often and [with multi-recipient protocols] with smarthosts, etc. Thus, it should be possible to use SMTP by default, recognize from the banner that the recipient talks QMTP, and commit that info to a cache (e.g. a non-synced file which could asynchronously be compiled into a cdb once in a while). When sending, one would look up host names in the cdb, and if QMTP-capable start a QMTP dialog. If it fails, the db can be updated with that info (it doesn't matter if it takes a while to make it to the cdb since this should be rare). When the db is updated a subsequent redelivery will use SMTP. When building up multi-recipient QMTP blocks, one could parse the recipients of the message first and look up the hosts (useful only for messages with many recipients, say 50). Alternatively, one could do this only for "smtproutes" entries or even have "qmtproutes" since the gain is for smart hosts or MLM hosts that use exploders via QMTP (the exploder does VERP). The advantage would be that QMTP could be automatically implemented by a qmail host and would soon be employed between qmail hosts without the need for any special setup. The disadvantage is the need to maintain another lookup db, but it would be relatively static and fast as it is local. If the db is lost, it would cause a slowdown, but it wouldn't be fatal. If the updates from the last few hours are lost, it is quite insignificant, so there is no need for frequent sync()/rebuilds. If the info is incorrect, SMTP will be used and the error noted and corrected, or QMTP will be attempted, fail, and the info corrected. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: QMTP suggestion
On Tue, Apr 06, 1999 at 05:57:37PM -0500, Fred Lindberg wrote: When sending, one would look up host names in the cdb, and if QMTP-capable start a QMTP dialog. If it fails, the db can be updated with that info (it doesn't matter if it takes a while to make it to the cdb since this should be rare). When the db is updated a subsequent redelivery will use SMTP. The outbound smtp agent would have to be aware somehow of the activities of its fellow outbound qmtp server. If the smtp listener on a remote site is advertising qmtp, and its qmtp server is not responding then this could cause a severe delay in mail going via smtp. -Peter
