To help you out with that comment:
http://web.infoave.net/~dsill/lwq.html#multi-rcpt
I'm not sure if that's the best discussion on the issue, but its there
(that section and the next).
The quick version is:
VERP was proposed by DJB as a way to identify bounce recipients. VERP
requires that each recipient have their own From: as well as To:. Being
able to identify bouncing addresses is important on large mailing lists.
There are scenarios, however, that are ignored by the original thinkers,
I believe.
For instance, multiple MTAs for one organisation that handle different
protocols for speed of queuing, etc. (SMTP on one machine, POP3 on
another). If the MTA is used for internal domain traffic (in one case I
administer, 97% or so is internal), the message-splitting can be a
definate aggrevation.
Now, the page above mentions that changing the delivery method would
require a lot of work. Because of that, this discussion will probably
end up going nowhere eventually, but having the opinions of many out in
the open is 'a good thing'. That said, it would be wonderful for those
of us who feel it to be a good idea, to have the delivery system offer
the option of either "always massively parallel" ;-) or "limited" (by
adding a value to 'control/maxsmtpsessions' or something -- with queuing
as I proposed) or "multi recipient" ... the way that destroys VERP.
At any rate, I'm going to see if I can grab some stats on the types of
messages I'm speaking of off a few servers and put some stats together.
(PS, its been an interesting clash here ... nice to have a list full of
severely opinionated people) :)
Paul Jarc wrote:
> Mark Mentovai <[EMAIL PROTECTED]> writes:
> > If an MTA receives a message with 100 recipients with the same MX,
> > there is no reason to transfer the message to the remote mail
> > exchanger 100 times.
>
> Yes, there is: per-recipient VERPs. You may not see this as
> outweighing the bandwidth issue, but it's still a reason in favor of
> individual transfers, given the limits of SMTP.
