On Mon, 15 Nov 1999 22:31:52 -0600, Bruce Guenter wrote:
>> > > 2a. if -l: compare host name of envelope recipients. If same as local host
>> > > name, deliver locally with qmail-local.
>> > > 2b. deliver multi-recipient message remotely (concurrent with 2a). If -l:
>> > > remove all recipients with host part matching the local host (me).
>
>Any suggestions on how to do concurrent deliveries correctly (ie even
>under error conditions)?
I think the easiest is to use a scheme like QMQP. One message per
connection and all recipients are accepted. The smarthost does all the
bounce generation, etc, so there are 3 possible outcomes: message
accepted, message not accepted (malformatted addresses -checked already
by qmail-queue if used, so very unusual and probable should be treated
as a temp error in this type of system), or time-out (deferral).
qmail-qmqpc already has failover for QMQP servers.
So, identify and mark local recipients. Concurrent {dispatch local
delivery agent for each local recipient - mark result; send remote
recipients via QMQP to smarthost - mark all remote recipient records
with result; }, redeliver until all recipients done (bounce or success)
or message exceeds queue life (bounce remaining).
>> > > 3. Generate one bounce message per local recipient. Generate pre-VERP
>> > > bounce if one of more remote recipients are not accepted.
>
>What do you mean by "pre-VERP"?
When the SENDER looks like .....-@[]
qmail-remote and qmail-local will adjust SENDER to put in the encoded
recipient address. This does not have to be done for qmail-qmqpc, since
the smarthost will always run qmail and there will always be a
qmail-remote or a qmail-local before final delivery.
I don't know if there is an advantage to using QMTP for this. One
problem is that qmail-qmqpc has a 60 s read time out. For the final
"OK" this means that if it takes longer than 60 s the client will think
that the message was not accepted resulting in duplication (for all
recipients, of course). This is ok for the intended use of qmail-qmqpc,
but should be increased to e.g. 300/600. Time-out happened a few times
with list messages from Brasil over ISDN to an underdimensioned list
exploder here in St. Louis. Increasing the time-out t e.g. 300 solved
this. QMQP over local LAN has been 100% reliable with default settings.
>And nobody should bet their business on something that doesn't exist
>yet, no matter how good the reputation.
Agreed. Also, no reason to believe that DJB will address this
particular issue.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
