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 client smtp will be able to choose
the form most suited to his purpose.
As a matter of principle, if the server smtp dictates the VERP
form and screws up, the sender loses through no fault of his own
(doesn't get bounce). If the server smtp screws up on any other
smtp convention, they both lose (sender doesn't get his msg across,
recipient doesn't get msg).
If the above were satisfied, I'd be happy with almost any
implementation, because:
1. Any postponement of explosion is a decided advantage.
Even though:
2. It is always safe and correct to explode.
Sam ([EMAIL PROTECTED]) wrote:
: > The advantage here is that you've saved N messages over one hop with
: > no change to the queue handler. If you're not a relay, that's the
: > only hop that matters.
: Unfortunately, only an insignificantly small number of messages travel over
: one hop only.
The only hop that matters is the one to the target mx. Hops before
and after are unimportant:
Before the Hop, the message is in the senders domain, and if the
admin has his wits about him, he will not let the recip list be
exploded before the Hop. He wants to keep that option open.
After the Hop, the message is in the recips domain, where it will
need to be exploded anyway for individual recips.
: Well, you will end up with multiple copies of the message in even the first
: hop's queue. As long as the message hops amongst servers that support
: VERP, it will always stay a single message, unless it splits off to
: different domains, etc...
Yes, absolutely. As above, if it's local, it doesn't bother me.
If it's not local, djb would say, sub-list the thing.
Other stuff...
: > For qmail, this pre-explosion has advantages. Russ (Nelson?)
: > pointed out a problem with mega-multi-recip msgs, being they
: > don't get scheduled independently, which can lead to a sendmail-like
: > queue run.
: Only if you code the server to act like sendmail.
I don't have the message number, it was quite some time back.
qmail schedules attempts based on the age of the message, however
many recips it has. It is the -message- that is attempted, so for
a hundred recips, a hundred qmail-remotes (subject to concurrency)
are spawned at once. This sudden and periodic load spike has the
appearance of a queue run. But if there were a hundred messages
with one recip each, their retry times spread out.
: > Main problem here is error handling, that your boolean-flag approach
: > doesn't have.
: Specifically what in regards to error handling are you referring to?
It's a consequence of having multiple copies. The last 250 ok after
DATA is meant to confirm ALL recips before, but what if I run out of
disk halfway through. I have to reject all, and recovery is messy.
But if the message preceded the recip list, then the 250 is for the
recip, not the message, and I can confirm the recips individually.
I don't think you can have this problem.
-harold
