April 2, 2024 6:00 PM, "Tassilo Philipp" <tphil...@potion-studios.com> wrote:
> Hi, > > Find attached the first stab at a final patch making generated bounce mails > follow more closely the > RFCs 3461, 3464 and 6522. The attached file includes the patch from my > previous mail in this > thread. > > The patch is based on opensmtp 7.5.0rc1 (w/ the additional patch in the rc1 > announcement thread on > this ml). > > It does, in short: > > - uses the correct content type(s) for DSNs, as specified in RFC3464 and > RFC6522 > > - adds xtext_decode() utility func (following the style/interface of the > base64_decode() utility func) > > - extends the data structures of the bounce message and envelope, as > necesary, to write the required fields outlined by RFC3461 and RFC3464 > into the machine readable sub mime part, namely, per-message field: > > * Original-Envelope-Id: (required if ENVID= was used, see RFC3461) > > and per recipiend fields: > > * Original-Recipient: (required if ORCPT= was used, see RFC3461) > * Arrival-Date: (optional, but added it while at it...) > * Diagnostic-Code: (optional, but added it while at it...) > > - adds a check whether the SMTP ENVID= param is valid xtext (RFC3461) > > - minor: removes a space in already set Final-Recipient: field > (following more closely the example layout from RFC3464) > > One thing I wasn't sure about what to do is *where* to handle the xtext > decoding of the ENVID= and > ORCPT= SMTP params. Right now the SMTP handling part just considers them > "opaque text", as they are > just handed down the relays, unmodified. When copying those into a DSN, they > must be decoded, > though, and the decoded result is considered being printable US-ASCII. >From > RFC3461 4.2 about > ORCPT: > > `Due to limitations in the Delivery Status Notification format, the > value of the original recipient address prior to encoding as "xtext" > MUST consist entirely of printable (graphic and white space) > characters from the US-ASCII repertoire.` > > A functional identical wording is used in 4.4 for the ENVID= param. > > The attached patch keeps the SMTP behaviour to just treat those params as > opaque strings, but > checks if the decoded part is US-ASCII when generating a bounce - and if it's > not, doesn't write it > to the respective DSN field(s). > > I think the SMTP handling might be the better place to check for that, and > refuse such SMTP params > outright, maybe? > > Thanks > Can you please inline the diff to your mail ?
