>Remember that time in early 2024 when I had NUL characters in my emails. >I guess it occuring again, and at least one MTA dislikes it. >Maybe it never went away. I got some suggestions then, but I think the >problem disappeared again before I could act on them... > >I have checked, it occurs on laptop (Ubuntu) and desktop (Devuan). >I am running self-built nmh from source code on each. > > (reason: 554 5.6.0 Message contains NUL characters)
I am kind of surprised that there is at least one MTA that complains! >And now today, many complaints... > >I thought it was related to doing either PGP/MIME signatures, or even PGP >clearsignatures. BUT, looking at my +outgoing box, it affects 41 of 130 >messages. Some of which are not PGP signed at all. OTH, I think that it >affects all messages which are PGP signed. >I've not found a way to reproduce this via just MH commands. > >I've replaced my "send" program on path with one that logs more stuff, but I >am not sure what else to debug now. I did this via overriding "mh-send-prog" > >dyas-[~](3.3.8) mcr 10229 %hexdump -C Mail/outgoing/104 >000002f0 65 79 38 63 6c 31 54 4b 63 34 69 4e 66 50 35 57 |ey8cl1TKc4iNfP5W| >00000300 47 68 41 3d 3d 0a 3d 52 57 50 30 0a 2d 2d 2d 2d |GhA==.=RWP0.----| >00000310 2d 45 4e 44 20 50 47 50 20 53 49 47 4e 41 54 55 |-END PGP SIGNATU| >00000320 52 45 2d 2d 2d 2d 2d 0a 00 00 00 00 00 00 00 00 |RE-----.........| I have to say that this sure looks like some kind of crypto padding, because it ends right on 16 byte boundary. But in your next message it doesn't, so maybe that isn't it. I guess what I would instrument would be: - What does the draft look like before send(1) gets it? send(1) will generally just take whatever you give it and shove it out on the wire, so I would be surprised if that was the failure point (but I've been surprised before!) - What the message looks like before and after GPG signs it. --Ken
