Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
Moin On Mon, Nov 29, 2021 at 01:57:54PM -0800, Michael Peddemors via mailop wrote: > No, Pipeline is not advertised, the RFC's say that when you send a command, > if you are NOT using pipelining, you need to wait for a response, and that > includes the QUIT.. wait for the receiving system to send an OK in this > respect, not only does it satisfy RFC's but also helps differentiate from > the many spamming systems that terminate as quickly as they can to reduce > overhead when spamming. Where did you find a pre-historic SMTP server without PIPELINING? Also RFC 5321 sounds quite clear to me: | The sender MUST NOT intentionally close the transmission channel until | it sends a QUIT command, and it SHOULD wait until it receives the reply | (even if there was an error response to a previous command). So the wait for QUIT reply is a SHOULD. Bastian -- Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
It appears that Bill Cole via mailop said: >SMTP clients of all sorts have done this (and worse, e.g. just FIN after >getting a 250 at end-of-data) for at least 3 decades. I don't see how it >could possibly be useful at this late date to try to enforce that SHOULD >which only exists for a human sense of elegance and tradition. ... What he said. qmail has been dropping after the QUIT command since 1998. It's not a useful spam signal. R's, JOhn ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On 2021-11-29 at 20:00:14 UTC-0500 (Mon, 29 Nov 2021 17:00:14 -0800) Michael Peddemors via mailop is rumored to have said: It does sound like you are arguing for dropping QUIT altogether, Nope. I didn't say that or anything like that. QUIT is essential. The response to QUIT is superfluous. but the protocol was designed for robustness, and there is a reason for the general use of COMMAND/ACKNOWLEGEMENT. That reason is not valid at QUIT because the reply MUST always be sent and MUST always be 220 and neither side has any freedom of action within the protocol after the QUIT has been sent. However, he is missing that earlier in the same RFC we see.. (Notice the MUST NOT, which over reaches the later SHOULD) Didn't miss it at all. I just read it more tightly. 3.8. Terminating Sessions and Connections An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code, after which it closes the connection. An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except: That MUST NOT does not apply to the client side of the SMTP session, it applies strictly to the server side. The fact that the client may actually be something we would more loosely call a server (i.e. Exchange, ) is irrelevant. In RFCxx21 jargon, there is only one server in a SMTP conversation, and it doesn't initiate closure. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On 2021-11-30 09:00:14 (+0800), Michael Peddemors via mailop wrote: On 2021-11-29 3:20 p.m., Bill Cole via mailop wrote: Michael Peddemors via mailop is rumored to have said: No, Pipeline is not advertised, the RFC's say that when you send a command, if you are NOT using pipelining, you need to wait for a response, and that includes the QUIT.. wait for the receiving system to send an OK in this respect, not only does it satisfy RFC's but also helps differentiate from the many spamming systems that terminate as quickly as they can to reduce overhead when spamming. Review the precise wording of https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.10 SHOULD in RFCs is stronger than it is in casual use, but it is still SHOULD, not MUST. SMTP clients of all sorts have done this (and worse, e.g. just FIN after getting a 250 at end-of-data) for at least 3 decades. I don't see how it could possibly be useful at this late date to try to enforce that SHOULD which only exists for a human sense of elegance and tradition. The "polite" pattern doesn't serve any functional purpose at QUIT, because there's no ambiguity for either side if the reply is simply lost. Even if QUIT is never sent and the client just sends a FIN packet after its last message is acknowledged, the only ambuiguity is that the server doesn't know whether the client failed in some way or was just finished sending messages, and that's not something a server should usually care about. For anyone not familiar with the passage.. Bill is 'technically' correct on this point.. 4.1.1.10. QUIT (QUIT) This command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel. The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command, and it SHOULD wait until it receives the reply (even if there was an error response to a previous command). This unambiguously permits the sender to terminate the connection as soon as it has sent a QUIT command. As Bill points out, RFC 2119 SHOULD (also spelled RECOMMENDED) is stronger than a casual "should". It has a very specific definition which is worth repeating in full: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (And yes Bill, we do see the odd system sending a FIN without even a QUIT, and it is more complicated when the remote end tears down the SSL connection before QUIT) This is not allowed. Per the paragraph you cite above the client MUST send a QUIT command. Tangentially, in the context of RFC 5321, it's not clear to me what the ramifications of not sending a QUIT could be. If the receiver acknowledged the . at the end of DATA with 250 OK, it has accepted the message. So there's not much that can be done about that. Refusing to talk to that sender in future is likely acceptable though. It does sound like you are arguing for dropping QUIT altogether, but the protocol was designed for robustness, and there is a reason for the general use of COMMAND/ACKNOWLEGEMENT. It sounds to me like Bill is merely arguing for the correct interpretation of the RFC 2119 SHOULD. However, he is missing that earlier in the same RFC we see.. (Notice the MUST NOT, which over reaches the later SHOULD) 3.8. Terminating Sessions and Connections An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code, after which it closes the connection. An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except: o After receiving a QUIT command and responding with a 221 reply. I read "server" as "receiver" here, in light of the first bullet point. I don't see this MUST NOT applying to the client/sender in any way. Having written all that though, RFC 2119 clearly states that an implementation must be prepared to accept the consequences of ignoring a SHOULD. In this context, a receiver choosing to treat a sender with suspicion for ignoring that SHOULD is perfectly germane. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On 2021-11-29 3:20 p.m., Bill Cole via mailop wrote: On 2021-11-29 at 16:57:54 UTC-0500 (Mon, 29 Nov 2021 13:57:54 -0800) Michael Peddemors via mailop is rumored to have said: On 2021-11-29 6:57 a.m., Larry M. Smith via mailop wrote: On 11/24/2021, Michael Peddemors via mailop wrote: CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR = mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT kernel Returning 250 ok [qp 3539411] for data QUIT command received, args: And then it terminates the connection, SSL collapses, without waiting for the remote mail server to acknowledge the QUIT. I get it that they 'might' think that closing when 'they are done' and we gave a 250ok on the DATA, and they sent the QUIT.. I don't know, thinking to shave a few milliseconds off of the connection, but the RFC is pretty clear that a QUIT .. AND .. and acknowlegement is part of RFC. Comments? (And no, there is zero lag before they terminate) If I understand you correctly; When sending mail, *.outbound.protection.outlook.com appears to send DATA, terminate via ., wait for a response, then issue QUIT immediately followed by a TCP FIN packet. Operationally, I don't think it makes a difference. RFC pedantics? Maybe. Does the receiving system advertise the Pipelining SMTP Service Extension?.. Does setting/un-setting that response to EHLO make a difference to outlook.com's behavior? If so, does and/or should RFC2920 allow for QUIT->TCP FIN? No, Pipeline is not advertised, the RFC's say that when you send a command, if you are NOT using pipelining, you need to wait for a response, and that includes the QUIT.. wait for the receiving system to send an OK in this respect, not only does it satisfy RFC's but also helps differentiate from the many spamming systems that terminate as quickly as they can to reduce overhead when spamming. Review the precise wording of https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.10 SHOULD in RFCs is stronger than it is in casual use, but it is still SHOULD, not MUST. SMTP clients of all sorts have done this (and worse, e.g. just FIN after getting a 250 at end-of-data) for at least 3 decades. I don't see how it could possibly be useful at this late date to try to enforce that SHOULD which only exists for a human sense of elegance and tradition. The "polite" pattern doesn't serve any functional purpose at QUIT, because there's no ambiguity for either side if the reply is simply lost. Even if QUIT is never sent and the client just sends a FIN packet after its last message is acknowledged, the only ambuiguity is that the server doesn't know whether the client failed in some way or was just finished sending messages, and that's not something a server should usually care about. For anyone not familiar with the passage.. Bill is 'technically' correct on this point.. 4.1.1.10. QUIT (QUIT) This command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel. The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command, and it SHOULD wait until it receives the reply (even if there was an error response to a previous command). (And yes Bill, we do see the odd system sending a FIN without even a QUIT, and it is more complicated when the remote end tears down the SSL connection before QUIT) It does sound like you are arguing for dropping QUIT altogether, but the protocol was designed for robustness, and there is a reason for the general use of COMMAND/ACKNOWLEGEMENT. However, he is missing that earlier in the same RFC we see.. (Notice the MUST NOT, which over reaches the later SHOULD) 3.8. Terminating Sessions and Connections An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code, after which it closes the connection. An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except: o After receiving a QUIT command and responding with a 221 reply. o After detecting the need to shut down the SMTP service and returning a 421 response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued). o After a timeout, as specified in Section 4.5.3.2, occurs waiting for the client to send a command or data. In particular, a server that closes connections in response to -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagi
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On 2021-11-29 at 16:57:54 UTC-0500 (Mon, 29 Nov 2021 13:57:54 -0800) Michael Peddemors via mailop is rumored to have said: On 2021-11-29 6:57 a.m., Larry M. Smith via mailop wrote: On 11/24/2021, Michael Peddemors via mailop wrote: CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR = mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT kernel Returning 250 ok [qp 3539411] for data QUIT command received, args: And then it terminates the connection, SSL collapses, without waiting for the remote mail server to acknowledge the QUIT. I get it that they 'might' think that closing when 'they are done' and we gave a 250ok on the DATA, and they sent the QUIT.. I don't know, thinking to shave a few milliseconds off of the connection, but the RFC is pretty clear that a QUIT .. AND .. and acknowlegement is part of RFC. Comments? (And no, there is zero lag before they terminate) If I understand you correctly; When sending mail, *.outbound.protection.outlook.com appears to send DATA, terminate via ., wait for a response, then issue QUIT immediately followed by a TCP FIN packet. Operationally, I don't think it makes a difference. RFC pedantics? Maybe. Does the receiving system advertise the Pipelining SMTP Service Extension?.. Does setting/un-setting that response to EHLO make a difference to outlook.com's behavior? If so, does and/or should RFC2920 allow for QUIT->TCP FIN? No, Pipeline is not advertised, the RFC's say that when you send a command, if you are NOT using pipelining, you need to wait for a response, and that includes the QUIT.. wait for the receiving system to send an OK in this respect, not only does it satisfy RFC's but also helps differentiate from the many spamming systems that terminate as quickly as they can to reduce overhead when spamming. Review the precise wording of https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.10 SHOULD in RFCs is stronger than it is in casual use, but it is still SHOULD, not MUST. SMTP clients of all sorts have done this (and worse, e.g. just FIN after getting a 250 at end-of-data) for at least 3 decades. I don't see how it could possibly be useful at this late date to try to enforce that SHOULD which only exists for a human sense of elegance and tradition. The "polite" pattern doesn't serve any functional purpose at QUIT, because there's no ambiguity for either side if the reply is simply lost. Even if QUIT is never sent and the client just sends a FIN packet after its last message is acknowledged, the only ambuiguity is that the server doesn't know whether the client failed in some way or was just finished sending messages, and that's not something a server should usually care about. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On 2021-11-29 6:57 a.m., Larry M. Smith via mailop wrote: On 11/24/2021, Michael Peddemors via mailop wrote: CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR = mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT kernel Returning 250 ok [qp 3539411] for data QUIT command received, args: And then it terminates the connection, SSL collapses, without waiting for the remote mail server to acknowledge the QUIT. I get it that they 'might' think that closing when 'they are done' and we gave a 250ok on the DATA, and they sent the QUIT.. I don't know, thinking to shave a few milliseconds off of the connection, but the RFC is pretty clear that a QUIT .. AND .. and acknowlegement is part of RFC. Comments? (And no, there is zero lag before they terminate) If I understand you correctly; When sending mail, *.outbound.protection.outlook.com appears to send DATA, terminate via ., wait for a response, then issue QUIT immediately followed by a TCP FIN packet. Operationally, I don't think it makes a difference. RFC pedantics? Maybe. Does the receiving system advertise the Pipelining SMTP Service Extension?.. Does setting/un-setting that response to EHLO make a difference to outlook.com's behavior? If so, does and/or should RFC2920 allow for QUIT->TCP FIN? No, Pipeline is not advertised, the RFC's say that when you send a command, if you are NOT using pipelining, you need to wait for a response, and that includes the QUIT.. wait for the receiving system to send an OK in this respect, not only does it satisfy RFC's but also helps differentiate from the many spamming systems that terminate as quickly as they can to reduce overhead when spamming. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On 11/24/2021, Michael Peddemors via mailop wrote: CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR = mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT kernel Returning 250 ok [qp 3539411] for data QUIT command received, args: And then it terminates the connection, SSL collapses, without waiting for the remote mail server to acknowledge the QUIT. I get it that they 'might' think that closing when 'they are done' and we gave a 250ok on the DATA, and they sent the QUIT.. I don't know, thinking to shave a few milliseconds off of the connection, but the RFC is pretty clear that a QUIT .. AND .. and acknowlegement is part of RFC. Comments? (And no, there is zero lag before they terminate) If I understand you correctly; When sending mail, *.outbound.protection.outlook.com appears to send DATA, terminate via ., wait for a response, then issue QUIT immediately followed by a TCP FIN packet. Operationally, I don't think it makes a difference. RFC pedantics? Maybe. Does the receiving system advertise the Pipelining SMTP Service Extension?.. Does setting/un-setting that response to EHLO make a difference to outlook.com's behavior? If so, does and/or should RFC2920 allow for QUIT->TCP FIN? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
I am not criticizing qmail for this behaviour. If you need another example: The Postfix smtp(8) client normally does not wait for the server's reply to the QUIT command, and it never waits for the TCP final handshake to complete. So now you have two people, who know that they are doing, having implemented the same behaviour. That's why I suggested the RFC should probably be changed (AFAICT there is currently work on a new revision?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
Umm.. not helpful, and if you are going to make inflammatory remarks, please sign it with your name.. Really isn't fair to call out Qmail, Dan Bernstein did an incredible amount of good in his day, and what version of Qmail are you using? Tell me if you see this happening in your logs, and if you do, go ahead and fix Qmail, it's open source... But in all honesty, comparing Qmail of 20 years ago, and a Multi billion dollar company.. Anyways, rest my case.. otherwise this turns into a flame war.. Just a really unproductive comment.. and completely out of line. On Thu, 25 Nov 2021 04:51:05 + ml+mailop--- via mailop wrote: > On Wed, Nov 24, 2021, Michael Peddemors via mailop wrote: > >> And then it terminates the connection, SSL collapses, without waiting for >> the remote mail server to acknowledge the QUIT. > > Just like qmail? > > Maybe it's time to change the RFC? > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On Wed, Nov 24, 2021, Michael Peddemors via mailop wrote: > And then it terminates the connection, SSL collapses, without waiting for > the remote mail server to acknowledge the QUIT. Just like qmail? Maybe it's time to change the RFC? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR = mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT kernel Returning 250 ok [qp 3539411] for data QUIT command received, args: And then it terminates the connection, SSL collapses, without waiting for the remote mail server to acknowledge the QUIT. I get it that they 'might' think that closing when 'they are done' and we gave a 250ok on the DATA, and they sent the QUIT.. I don't know, thinking to shave a few milliseconds off of the connection, but the RFC is pretty clear that a QUIT .. AND .. and acknowlegement is part of RFC. Comments? (And no, there is zero lag before they terminate) -- Michael -- -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
