US Phone company mail servers are reporting email sent with MailKit contains bare CR

[Saurbaum]

Describe the bug Phone company mail servers are reporting email sent with MailKit contains bare CR 552 5.2.0 Message contains bare CR and is violating 822.bis section 2.3

Platform (please complete the following information):

• OS: Windows
• .NET Runtime: CoreCLR
• .NET Framework: .NET 4.5
• MailKit Version: 4.2.0

To Reproduce I personally have not managed to reproduce this using any of the mail servers I have access to but my protocol log looks the same as the logs I was sent.

I'm filling in my message and checking in notepad++ that it looks like this

and when I check the protocol log I see this which definitely looks like CR without a trailing LF

Protocol Logs SMTP Protocol Log Filename.txt

Additional context This appears to be specific to mail recipients using xxxxxxxxxx.vtext (where xxx.. is their phone number and .vtext is for Verizon phones) and when the same user changes to a normal email address this appears to work.

There has been a suggestion that the major phone carriers (ATT,Verizon) have tightened up the rules for message sending but I'm on the wrong side of the Atlantic to be able to check this directly.

[jstedfast]

Not sure if the above commit fixes this (sorta seems like it shouldn't?), but it's the only issue I could find.

[jstedfast]

Ok, so this is likely to either be a bug in MimeKit's Unix2DosFilter -or- MailKit's SmtpDataFilter.

Not sure which (if either) the bug exists in :-\

If it's not in either of those, not sure where it could be...

[jstedfast]

Would it be possible to attach the original text/plain and text/html content files? Those might help me diagnose this a bit.

[jstedfast]

Wrote up a quick unit test based on your protocol log to construct the exact same MimeMessage and then piped it through to a MemoryStream backed SmtpStream the same exact way that SmtpClient sends the message in the DATA command, but no luck reproducing (even without the Unix2Dos filter changes).

I'm at a loss to reproduce this issue...

[Saurbaum]

I'll see what I can dig out on Monday when I'm in the office.

On Fri, 9 Feb 2024, 22:30 Jeffrey Stedfast, @.***> wrote:

Wrote up a quick unit test based on your protocol log to construct the exact same MimeMessage and then piped it through to a MemoryStream backed SmtpStream the same exact way that SmtpClient sends the message in the DATA command, but no luck reproducing (even without the Unix2Dos filter changes).

I'm at a loss to reproduce this issue...

— Reply to this email directly, view it on GitHub https://github.com/jstedfast/MimeKit/issues/1004#issuecomment-1936688639, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXTQEBM6WZ3D4DKNNZQ3WLYS2PPTAVCNFSM6AAAAABDCAUQLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWGY4DQNRTHE . You are receiving this because you authored the thread.Message ID: @.***>

[Saurbaum]

Welp this is utterly weird. Problem is definitely my end and not in [Mail/Mime]Kit.

If I inspect the strings in the debugger they are showing CRLF as expected. As soon as I dump them out to a file they revel their true colours.

[jstedfast]

But that still doesn't explain why carriers are saying your emails contain bare carriage returns right? Or am I confused?

[Saurbaum]

It seems I had in the HTML formatting some lines ending in LFCR. That seemingly would be processed into

LF CR And I think looking at the way it would convert the HTML into a plain text version it would end up with a series of LFCR at the start of the message which the viewer in Visual Studio was than trying to make human readable and not showing the actual data. So the email message absolutely does have a bare CR in it because its companion LF is on the previous line. Making it harder to spot in my data was that when you have a chain of several together they look much more normal. LF CRLF CRLF CR