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
