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.

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

WebAPI / Incoming webhooks - missing ContentDisposition in Structure #258

Open
morki opened this issue Dec 3, 2024 · 2 comments
Open

WebAPI / Incoming webhooks - missing ContentDisposition in Structure #258

morki opened this issue Dec 3, 2024 · 2 comments

Comments

@morki
Copy link

morki commented Dec 3, 2024

Hey @mjl- ,

thank you again for such a great project. I have some trouble with using incoming webhooks for our system.
Specifically we are missing ContentDisposition and ContentDispositionParams fields to construct representation of email with attachments for our delivery queue. Is it possible to add those please?

https://pkg.go.dev/github.com/mjl-/[email protected]/webhook#Structure

Desired state

type Structure struct {
        ....
	ContentDisposition       string            // Lower case (nullable), e.g. attachment 
	ContentDispositionParams map[string]string // Lower case keys, original case values, e.g. {"filename": test.pdf"}.
}
@mjl-
Copy link
Owner

mjl- commented Dec 4, 2024

Hi @morki! Yeah, this makes sense. I'll look into adding it soonish.

mjl- added a commit that referenced this issue Dec 6, 2024
for each message part. The ContentDisposition value is the base value without
header key/value parameters. the Filename field is the likely filename of the
part. the different email clients encode filenames differently. there is a
standard mime mechanism from rfc 2231. and there is the q/b-word-encoding from
rfc 2047. instead of letting users of the webhook api deal with those
differences, we provide just the parsed filename.

for issue #258 by morki, thanks for reporting!
@mjl-
Copy link
Owner

mjl- commented Dec 6, 2024

@morki the commit above adds the ContentDisposition word ("attachment", "inline"), and instead of the ContentDispositionParams, it adds a "Filename" field. this is due to differences in where email clients put the filename, and in which encoding. could you see if this works for you?

See https://www.xmox.nl/b/#42793834f8b6112a40e0ee9508c40c6e1798d23d for a binary with this commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants