Scott Schwartz writes:
If you don't want to fix the problem,
There is no problem. qmail is working exactly as designed. It provides
this feature with a minimum of fuss.
If sendmail or postfix did that, you'd flame about it constantly.
Your trolling is not welcome here, Scott. Go away.
Scott Schwartz writes:
The problem is that if conf-break isn't '-', then qmail-inject's "m"
and "r" options will turn replyable addresses into VERPs that are not
replyable addresses (ironic, considering VERP's ostensible purpose).
If your conf-break is +, for example, and you set environment
"D. J. Bernstein" [EMAIL PROTECTED] writes:
|QMAILSUSER=schwartz+dsn
| What's the problem?
That you didn't substantively respond to the message you just replied
to.
It's better to fix bugs than to work around them.
| If your conf-break is +, you might have a mailing list called
|
|
"D. J. Bernstein" [EMAIL PROTECTED] writes:
| Scott Schwartz writes:
| I think it's strange that qmail-inject uses '-' to seperate the mailbox
| from the verp part, even when some other conf-break character is in
| effect for that user. This surely violates the principle of least
| surprise,
"Sam" [EMAIL PROTECTED] wrote:
[1] Implementing PIPELINING in Qmail would be a rather dumb thing to do, of
course, this is theoretical.
Why do you say that? qmail-smtpd supports it, and qmail-remote support
multiple recipients.
-Dave
"Sam" [EMAIL PROTECTED] wrote:
John R. Levine ([EMAIL PROTECTED]) wrote:
My point is that it is the senders responsibility to generate a
return path. Passing that responsibility to the server isn't a good
You are passing the responsibility of delivering the entire message to the
same
Dave Sill writes:
"Sam" [EMAIL PROTECTED] wrote:
[1] Implementing PIPELINING in Qmail would be a rather dumb thing to do, of
course, this is theoretical.
Why do you say that? qmail-smtpd supports it, and qmail-remote support
multiple recipients.
Except that qmail-remote is always
"Sam" [EMAIL PROTECTED] wrote:
Except that qmail-remote is always called to deliver one recipient only.
qmail-rspawn only calls it with one recipient, but qmail-remote is
also a documented command that could be used in a home grown bulk
mailer, where pipelining would be a big win.
-Dave
Dave Sill writes:
No. You don't give a message to remote server because you think it'll
treat it right; you do it because you have to. Considering the
suprisingly large number of MTA's that don't even send bounces to the
return path, it seems likely that trusting random remote systems to
I think it's strange that qmail-inject uses '-' to seperate the mailbox
from the verp part, even when some other conf-break character is in
effect for that user. This surely violates the principle of least
surprise, and it requires some users (but not others) to manually
include their break
At 05:18 PM Friday 7/30/99, Scott Schwartz wrote:
I think it's strange that qmail-inject uses '-' to seperate the mailbox
from the verp part, even when some other conf-break character is in
effect for that user. This surely violates the principle of least
surprise, and it requires some users
From: Mark Delany [EMAIL PROTECTED]
Date: Fri, 30 Jul 1999 14:39:15 -0700
At 05:18 PM Friday 7/30/99, Scott Schwartz wrote:
I think it's strange that qmail-inject uses '-' to seperate the mailbox
from the verp part, even when some other conf-break character is in
effect for that user.
At 05:54 PM Friday 7/30/99, Chris Garrigues wrote:
From: Mark Delany [EMAIL PROTECTED]
Date: Fri, 30 Jul 1999 14:39:15 -0700
At 05:18 PM Friday 7/30/99, Scott Schwartz wrote:
I think it's strange that qmail-inject uses '-' to seperate the mailbox
from the verp part, even when some
From: Mark Delany [EMAIL PROTECTED]
Date: Fri, 30 Jul 1999 16:52:17 -0700
At 05:54 PM Friday 7/30/99, Chris Garrigues wrote:
One way to think about it is as defining a "network standard conf-break
character" which systems are expected to convert to and from in order to
Yep. A
On Fri, 30 Jul 1999, Mark Delany wrote:
Yep. A standard conf-break may not be a bad idea, but it doesn't avoid the
confusion that Scott raised that people will confuse or assume that the qmail
conf-break is the same as the VERP conf-break.
This confusion is probably confined to people who
Chris Garrigues ([EMAIL PROTECTED]) wrote:
: From: Mark Delany [EMAIL PROTECTED]
: At 05:54 PM Friday 7/30/99, Chris Garrigues wrote:
: One way to think about it is as defining a "network standard conf-break
: character" which systems are expected to convert to and from in order to
: Yep.
"Chris Garrigues" [EMAIL PROTECTED] writes:
| One way to think about it is as defining a "network standard conf-break
| character" which systems are expected to convert to and from in order to
| interoperate.
My intuition is that it would be difficult to get people to go along
with that,
Scott Schwartz writes:
I think it's strange that qmail-inject uses '-' to seperate the mailbox
from the verp part, even when some other conf-break character is in
effect for that user. This surely violates the principle of least
surprise,
Certainly not. If a mailing list is named
I'd really like to get back to the main thing, which is how the
client smtp can get to decide the form of the VERP, rather than
choose between only 2 options: obey the standard form; or don't
do VERP. If you let the client smtp decide this, you won't need to
encode/decode anything, and the
writes:
I'd really like to get back to the main thing, which is how the
client smtp can get to decide the form of the VERP, rather than
The client can get to decide right now. There's nothing to stop the client
from doing that.
As a matter of principle, if the server smtp dictates the
On Wed, 28 Jul 1999 22:44:56 GMT, Sam wrote:
There's no question that there's a big difference between sending an 8K
message to 10,000 AOL recipients - bigger lists certainly do that - as
10,000 individual messages, or 500 batchess. Someone will pipe in and
Who does still allow batches of 200?
On Thu, 29 Jul 1999 09:41:15 -0400 (EDT), Russell Nelson wrote:
Let me be the first of many who point out that 10,000 / 500 = 20. :)
... going for coffee.
I most humbly apologize for wasted bandwidth and cc the list only to
save keyboards and fingertips.
-Sincerely, Fred
(Frederik
: I'd really like to get back to the main thing, which is how the
: client smtp can get to decide the form of the VERP, rather than
: The client can get to decide right now. There's nothing to stop the client
: from doing that.
The client is not allowed to use any other separator other than
writes:
The client is not allowed to use any other separator other than '-',
You are mistaken. If I felt like it, I can easily code a mailing list
manager, using Qmail, that uses the ^ character instead.
Oh, you mean in the draft? Simply include any other valid separator as the
last
list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-varshavchik-ve
John R Levine ([EMAIL PROTECTED]) wrote:
: Gee, someone admits that VERP is a good idea.
: This draft needs a lot of work. It has gratuitous language about the extra
: bandwidth that VERP requires, and hex encodes characters for no reason I can
: understand. But I suppose the idea of allowing
My problem with it is the same problem I've always had: the
responsibility should be on the client smtp, not the server. How can
the client smtp know the server will encode the VERP correctly?
Because it uses ESMTP option negotiation to find out if the server
supports that.
It would be better
On Wed, Jul 28, 1999 at 01:55:25PM -0400, John R. Levine wrote:
Can you suggest an application where that would be useful? I use VERP
all the time and I can't ever recall a situation where the default
form of VERP wasn't entirely adequate. Adding features because
someone might want them for
[EMAIL PROTECTED] writes:
On Wed, Jul 28, 1999 at 01:55:25PM -0400, John R. Levine wrote:
Can you suggest an application where that would be useful? I use VERP
all the time and I can't ever recall a situation where the default
form of VERP wasn't entirely adequate. Adding features
John R. Levine writes:
It would be better to send as many "return paths" as recipient
addresses, but only one message. This might end up looking like:
MAIL FROM/RCPT TO:me-you-returned=example.com[EMAIL PROTECTED]
Can you suggest an application where that would be useful? I use VERP
all
John R. Levine ([EMAIL PROTECTED]) wrote:
: Because it uses ESMTP option negotiation to find out if the server
: supports that.
My point is that it is the senders responsibility to generate a
return path. Passing that responsibility to the server isn't a good
idea, regardless of whatever
writes:
John R. Levine ([EMAIL PROTECTED]) wrote:
: Because it uses ESMTP option negotiation to find out if the server
: supports that.
My point is that it is the senders responsibility to generate a
return path. Passing that responsibility to the server isn't a good
You are passing
Sam ([EMAIL PROTECTED]) wrote:
: You are passing the responsibility of delivering the entire message to the
: same exact server. If you think that the server is good enough to accept
: responsibility for delivering the message in the first place, chances that
: it's also good enough to properly
writes:
I was thinking of qmail at the time, and here's a simple way
to do it. The mod should be applicable to other MTAs that separate
the queue handling from the smtp reception.
The smtpd reads and saves all, then invokes the queuer once per
recip, with the VERPed RP. The message
34 matches
Mail list logo
