If it's crypto padding surely it has to be a normatively specified value to
allow checksums to work? So this would be documented.

I think it's more likely to be an off by one picking up C string terminal
byte or initialised alloc() space. Uninitialised would be random.

G

On Fri, 7 Nov 2025, 7:40 am Ken Hornstein, <[email protected]> wrote:

> >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
>
>

Reply via email to