Google messages are simply wrapped at 76 chars, so "unfolding" is always right with their messages, but I've sees ascii arts in multiline responses too and if you remove newlines you break the art! :-)
OK, ignoring ascii arts, you'll still find messages like this one: 550-5.7.0 Message considered as spam or virus, rejected 550-5.7.0 Your IP: XXX.YYY.ZZZ.DDD 550-5.7.0 Mailhost: mailin65.aul.t-online.de 550-5.7.0 Timestamp: 2017-07-07T12:24:09Z 550-5.7.0 Expurgate-ID: 149288::1499430249-00001136-C1FAF5F8/22/str=0001.0A0C0207.595F7D69.01F2,ss=3,re=0.000,recu=0.000,reip=0.000,cl=3,cld=1,fgs=0 550-5.7.0 Authenticator: 7E730435A606B7427FDC506103C638DA63D6F8C615666BF27A0929A4DD946E180B8C423A 550-5.7.0 550-5.7.0 Your message has been rejected due to spam or virus classification. 550-5.7.0 If you feel this is inapplicable, please report the above error codes 550-5.7.0 back to *REDACTED* to help us fix possible misclassification. 550-5.7.0 We apologize for any inconvenience and thank you for your assistance! 550-5.7.0 550-5.7.0 Die Annahme Ihrer Nachricht wurde abgelehnt, da sie als Spam oder 550-5.7.0 Virus eingestuft wurde. Sollten Sie dies als unzutreffend ansehen, 550-5.7.0 senden Sie bitte obige Fehlercodes an *REDACTED*, damit wir 550-5.7.0 die Klassifizierung untersuchen koennen. Wir entschuldigen uns fuer 550 5.7.0 etwaige Unannehmlichkeiten und bedanken uns für Ihre Unterstuetzung! and removing the newlines will make it even harder to read. Or 550-Syntax error in email@address@address 550 ^ Where not only you are expected to preserve newlines, but also to use a monospaced font. BTW nowadays no one expect anyone but tech people to really read that "human readable" content... Otherwise let me know how much "human readable" is this microsoft error (it is not a multiline.. but it is very long and I don't know humans speaking that language): 554 5.2.2 mailbox full; STOREDRV.Deliver.Exception:QuotaExceededException.MapiExceptionShutoffQuotaExceeded; Failed to process message due to a permanent exception with message Cannot open mailbox /o=Messaging/ou=*REDACTED*/cn=*REDACTED*. 16.55847:7E000000, 17.43559:0000000058010000000000001F00000000000000, 20.52176:000FEF840500000000000000, 20.50032:000FEF847517000000000000, 255.23226:000FEF84, 255.27962:FE000000, 255.17082:DD040000, 0.26937:00000000, 4.21921:DD040000, 255.27962:FA000000, 255.1494:00000000, 0.50608:1A010480, 5.29818:0000000064326137626162342D393861382D343764632D613732362D36313363393835353362393100010480, 1.29920:03000000, 7.29828:014E4613000000001A010480, 7.29832:0000C012000000001A010480, 4.45884:DD040000, 4.29880:DD040000, 1.36108:03000000, 4.29888:DD040000, 1.56872:FE000000, 4.42712:DD040000, 5.10786:0000000031352E30302E313236332E3030303A45584331335453504D5231390005000780, 255.1750:00000000, 0.26849:0A000000, 255.21817:DD040000, 0.26297:000FEF84, 4.16585:DD040000, 0.32441:0E000000, 4.1706:DD040000, 0.24761:9C080000, 4.20665:DD040000, 0.25785:00000000, 4.29881:DD040000 [Stage: CreateSession] Stefano On 7 July 2017 at 15:07, Maarten Oelering <maar...@postmastery.net> wrote: > Hi David, > > Given this example from an SMTP trace: > > 550-5.7.1 [X.X.X.X 18] Our system has detected that this message is > 550-5.7.1 likely suspicious due to the very low reputation of the sending IP > 550-5.7.1 address. To best protect our users from spam, the message has been > 550-5.7.1 blocked. Please visit > 550 5.7.1 https://support.google.com/mail/answer/188131 for more > information. w198si19789289wmd.1 - gsmtp > > I would log is as a single line, removing the folding and removing repeated > enhanced status codes: > > 550 5.7.1 [X.X.X.X 18] Our system has detected that this message is likely > suspicious due to the very low reputation of the sending IP address. To best > protect our users from spam, the message has been blocked. Please visit > https://support.google.com/mail/answer/188131 for more information. > w198si19789289wmd.1 - gsmtp > > Maarten Oelering > Postmastery > > On 7 Jul 2017, at 13:36, David Hofstee <opentext.dhofs...@gmail.com> wrote: > > And actually, this reply has to possibly be transferred to a DSN as well > (see https://tools.ietf.org/html/rfc3464#section-2.3.6 ). Those > diagnostic-code field values may be multiline as well, but I presume one > would leave the numeric codes out. > > @Stefano: Not sure if I have the time, but good tip on checking if it is a > bug or not. > > Yours, > > > David > > On 7 July 2017 at 12:28, David Hofstee <opentext.dhofs...@gmail.com> wrote: >> >> Yes, I know. The subsequent RFCs 2821 and 5321 are equally unclear on >> this, I think. >> >> But it is a bit weird to say the human-readable text is for humans only. >> Since it is transferred via SMTP, the RFC should define how to handle it. >> And it is ambiguous. I would like option 1 best. >> >> David >> >> On 7 July 2017 at 12:03, Vladimir Dubrovin <dubro...@corp.mail.ru> wrote: >>> >>> >>> Hello David. >>> >>> RFC 821 is outdated, use RFC 2821 as proposed or RFC 5321 as a draft for >>> SMTP. Also, there is an RFC 3463, it adds extended status codes and you >>> should probably read it. >>> >>> According to RFC, only code (and potentially extended status code) are >>> intended for machine interpretation. The rest of response is a >>> human-readable text, which should not be automatically interpreted. So, as a >>> human, you are absolutely free to use it in any reasonable way. You can >>> either leave it as is, or remove status codes, or concatenate it in the >>> single line (since it's a human readable form, you should probably replace >>> CRLF + status code + delimiter characters with a whitespace, because in >>> human-readable form you do not expect the words to be wrapped or the lines >>> to contain extra spaces). >>> >>> 07.07.2017 12:27, David Hofstee пишет: >>> >>> Hi, >>> >>> I've an interesting RFC question. In an SMTP reply, one can have single >>> line or multiline replies. E.g. >>> >>> 521 single line reply >>> >>> or >>> >>> 521-Line one >>> 521-Line two >>> 521 Line three >>> >>> See also https://tools.ietf.org/html/rfc821#page-50 . >>> >>> My question is: The reply is an answer that is, necessarily, formatted >>> for SMTP. But how should the multiline answer be interpreted? What is its >>> 'value'. >>> >>> option 1: Remove superfluous return codes and <CRLF>s. E.g.: >>> 521 Line oneLine twoLine three >>> >>> or option 2: Remove superfluous return codes but keep <CRLF>. E.g. >>> 521 Line one >>> Line two >>> Line three >>> >>> or option 3: Remove superfluous <CRLF>s. E.g. >>> 521-Line one521-Line two521 Line three >>> >>> or option 4: Convert <CRLF>s into '\r\n' to make it a one line answer. >>> E.g. >>> 521-Line one\r\n521-Line two\r\n521 Line three >>> >>> or option 5: Keep everything. Eg. >>> 521-Line one >>> 521-Line two >>> 521 Line three >>> >>> The RFC does not really state that. So I am not quite sure how that >>> should be logged correctly. Where the formatting starts and what 'value' it >>> is supposed to represent. When I look at other standards (e.g. >>> http://json.org), the formatting and what it is to represent, is more clear. >>> >>> This came up when I saw 3 different outputs in different MTA's (1,4 and >>> 5). Not sure if I have to file a bugreport to my favorite MTA supplier. >>> >>> Can anyone say something smart about how the reply should be seen? >>> >>> Yours, >>> >>> >>> >>> David >>> >>> >>> _______________________________________________ >>> mailop mailing list >>> mailop@mailop.org >>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >>> >>> >>> -- >>> Vladimir Dubrovin >>> @Mail.Ru >> >> >> >> >> -- >> -- >> My opinion is mine. > > > > > -- > -- > My opinion is mine. > _______________________________________________ > 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 > _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
