search

purebred-mua / purebred-email

A fast email parsing library implemented in Haskell
https://hackage.haskell.org/package/purebred-email
GNU Affero General Public License v3.0
23 stars 4 forks source link

Some systems don't emit micalg for multipart/signed #72

Open tomjaguarpaw opened 2 years ago

tomjaguarpaw commented 2 years ago

Sadly I have another non-conformance to report. Some of my archive has Content-Type multipart/signed but does not provide micalg. Specifically, it looks like this

Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary=CUT-HERE-9527180438960725810

That is non-conformant according to RFC 1847 but it would be helpful to deal with these nonetheless.

tomjaguarpaw commented 2 years ago

(I have reported this upstream to the faulty system)

frasertweedale commented 2 years ago

@tomjaguarpaw thanks for the report. Are you able to advise what program produces these messages, and how it expects recipients to process this message (perhaps if it does verification itself, the parameters are hardcoded?)

I'm curious to know, because it will help to decide how (or whether) we should deal with this situation in purebred-email.

tomjaguarpaw commented 2 years ago

They are (automated) sales invoices from my ISP intended for a human to read. I suspect they expect the recipient's mail client to verify the PGP signature (if the client is configured to do so).

frasertweedale commented 2 years ago

@tomjaguarpaw thanks for the additional info.

I'm not really sure how best to proceed. Unlike some other deviations from spec we have dealt with, lack of micalg really does put the verifier in a difficult position. There is no default, thus no general way to recover from this situation - how to handle it would be specific to the producer. Therefore I'm leaning towards not fixing this in the parser.

It might be worth thinking about tools for fixing up non-conformant messages - "on the fly" or for writing to the mail store (persisting the repaired message). In this case the fixup might be to write the micalg parameter, or it might be to unwrap the signature. But let me know what you think.

tomjaguarpaw commented 2 years ago

My mail client (Mutt) does successfully recover from the situation and validates the signature. I'm not sure how it does that. Perhaps the MIC algorithm is specified in the PGP signature itself.

On the other hand, I don't desperately need to be able to parse these files and I can understand your rationale for not wanting to support too many non-conformant message types.

frasertweedale commented 2 years ago

OK let me look into the structure of PGPMIME signature payloads a bit further. I will decide one way or another before the next major version because it will be an API breaking change to the Signed constructor to make the micalg parameter optional.

tomjaguarpaw commented 2 years ago

it will be an API breaking change to the Signed constructor to make the micalg parameter optional

Yes, I can see it is pragmatically a difficult decision to make. One doesn't want purebred users to be able to create malformed messages!

(My ISP has now fixed the issue on their end anyway)