Re: QMTP + VERP
On 4 Feb 1999 15:30:24 -, Russell Nelson wrote: >If qmail's QMTP client coagulated recipients addressed to the same >hostname (chasing down MXes take more bandwidth, as Dan has proven), >then we could tell the Mark Crispins of the world, "So implement QMTP >if you're that concerned about resources. QMTP takes less bandwidth, >and can receive any number of recipients in a single message." The problem is concurrency, i.e. qmail needs to know that a host does QMTP before spawning qmail-remote:s for the other addresses to this host. This might be done by sorting by host [and by doing smtproutes before qmail-remote it could be batched even more]. For SMTP one would _choose_ to send one message per recipient (to get VERP and avoid the overhead of dealing with rejections from the remote MTA at the SMTP dialog level), but for QMTP the polite recipient shuts up and takes it. This could also save DNS lookups, since the lookup would be done only once per message per host (not usually a big savings, but may be for a MLM host). That and a few smtproutes to QMTP smarthosts + ezmlm would make an awesome "message distributer". >I'd really like to see this in qmail 2.0. Anything I can do to help, Dan? -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: QMTP + VERP
Fred Lindberg writes: > On Wed, 03 Feb 1999 23:09:52 +0100 (MET), Stefan Paletta wrote: > > >Any takers for an ESMTP server-sided VERP expansion extension draft? ;-) > > Any takes for a QMTP _recipient_ side VERP expansion draft? > > When you talk about several recipients in a QMTP message where the QMTP > recipient does VERP expansion there are no valid arguments whatsoever > against having multiple recipients. > > In essence, you get raw qmail queue communication. Fast, efficient, and > usable both as normal hosts and especially as smarthosts. You can run > mailing lists on a host with a not-so-good connection, QMTP them to a > well-connected smarthost and explode then there. To other QMTP hosts > they go on as multi-recipient messages, to SMTP hosts they go > one-by-one after VERP expansion. THAT would be really really cool. There are some people (such as Mark Crispin) who object to VERP in such strong terms as to call it a denial of service attack. By way of explanation, his MTA retains multi-RCPT message in a single file. When a VERP'ed message comes in, each has to be stored in its own file. If qmail's QMTP client coagulated recipients addressed to the same hostname (chasing down MXes take more bandwidth, as Dan has proven), then we could tell the Mark Crispins of the world, "So implement QMTP if you're that concerned about resources. QMTP takes less bandwidth, and can receive any number of recipients in a single message." I'd really like to see this in qmail 2.0. Anything I can do to help, Dan? -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: QMTP + VERP
On Wed, 03 Feb 1999 23:09:52 +0100 (MET), Stefan Paletta wrote: >Any takers for an ESMTP server-sided VERP expansion extension draft? ;-) Any takes for a QMTP _recipient_ side VERP expansion draft? When you talk about several recipients in a QMTP message where the QMTP recipient does VERP expansion there are no valid arguments whatsoever against having multiple recipients. In essence, you get raw qmail queue communication. Fast, efficient, and usable both as normal hosts and especially as smarthosts. You can run mailing lists on a host with a not-so-good connection, QMTP them to a well-connected smarthost and explode then there. To other QMTP hosts they go on as multi-recipient messages, to SMTP hosts they go one-by-one after VERP expansion. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: QMTP + VERP
Bruno Wolff III wrote/schrieb/scribsit: > Stefan Paletta <[EMAIL PROTECTED]> wrote: >> See QMAIL EXTENSIONS in addresses.5. > The stuff there doesn't seem to apply at the point the qmtp connection > is being processed. This problem is on the sending end, since qmail itself cannot do multiple rcpt deliveries; anyone is free to write a QMTP client that leaves VERP expansion to the server. > Another way to extend QMTP would be to have sender > addresses that end with -@[] expanded with VERP information. True - this would be useful if qmail at one point did multiple rcpt deliveries and it would be necessary if other MTAs supported QMTP then. > It looks like qmail would have to be changed to delay the expansion of > VERPs from qmail-send until qmail-remote, since the protocol by which > the message will be transmitted won't be known until then. Again, this has been beaten to death in the multiple rcpt discussions^Wflame-wars. Any takers for an ESMTP server-sided VERP expansion extension draft? ;-) Stefan
Re: QMTP + VERP
On Wed, Feb 03, 1999 at 10:25:37PM +0100, Stefan Paletta <[EMAIL PROTECTED]> wrote: > > Bruno Wolff III wrote/schrieb/scribsit: > > Maybe QMTP should be extended in a way that allows for VERP without > > having to restransmit the message body more than once. Perhaps more than > > one sender address could be sent. > > See QMAIL EXTENSIONS in addresses.5. > > Stefan The stuff there doesn't seem to apply at the point the qmtp connection is being processed. Another way to extend QMTP would be to have sender addresses that end with -@[] expanded with VERP information. It looks like qmail would have to be changed to delay the expansion of VERPs from qmail-send until qmail-remote, since the protocol by which the message will be transmitted won't be known until then.
RE: QMTP + VERP
Bruno Wolff III wrote/schrieb/scribsit: > Maybe QMTP should be extended in a way that allows for VERP without > having to restransmit the message body more than once. Perhaps more than > one sender address could be sent. See QMAIL EXTENSIONS in addresses.5. Stefan
