Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFC8621 nonconformance #67

Open
sftse opened this issue Dec 5, 2023 · 1 comment · May be fixed by #68
Open

RFC8621 nonconformance #67

sftse opened this issue Dec 5, 2023 · 1 comment · May be fixed by #68

Comments

@sftse
Copy link
Contributor

sftse commented Dec 5, 2023

When parsing the example legacy/034.eml the returned parts are

html_body: [3, 4, 5], text_body: [2, 4, 5], attachments: [4, 5]

This seems at odds with RFC8621

o attachments: "EmailBodyPart[]" (immutable)

  A list, traversing depth-first, of all parts in "bodyStructure"
  that satisfy either of the following conditions:

  *  not of type "multipart/*" and not included in "textBody" or
     "htmlBody"

  *  of type "image/*", "audio/*", or "video/*" and not in both
     "textBody" and "htmlBody"

  None of these parts include subParts, including "message/*" types.
  Attached messages may be fetched using the "Email/parse" method
  and the "blobId".

  Note that a "text/html" body part [[HTML](https://datatracker.ietf.org/doc/html/rfc8621#ref-HTML)] may reference image parts
  in attachments by using "cid:" links to reference the Content-Id,
  as defined in [[RFC2392](https://datatracker.ietf.org/doc/html/rfc2392)], or by referencing the Content-Location.

Attachments 4, 5 are image/png and fit neither of the criteria listed.
@sftse
Copy link
Contributor Author

sftse commented Dec 6, 2023 •
edited

I'm not sure why the RFC includes the second criterion though. Prior to that, the criteria for textBody and htmlBody are

o textBody: "EmailBodyPart[]" (immutable)

  A list of "text/plain", "text/html", "image/*", "audio/*", and/or
  "video/*" parts to display (sequentially) as the message body,
  with a preference for "text/plain" when alternative versions are
  available.

o htmlBody: "EmailBodyPart[]" (immutable)

  A list of "text/plain", "text/html", "image/*", "audio/*", and/or
  "video/*" parts to display (sequentially) as the message body,
  with a preference for "text/html" when alternative versions are
  available.

This seems to suggest image/*, audio/* and video/* are always in both textBody and htmlBody, so the second condition for something being an attachment would always be false.

@sftse sftse linked a pull request Dec 6, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rfc8621 conformance fix sftse/mail-parser
1 participant
@sftse