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 bounce it.
True, but this requires *brain work* :) not in the manner of mindless
copying of a message and adding a couple of Received lines. But
point taken, you've got to trust him at least a bit.
: > idea, regardless of whatever promises the server makes, when it is
: > so easy for the sender to send the VERPified RP.
: There's nothing in the draft that keeps you from doing that, as long as you
: understand the pluses and the minuses versus the approach defined in the
: draft.
: > Someone took the trouble to put up a draft;
: That would be me.
Oh! You know I came -this close- to calling you a ninny :)
: > so at least one person
: > feels there's bandwidth savings to be had. The pseudo-esmtp command
: > example accomplishes that with less complexity than the draft, and
: No it doesn't. The server now has to keep track of a separate return
: address for each recipient, instead of keeping one boolean flag for the
: entire message.
: > is probably more easily retrofitted into existing servers than
: > embedding yet a whole nuther encoder/decoder.
: No it's not. Do you think it's easier to retrofit existing servers to now
: keep track of an additional metada per each recipient, or an additional
: item of information per message? Although many servers already do keep
: track of recipient-specific metadata (required to support ESMTP DSN), many
: servers - such as Qmail - do not have any kind of recipient-specific
: metadata, except for some slight distinction between local and remote
: recipients. Implementing your proposal in Qmail will require substantially
: more coding and effort.
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.
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.
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.
Main problem here is error handling, that your boolean-flag approach
doesn't have. 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.
I'd be glad to take this off list since it's not really qmail
related.
-harold
