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 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 TO conversation that you described?
If the queuer, and everything else, is unchanged, then this will not
happen. What you've described will work for one hop only, and will cease to
be effective on subsequent hops. A typical message usually hops through
several relays, and even if every one of them is modified according to your
plan, only the first hop will result in any kind of optimization
whatsoever.
> 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.
> 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.
> 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?
> This can be rectified by having the message precede
> the recipient list so each 250 ok is really ok.
>
> Another problem is disk space used.
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...
> I'd be glad to take this off list since it's not really qmail
> related.
Actually it does relate to Qmail, in a certain way.
--
Sam
