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 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.
> 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.
>
> : >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 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;
That would be me.
> 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.
That is the sole difference between your proposal, and mine. Everything
else is exactly the same, because you will still have to go through the
same logistics in order to integrate any kind of an ESMTP-based VERP
extension[1].
[1] Such as what to do when you must relay to a server that does not
support the extension, or deliver a message to the local mailbox.
--
Sam
