On Mon, Oct 17, 2022 at 10:43 PM Grant Taylor via mailop <mailop@mailop.org> wrote:
> On 10/17/22 10:17 PM, Brandon Long via mailop wrote: > > Right, but you can't stick a non-compliant message into a DSN > > directly and have that be a compliant message... so you either make > > the non-compliant message compliant when you stick it into the DSN, > > or you figure that a sender who sends a non-compliant message can > > handle a non-compliant response. > > Are you talking about the 3rd and optional part of RFC standard Delivery > Status Notifications, a.k.a. Bounces? -- I'm going to assume yes until > corrected. > Yes. First, the message that caused the ""bounce is optional. > Note that if Gmail can't find the message-id of the bounce message and correlate that to a message in the receiver's mailbox, it will likely mark the bounce message as spam. We would highly recommend folks include the original message or headers in their bounce messages, and just about everyone does. Second, why would you send the entire message (message/rfc822) in the > DSN? There's too good a chance that you inadvertently send (as in > originate a permutation of) -- at best -- questionable content. I'd > think that you would want to only send the headers (text/rfc822-headers). > Like I said, if the bounce receiver didn't send it, we'll mark it as spam anyways. And bounce messages are already hard enough for customers to understand, so including the original helps them understand what bounced. Anyways, I think we do fall back to headers-only in some cases like very large messages... and sometimes to message/global depending. Another use case, where the DKIM thing is useful, is for ARF reporting (rfc5965), and there the third part is required. Or are you talking about a completely new message that is a stand in for > an RFC standard DSN but looks completely different? > > Either way, I see no reason to worry about altering the message. Send a > sub-set of it (which is often sufficient to identify the original > message) or don't send it. Either way, there's not enough to worry with > DKIM validation of what was received by the mail system generating the DSN. > > > And while this particular case of re-wrapping lines is fairly easy > > to fixup when generating the DSN, > > }:-) > > > other cases like embedded non-utf8 8bit characters are more > > complicated... just auto-detect the language, convert to utf8 and > > embed in a message/global, I'm sure their system will know what to > > do with that ;) > > I would snarkily reply add the original message as a message/rfc822 > attachment that is base64 encoded. Except Google has a propensity of > disliking message/rfc822. -- For the longest time Gmail didn't support > it. > We used to do this (or rather, just let the regular cte encoding logic choose, which included using quoted-printable for too long lines)... but it turns out that while a bunch of parsers support decoding it even though it's against the rfc, many do not. As for supporting message/rfc822 attachments, we had some issues where a very loud subset of early customers preferred it being a download link instead of displayed inline, and it took some time to convince PM to override that... I think it still may listen to the Content-Disposition header whether to show inline or not. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
