.
Executive summary: qmail breaks VERP under certain circumstances.
Let H be a host running qmail, A and B users at H, and V a virtual domain
redirected to B@H. Let X@V, i.e. B-X@H, be forwarded to some other, maybe
remote, address, say K@L. Now, let's assume A uses
QMAILINJECT=r
On Thu, 9 Aug 2001, Russell Nelson wrote:
Yes, this is a bug.
Surprised? :)
Is Dan going to issue a qmail-1.04?
Well, he could probably address other issues as well, e.g. a latent
problem with the interpretation of program return codes (summarized in my
posting titled qmail vs ld.so
On 8 Aug 2001, John R. Levine wrote:
Like I said:
It's true, qmail doesn't work the way you might first have guessed it
does. That doesn't mean it's wrong.
The fact qmail--or any other piece of software--does something does not
mean it is correct.
Executive summary: qmail breaks VERP
Executive summary: qmail breaks VERP under certain circumstances.
Revised executive summary: qmail's VERP works fine, but some people
are more than a little unclear on the way virtual domains work.
Let H be a host running qmail, A and B users at H, and V a virtual domain
redirected to B@H. Let
On 8 Aug 2001, John R. Levine wrote:
Well, actually, it should be bounced to A-X=V@H, and that's exactly
where it goes since that's the address that VERP creates. (I presume
M was a typo for H there.)
Oops. Yes, it should read A-X=V@H.
Unfortunately, the return address in the scenario
On 6 Aug 2001, John R. Levine wrote:
Is it really that overwhelmingly difficult to have whatever configures
your bounce handler look in /var/qmail/control/virtualdomains to see
what prefix to strip off the local part of the VERP address? I
suspect either of us could do it in about four
John R. Levine:
It's true, qmail doesn't work the way you might first have guessed it
does. That doesn't mean it's wrong.
Well, qmail-send does rewrite the envelope recipient for
local deliveries. That's not a very good thing.
/filip
Is it really that overwhelmingly difficult to have whatever configures
your bounce handler look in /var/qmail/control/virtualdomains to see
what prefix to strip off the local part of the VERP address? I
suspect either of us could do it in about four lines of perl.
You can turn the question
it in this case. What if
`[EMAIL PROTECTED]' *was* a valid, different
address? It could falsely detect loops. Maybe that wouldn't make
sense in this particular case, but I'm sure you can construct a more
palatable case with little effort.
Also, that doesn't resolve my VERP problem.
in this particular case, but I'm sure you can construct a more
palatable case with little effort.
Then use a character in virtualdomains which is not legal in an email
address. I thought you didn't need to be taught the religion?
Repent, sinner!
Also, that doesn't resolve my VERP problem.
Sorry, I thought
Also, that doesn't resolve my VERP problem.
Sorry, I thought it did. Why doesn't it?
Uhhh, did you *read* my first piece of email? If I get a VERP address
of `[EMAIL PROTECTED]',
how pray tell is my mailing list software supposed to know that the
mail was actually sent to `[EMAIL PROTECTED
Charles M. Hannum writes:
Also, that doesn't resolve my VERP problem.
Sorry, I thought it did. Why doesn't it?
Uhhh, did you *read* my first piece of email? If I get a VERP address
of `[EMAIL PROTECTED]',
how pray tell is my mailing list software supposed to know
On Mon, 6 Aug 2001, Russell Nelson wrote:
Charles M. Hannum writes:
Uhhh, did you *read* my first piece of email? If I get a VERP address
of `[EMAIL PROTECTED]',
how pray tell is my mailing list software supposed to know that the
mail was actually sent to `[EMAIL PROTECTED
On Mon, 6 Aug 2001, Russell Nelson wrote:
Charles M. Hannum writes:
Uhhh, did you *read* my first piece of email? If I get a VERP address
of `[EMAIL PROTECTED]',
how pray tell is my mailing list software supposed to know that the
mail was actually sent to `[EMAIL PROTECTED
Charles M. Hannum writes:
There is no way for the mailing list software to get from
`[EMAIL PROTECTED]' to
`[EMAIL PROTECTED]' without having knowledge of virtualdomains.
That's not an acceptable solution.
Why not?
--
-russ nelson [EMAIL PROTECTED] http://russnelson.com
Crynwr sells
/control/virtualdomains to see
what prefix to strip off the local part of the VERP address? I
suspect either of us could do it in about four lines of perl.
It's true, qmail doesn't work the way you might first have guessed it
does. That doesn't mean it's wrong.
--
John R. Levine, IECC, POB 727
-To: is considered opaque, which is satisfactory for its role
as a loop inhibitor -- as long as the Delivered-To: line for a given
address is the same, a loop will be detected.
For VERP to be useful, the VERP address needs to be the latter;
otherwise my mailing list manager won't be able to handle
I have a mail host -- call it netbsd.org -- that's been running qmail
1.03 for rather a long time. It uses VERP heavily to do automatic
bounce handling for mailing lists. It also uses virtualdomains to
serve a couple of personal vanity domains.
In virtualdomains, I have
Hi,
I use a PERL script to send out a daily newsletter. Here's the send
fragment:
if (!defined $dry) {
$ENV{QMAILUSER} = $mailuser;
$ENV{QMAILHOST} = $mailhost;
$ENV{QMAILINJECT} = r;
foreach $email (@subscribers) {
open MAIL,
Hello.
I am trying to setup automatic bounce handling for mailing list ,where the
messages are injected to qmail by smtp, one by one - customised messages for
every recipient, with the correct smtp envelope for VERP, and the address
list is extracted from a database before the list is being sent
-from your qmail--and it'll go to the
"me-" address rather than the me-user%host VERP address. This is
done this way because the local bounce can contain multiple
undeliverable addresses. To process these bounces, you need to parse
the QSMBF-format bounce message that qmail generates.
"Brett" [EMAIL PROTECTED] wrote:
I'm trying to implement VERP for my own user address, that is, an address
that's not a mailing list.
I found a VERP page (quoted below) and according to that I should touch
~/.qmail-me-owner and ~/.qmail-me-owner-default. Then if I set the
Q
I'm still having the same annoying problem with the VERP implementation. How
do I get it running on my home email address? That is, all emails I send out
from [EMAIL PROTECTED], if bounced, I want sent back to
[EMAIL PROTECTED] Thanks.
: Thursday, March 22, 2001 10:51 AM
To: [EMAIL PROTECTED]
Subject: Re: VERP problems
"Brett" [EMAIL PROTECTED] wrote:
I'm trying to implement VERP for my own user address, that is, an address
that's not a mailing list.
I found a VERP page (quoted below) and according to that I should touc
"Brett" [EMAIL PROTECTED] wrote:
I'm still having the same annoying problem with the VERP implementation. How
do I get it running on my home email address? That is, all emails I send out
from [EMAIL PROTECTED], if bounced, I want sent back to
[EMAIL PROTECTED] Thanks.
Did you rea
Brett [EMAIL PROTECTED] wrote:
Okay, but the bounce sent to [EMAIL PROTECTED] also gets bounced. It doesn't
know to send 'me-*' eamil through to 'me' even though I've touched
~/.qmail-me-owner and ~/.qmail-me-owner-default and chmodded both to 777.
Making the files world-writable is bad, and
"Brett" [EMAIL PROTECTED] wrote:
Okay, but the bounce sent to [EMAIL PROTECTED] also gets bounced. It doesn't
know to send 'me-*' eamil through to 'me' even though I've touched
~/.qmail-me-owner and ~/.qmail-me-owner-default and chmodded both to 777.
Try touching .qmail-default. Neither
ystem is not able to pass a message off to a remote system, the
bounce generated will be local--from your qmail--and it'll go to the
"me-" address rather than the me-user%host VERP address. This is done
this way because the local bounce can contain multiple undeliverable
addresses. To process the
I'm trying to implement VERP for my own user address, that is, an address
that's not a mailing list.
I found a VERP page (quoted below) and according to that I should touch
~/.qmail-me-owner and ~/.qmail-me-owner-default. Then if I set the
QMAILINJECT environment variable to 'r', I'm ready to go
Brett [EMAIL PROTECTED] wrote:
I found a VERP page (quoted below) and according to that I should touch
~/.qmail-me-owner and ~/.qmail-me-owner-default. Then if I set the
QMAILINJECT environment variable to 'r', I'm ready to go. I call:
echo to:[EMAIL PROTECTED] | /var/qmail/bin/qmail
: Wednesday, March 21, 2001 4:42 PM
To: [EMAIL PROTECTED]
Subject: Re: VERP problems
Brett [EMAIL PROTECTED] wrote:
I found a VERP page (quoted below) and according to that I should touch
~/.qmail-me-owner and ~/.qmail-me-owner-default. Then if I set the
QMAILINJECT environment variable to 'r
action not taken: mailbox name not allowed
I'd say that is a completely screwed up smtp server or maybe a firewall.
Anyone else seen this? Does anyone have any spiffy ideas for working
around this? Perhaps some way to rewrite the headers to a few specific
users to eliminate the VERP?
Tried
On Thu, Nov 09, 2000 at 10:41:21AM +0100, Markus Stumpf wrote:
On Wed, Nov 08, 2000 at 04:46:29PM -0800, Ben Beuchler wrote:
Connected to scooby.helpsystems.com.
Escape character is '^]'.
220 SMTP service ready
This doesn't look like a Lotus Mailserver.
Based on what some others have
On Thu, Nov 09, 2000 at 03:16:31PM +1100, Brett Randall wrote:
On Wed, 8 Nov 2000, [EMAIL PROTECTED] wrote:
[insyte@blah insyte]$ telnet scooby.helpsystems.com 25
Trying 209.32.71.125...
Connected to scooby.helpsystems.com.
Escape character is '^]'.
220 SMTP service ready
helo
On Wed, Nov 08, 2000 at 11:07:00PM -0800, Ben Beuchler wrote:
220 SMTP service ready
helo doofus
250 Requested mail action okay, completed
mail from:[EMAIL PROTECTED]
553 Requested action not taken: mailbox name not allowed
quit
221 SMTP server closing transmission channel
Just in case
Good afternoon, y'all...
Has anyone exprienced problems with VERP and recipients behind Lotus
Domino? I've been having some problems with a few of my ezmlm
recipients that are using Lotus Domino as their mail server. It appears
that Domino flagrantly flies in the face of RFC822 by rejecting
Good afternoon, y'all...
Has anyone exprienced problems with VERP and recipients behind Lotus
Domino? I've been having some problems with a few of my ezmlm
recipients that are using Lotus Domino as their mail server. It appears
that Domino flagrantly flies in the face of RFC822 by rejecting
On Wed, 8 Nov 2000, [EMAIL PROTECTED] wrote:
[insyte@blah insyte]$ telnet scooby.helpsystems.com 25
Trying 209.32.71.125...
Connected to scooby.helpsystems.com.
Escape character is '^]'.
220 SMTP service ready
helo doofus
250 Requested mail action okay, completed
mail from:[EMAIL
Hello,
Once in a while I have to send messages thousands of users that are listed
in a dynamic database. Is not viable for me to use a mailing list manager.
To handle bounces I use VERP by connecting to the Qmail SMTP server directly
like this:
HELO localhost
MAIL FROM:[EMAIL PROTECTED
John White [EMAIL PROTECTED] schrieb/wrote:
Actually, you can use the user-@domain-@[] format when talking
to qmail-smtpd, and the VERP expansion will be handled.
I'd call that a bug.
--
Claus Andre Faerber http://www.faerber.muc.de
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69
What's the best way to build a bounce-handling capability in coordination
with qmail? What are the proper source files to look at in ezmlm to discover
how it does it?
The qmail-ezmlm bounce picture would be helpful, something in higher detail
than
"ezmlm uses qmail's VERPs to send a
On Wed, Apr 12, 2000 at 01:26:07AM -0200, Manuel Lemos wrote:
Hello John,
On 12-Apr-00 02:05:12, you wrote:
On Wed, Apr 12, 2000 at 12:50:41AM -0200, Manuel Lemos wrote:
Do you mean there is no way to determine wether the SMTP server supports
VERP?
Of course there is. You can tell
On Wed, Apr 12, 2000 at 12:07:09AM -0700, Russ Allbery wrote:
Manuel Lemos [EMAIL PROTECTED] writes:
Maybe I am missing here something that is simpler than I think but that
still doesn't answer my basic question: what SMTP command sequence do I
need to use to enable VERP on message
On Wed, Apr 12, 2000 at 03:10:14AM -0700, John White wrote:
FROM: [EMAIL PROTECTED]
TO: [EMAIL PROTECTED]
Of course that's
MAIL FROM:
and
RCPT TO:
John
John White [EMAIL PROTECTED] writes:
On Wed, Apr 12, 2000 at 12:07:09AM -0700, Russ Allbery wrote:
None. By the time the message reaches the SMTP level, VERP has already
been done. VERP is not an SMTP feature.
*cough*
Actually, you can use the user-@domain-@[] format when talking
On Wed, Apr 12, 2000 at 01:57:49PM -0700, Russ Allbery wrote:
John White [EMAIL PROTECTED] writes:
On Wed, Apr 12, 2000 at 12:07:09AM -0700, Russ Allbery wrote:
None. By the time the message reaches the SMTP level, VERP has already
been done. VERP is not an SMTP feature.
*cough
*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi.
In several places I was reading about the "VERP (Variable Envelope
Return Path)" feature of qmail.
Unfortunately, I didn't find any information about how to use this
feature.
I have an applicat
On Thu, Mar 30, 2000 at 02:23:47PM +0200, Martin Renner wrote:
*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi.
In several places I was reading about the "VERP (Variable Envelope
Return Path)" feature of qmail.
Unfortunately, I didn't find any i
I have an application, which is communicating directly via SMTP with
qmail. As I am sending to huge lists (up to 28000 recipients) I would
like to use VERP.
Set up an ezmlm(-idx) list on the qmail host. Send to the list address via
SMTP. That's it.
Regards, Frank
On Tue, 4 Jan 2000, Russell Nelson wrote:
Pavel Kankovsky writes:
And it bounces to "user-bounce-@hostname"
Yup. When the VERP part is empty, then you know that it's an QSBMF,
but Qmail's Bounce Message Format is Simple to Parse. What's the big
deal?
1. QSBMF may be Simpl
Pavel Kankovsky writes:
1. QSBMF may be Simple to Parse but it cannot be as simple as $EXTn
Just about. See below.
2. qmail-VERP combo should not be advertised and/or documented as
something *eliminating* the need to parse bounces completely
Sheesh, Pavel, get a life or something
ender.s + sender.len - 5,"-@[]"))
{
sender.len -= 4;
sender.s[sender.len - 1] = 0;
}
I understand VERP would make the things more complicated because one would
have to generate one bounce message per failed recipient (and it would
also made bounce-bombing much easier)
Pavel Kankovsky writes:
And it bounces to "user-bounce-@hostname"
Yup. When the VERP part is empty, then you know that it's an QSBMF,
but Qmail's Bounce Message Format is Simple to Parse. What's the big
deal?
--
-russ nelson [EMAIL PROTECTED] http://russnelson.com
Crynwr sel
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
ist called
|
|[EMAIL PROTECTED]
That looks like a weak attempt at insult, which, unfortunately, doesn't
address the issue:
qmail-inject's verp flags silently turn valid envelopes into invalid
ones iff someone uses a different configuration than the author and
doesn't take otherwise unnecessary evas
"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
|
"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
o
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.
Note that exactly this problem comes up when people write programs to talk to the
SMTP port and assu
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.
t people to go along
with that, especially since the break character is in the uninterpreted
local mailbox part of the address.
| This is much like FTP URLs using '/' characters no matter what
So, we invent a new kind of URL:
verp://cse.psu.edu/schwartz/qmail/
In fact, to save ty
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
Jim
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
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
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
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 the VERP expansion on another
machine is OK
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
[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
ou 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.
Someone took the trouble to put up a draft; so at least one person
feels there's bandwidth savings to be had. The pseudo-esm
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 the time and I can't ever recall a situation where the default
: form of V
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
text is the same, i.e. the
list is exploded at this point. The queuer and everything else
works as normal.
How to you propose to arrange for the next relay in the chain, which
advertises support for your VERP extension, to receive the original message
in the same condensed MAIL FROM/RCPT
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
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
Harald Hanche-Olsen writes:
Putting virtual.dom:foo in virtualdomains and
expecting to control this by ~alias/.qmail-foo-default does not work.
Hmmm? [EMAIL PROTECTED] is rewritten as foo-joe and delivered locally. The
delivery is handled by ~alias/.qmail-foo-joe, -foo-default, or -default.
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
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
oded in qmail-send.c), but the - there shouldn't
matter because it's stripped. The VERP process doesn't appear to add any
other break characters; instead, it uses the characters already in the
address.
So if you just fix whatever it is that you're using to send mail so that
instead of generat
On Thu, Jan 21, 1999 at 09:26:55PM -0800, Russ Allbery wrote:
So if you just fix whatever it is that you're using to send mail so that
instead of generating return addresses of the form:
list-bounces-@host-@[]
it generates them as:
list+bounces+@host-@[]
I believe
Tim Pierce [EMAIL PROTECTED] writes:
Mail is sent with a wrapper around qmail-inject, with an environment of:
QMAILSUSER= list-request
QMAILSHOST= rootsweb.com
QMAILINJECT = r
Am I doing it the wrong way? This is the only reference to VERPs I
Tim Pierce writes:
Is this intentional?
Yes. Dash-separated extensions are used in the .qmail-*-default
mechanism, qmail-inject VERPs, ezmlm VERPs, etc.
conf-break is the default user-ext delimiter. It doesn't affect the use
of dashes inside extensions.
---Dan
- "D. J. Bernstein" [EMAIL PROTECTED]:
| Tim Pierce writes:
| Is this intentional?
|
| Yes. Dash-separated extensions are used in the .qmail-*-default
| mechanism, qmail-inject VERPs, ezmlm VERPs, etc.
|
| conf-break is the default user-ext delimiter. It doesn't affect the use
| of dashes
D J Bernstein [EMAIL PROTECTED] writes:
Yes. Dash-separated extensions are used in the .qmail-*-default
mechanism, qmail-inject VERPs, ezmlm VERPs, etc.
conf-break is the default user-ext delimiter. It doesn't affect the use
of dashes inside extensions.
Am I correct in thinking, then, that
On Fri, Jan 22, 1999 at 03:01:36AM -0800, Russ Allbery wrote:
D J Bernstein [EMAIL PROTECTED] writes:
Yes. Dash-separated extensions are used in the .qmail-*-default
mechanism, qmail-inject VERPs, ezmlm VERPs, etc.
conf-break is the default user-ext delimiter. It doesn't affect the use
[ I sent this to qmail-help a month or so ago, but had no response. ]
I'm using qmail as the outbound mail agent on a machine that runs
sendmail for incoming mail. I would like to modify qmail to use "+"
in constructing per-recipient VERPs on outgoing mail. That's
necessary to make sendmail
1 - 100 of 104 matches
Mail list logo
