Re: send bcc: wierdness?

[Bob Carragher]

Thank you for this explanation, Robert!  I now understand a huge
chunk of the -snoop output to post(1) ... that admittedly I
hadn't been paying close attention to.  B-)

                                Bob

P.S.  and, apologies to those who explained it before, when I
still wasn't paying close attention.  B-)

On Mon, 13 Apr 2020 13:04:07 +0700 Robert Elz <address@hidden> sez:

>     Date:        Mon, 13 Apr 2020 01:05:54 -0400
>     From:        "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <address@hidden>
>     Message-ID:  <477754.1586754354@turing-police>
>
>   | But if it already knew that it would need two transactions, why did it 
> bother
>   | with the first transaction?
>
> To verify that both addresses are OK.   Whatever sequence it uses,
> 3 SMTP transactions are needed, one to validate the first address,
> (and optionally the second), one to deliver to the second address
> (also validating it if that wasn't done in the first) and one to
> deliver to the first addr.
>
> There could be one less RCPT TO transaction than is currently used,
> but only when there are just 2 deliveries needed, add a 2nd Bcc
> recipient, and now 3 separate delivery SMTP connections are needed,
> plus verification - if all 3 addresses are verified in the first
> connect, a total of four, any other sequence and more are required.
>
> Hence, verify everything in the first transaction, and once we know
> all addresses are OK, deliver to them in one transaction for all visible
> recipients (if all are, this can be a continuation of the verification
> connection - which is the usual case) and one more for each bcc recipient.
>
>   | Or is the problem that if the first transaction sends 1 bcc note
>   | and succeeds, and the second sends 3 successful and one failed,
>   | error recovery gets difficult?
>
> Yes.   Whichever order those two are done.    I believe though that
> the three and one case ends up in no deliveries - I think you'll find
> that if there are any failures (even temporary ones) to any of the
> RCPT TO commands (or MAIL FROM obviously) then MH's SMTP agent quits,
> and never sends a DATA command.   It sends to everyone or no-one.
>
>   | (Though even if you have no bcc's, and 2 recipients to 1 mx,
>   | and 2 recipients to a different mx, and one fails, you still
>   | have the same problem...)
>
> Yes, but recall than when MH was developed, for 99% of e-mails, all
> recipients were on the local system, networking was still (mostly)
> a coming thing, for the vast majority of users.
>
>   | Or has it been doing a pre-test all along and I've just never
>   | caught it at it? :)
>
> Yes, always - but when there are no BCC recipients, then there's no
> need for separate SMTP transactions, and once the pre-test is done,
> we can simply complete the transaction with a DATA command,   This
> separate SMTP series is only needed when we're hiding recipient addresses,
> so one SMTP transaction cannot be shown all of them.
>
> kre