In ZoneMTA when encountering a multiline response I remove response codes from all lines beside the first one and join resulting lines with spaces. So a bounce email sent to the return path might look like this:
— Delivery to the following recipient failed permanently: andris.rein...@gmail.com <mailto:andris.rein...@gmail.com> Technical details of permanent failure: 550-5.7.1 [217.146.68.196 11] Our system has detected that this message is not RFC 5322 compliant: 'From' header is missing. To reduce the amount of spam sent to Gmail, this message has been blocked. Please visit https://support.google.com/mail/?p=RfcMessageNonCompliant <https://support.google.com/mail/?p=RfcMessageNonCompliant> and review RFC 5322 specifications for more information. a6si2605892lfk.371 - gsmtp — Andris Reinman ZoneMTA / WildDuck IMAP https://github.com/zone-eu/zone-mta <https://github.com/zone-eu/zone-mta> https://github.com/wildduck-email/wildduck <https://github.com/wildduck-email/wildduck> > On 10. juuli 2017, at 22:10, Brandon Long via mailop <mailop@mailop.org> > wrote: > > Humans also don't universally understand English, much less technical > responses. And the smtp reply codes and extended status codes don't do a > great job of mapping to what an end user can actually do about the bounce. > We currently classify the bounce into about 10 different categories based > largely on the most common "human" responses we see, and translate that into > a couple dozen languages, and its still not clear that its that much more > helpful than "your recipient didn't get the mail, sorry". > > And removing the prefix from the following lines when showing the error to > humans makes a lot of sense. Assuming the person reading it is doing so in a > fixed width font is pretty silly in this day. > > We went back and forth with Apple about how are errors should be formatted, > mostly for MSA which is often shown directly to humans in their mail client. > We ended up always including a space after any line break to ensure that it > works whether the client replaces newlines with spaces or not. Ditto for > including spaces around URLs so they're easier to extract and make clickable. > > So, yes, to the original poster, the RFCs are not clear on how to handle > unwrapping, there is no consistency. To the responders, yes the RFC doesn't > talk about unwrapping at all, but there are many cases where unwrapping makes > it much easier to read for end users. Replacing newlines with space is > probably the best you can do, or space collapse and then add a space. > > Brandon > > On Mon, Jul 10, 2017 at 12:58 AM, David Hofstee <opentext.dhofs...@gmail.com > <mailto:opentext.dhofs...@gmail.com>> wrote: > > How is https://tools.ietf.org/html/rfc5321#section-4.2 > > <https://tools.ietf.org/html/rfc5321#section-4.2> ambiguous? > - The handling for the SMTP server is NOT ambiguous. > - The handling for the human is NOT ambiguous. Just read the text. However, > most humans do not read from the wire. They use log files or other methods. > Which leads to #3. > - The handling for automated systems, forwarding the 'text' to another > system, is ambiguous. Should it include newlines and/or codes? The creation > of a DSN is one example. A logfile a second (should there be a newline in the > logfile, breaking simple parsing scripts?). An automated bounce handler is a > third example. > > I would actually say that, since the reply text can be included in a DSN, it > should be clearer. It is not just humans that this is intended for. > > Yours, > > > David > > > On 7 July 2017 at 18:44, Bill Cole <mailop-20160...@billmail.scconsult.com > <mailto:mailop-20160...@billmail.scconsult.com>> wrote: > On 7 Jul 2017, at 6:28, David Hofstee wrote: > > But it is a bit weird to say the human-readable text is for humans only. > > We appear to use conflicting definitions of the word "weird." > > Since it is transferred via SMTP, the RFC should define how to handle it. > > No. Message headers & body data are also transferred via SMTP, and the SMTP > RFC series does not define how those are handled either. This is by > intentional design. > > And it is ambiguous. I would like option 1 best. > > How is https://tools.ietf.org/html/rfc5321#section-4.2 > <https://tools.ietf.org/html/rfc5321#section-4.2> ambiguous? > > > _______________________________________________ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop> > > > > -- > -- > My opinion is mine. > > _______________________________________________ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop> > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
