Re: send bcc: wierdness?
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 sez: > Date:Mon, 13 Apr 2020 01:05:54 -0400 > From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" > 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
Re: send bcc: wierdness?
Date:Mon, 13 Apr 2020 01:05:54 -0400 From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" 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
Re: send bcc: wierdness?
On Sun, 12 Apr 2020 18:59:01 +0700, Robert Elz said: > Yes, so both were OK, which means it is OK to transmit the message. > > That needed to be done in two different SMTP transactions, to avoid > revealing the bcc user's address to the other user (nmkh doesn't > know they're both you). But if it already knew that it would need two transactions, why did it bother with the first transaction? 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? (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...) Or has it been doing a pre-test all along and I've just never caught it at it? :) pgpzvPkYqluRa.pgp Description: PGP signature
Re: send bcc: wierdness?
Date:Sun, 12 Apr 2020 05:17:19 -0400 From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" Message-ID: <423943.1586683039@turing-police> | Well, the -snoop output was pretty clear that Google's inbound | listener on port 587 gave back a 250 OK on both addresses: Yes, so both were OK, which means it is OK to transmit the message. That needed to be done in two different SMTP transactions, to avoid revealing the bcc user's address to the other user (nmkh doesn't know they're both you). | it's even more broken than we thought Not broken at all, it is doing exactly what it was supposed to do. It's just that doing the Rcpt To pre-check these days is mostly a waste of time, as everyone simply says OK to every syntactically correct address they're handed (and of course, nmh/MH would never pass on a syntatically invalid address). kre
Re: send bcc: wierdness?
On Sun, 12 Apr 2020 14:54:31 +0700, Robert Elz said: > That will be do that is one of the addresses is bad (and the receiving > MTA can work that out - which it once would have often done, and sadly these > days, amost never) then the message gets delivered to no-one, rather than Well, the -snoop output was pretty clear that Google's inbound listener on port 587 gave back a 250 OK on both addresses: (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RSET (tls-decrypted) <= 250 2.1.5 Flushed o16sm4571323qki.110 - gsmtp (tls-encrypted) => MAIL FROM: (It then goes on to correctly send one copy to each destination) So if it was supposed to retry if one address was bad, it's even more broken than we thought pgpb2UD3AalNg.pgp Description: PGP signature
Re: send bcc: wierdness?
Hi, Ken wrote: > I replied to that message on exmh-users, giving the history of things > and some possible solutions. Archived: https://marc.info/?l=exmh-users&m=158665218124252&w=2 -- Cheers, Ralph.
Re: send bcc: wierdness?
Date:Sun, 12 Apr 2020 01:05:29 -0400 From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" Message-ID: <413088.1586667929@turing-police> | the part I couldn't figure out is why it sends EHLO, RCPT TO, RCPT TO | - and then an RSET rather than DATA, before sending the two copies. That will be do that is one of the addresses is bad (and the receiving MTA can work that out - which it once would have often done, and sadly these days, amost never) then the message gets delivered to no-one, rather than being sent to some of the destinations, leaving you to work out how to reconstruct the message to send it with corrected addresses, without bothering people who got the first one with a second (and so those people don't receive a message containing bad addresses if at all possible). That should probably all go now - no-one's local MTA does remote addr resolution before accepting the addr - most don't even do local addr resolution - they just send a bounce message later. kre
Re: send bcc: wierdness?
On Sat, 11 Apr 2020 23:05:25 -0400, Ken Hornstein said: > >So I got a user report that exmh was doing something weird with bcc:. > >[...] > > Geez, Valdis, people have only talked about (n)mh's weird bcc for ... > 30 years? :-) Even in threads you have commented on, as recently > as a year ago: > >https://lists.nongnu.org/archive/html/nmh-workers/2019-02/msg4.html > > I replied to that message on exmh-users, giving the history of things > and some possible solutions. Yeah, I understand why it goes and sends 2 separate envelopes - the part I couldn't figure out is why it sends EHLO, RCPT TO, RCPT TO - and then an RSET rather than DATA, before sending the two copies. pgpj29Xpk3bc5.pgp Description: PGP signature
Re: send bcc: wierdness?
>So I got a user report that exmh was doing something weird with bcc:. >[...] Geez, Valdis, people have only talked about (n)mh's weird bcc for ... 30 years? :-) Even in threads you have commented on, as recently as a year ago: https://lists.nongnu.org/archive/html/nmh-workers/2019-02/msg4.html I replied to that message on exmh-users, giving the history of things and some possible solutions. --Ken
send bcc: wierdness?
So I got a user report that exmh was doing something weird with bcc:. I looked at the exmh code, which doesn't do anything special with bcc:, it just assumes that the underlying nmh will DTRT. So.. I go to test nmh. As tested, it had: From: "Valdis =?utf-8?Q?Kl=c4=93tnieks?=" To: valdis.kletni...@gmail.com bcc: val...@vt.edu Fcc: +outbox Subject: Test of bcc: nmh adsfasdf And I do a 'send -watch -snoop', and the relevant part of the transcript says: (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RSET (tls-decrypted) <= 250 2.1.5 Flushed o16sm4571323qki.110 - gsmtp (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => DATA (tls-decrypted) <= 354 Go ahead o16sm4571323qki.110 - gsmtp (tls-encrypted) => . (tls-decrypted) <= 250 2.0.0 OK 1586650839 o16sm4571323qki.110 - gsmtp (tls-encrypted) => RSET (tls-decrypted) <= 250 2.1.5 Flushed o16sm4571323qki.110 - gsmtp (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => DATA (tls-decrypted) <= 354 Go ahead o16sm4571323qki.110 - gsmtp (tls-encrypted) => . (tls-decrypted) <= 250 2.0.0 OK 1586650840 o16sm4571323qki.110 - gsmtp (tls-encrypted) => QUIT (tls-decrypted) <= 221 2.0.0 closing connection o16sm4571323qki.110 - gsmtp which looks to me like it tried both destinations, got 250 back for them.. ... and then did an RSET and sent as two separate SMTP transactions. which had me going WTF?? (and it of course didn't help my mood that this doesn't match the reported problem behavior, which sounds like 'send' did a 'forw -mime', but the embedded message wasn't recognized as MIME message/822 and all the headers displayed in the body of the message, which of course confused all the non-expert recipients...) pgpSWknsJCcL0.pgp Description: PGP signature
