I know that using * in IMAP FETCH Command either defines all or one mail but does
"*:*" also defines all mails in the selected folder? Does it defines something else too? Asking cause my company is implementing its own IMAP server, and I couldn't find any reference to *:* in the RFC 3501 and 4466.
If possible, please also cite the RFC.
* does not mean all mail. As a number, * means "the last message in the folder". More generally, 42 means "message 42", 42:50 means "messages 42 to 50 inclusive", 42:* "messages 42 to the last one", and * means "the last message", see? *:* is another way to say "just the last message".
But *.* doesn't mean anything in particular. I can't think of any case where that is even syntactically valid.
: would mean just the last message. You can check for rfc 791. Check www.tools.ietf.org
Related
Interesting about how the server detect the end of client's message in https://www.rfc-editor.org/rfc/rfc4315
As I know multipart/mixed contains a lot of empty lines, it would be wrong using just CRLF.
Messages and similar multiline structures are preceded by a byte count.
> A1 APPEND INBOX {4082}\r\n
< + Go ahead\r\n
> (4082 bytes of message follow)\r\n
Simple as that.
1) Given my email, produced via a mailchimp online editor.
2) I go to my openEdX, log in as administrator of the MOOC. Then got to My MOOC > INSTRUCTOR > EMAILS, in order to send my email. First a test to myself, later to my 2000 mooc students.
3) The email I receive in my inbox is CUT HALF WAY. The bottom part is all missing.
QUESTION : What is going on there ? How to fix this ?
Look into your code for the first paragraph which disapeared. It's likely the buggy part.
For this case, I can see the first disappeared sentence is :
💡 Astuce : Pensez à inviter NudiMooc à suivre votre BLOG
My eyes are catched up by the strange 💡 sign, which is a rare unicode character.
Delete this exotic 💡 sign from your email / html5 code, and it will work again. I tested it by sending to myself. Horray ! The corrected code without the lightbulb was complete !! :D
OpenEdX processing may crash on this string. But because there are some witty security, the previous, valid text is kept.
My Docker syslog tags are being truncated at what seems to be 32 characters. When I look at RFC 5424 I am not sure which field it is. Anyone know? I am trying to verify the allowed length the tag can be.
Apr 19 06:43:05 ord-nodecore-prd-01 docker/core_sql_event_processor_ha[1207]: 2016-04-19T06:43:05.265Z [sqlEventHandler] Event '3c5e1a15-f8a1-4bfa-b2fa-2e54b2a5fbaa' resulted in 0 relevant application events
Becomes:
<30>Apr 19 06:43:05 ord-nodecore-prd-01 docker/core_sql_event_processor_ 2016-04-19T06:43:05.265Z [sqlEventHandler] Event '3c5e1a15-f8a1-4bfa-b2fa-2e54b2a5fbaa' resulted in 0 relevant application events
Note the tag, docker/core_sql_event_processor_ha[1207]:
Here is the RFC link: https://www.rfc-editor.org/rfc/rfc5424#page-9
I am thinking it is the 'SD-Name' but it may be 'APP-Name'. No idea.
Your example has nothing to do with RFC5424, and looks more like RFC3164 (which is not a standard, but a collection of older best practices).
Please read this: https://www.rfc-editor.org/rfc/rfc5424#appendix-A.1
then search for 'TAG ' - in essence, RFC5424 does not have a TAG field as such.
I am not familiar with Docker logging, but if I read
https://docs.docker.com/engine/admin/logging/overview/#syslog-options
, then check syslog-format - it seems that the format can be specified, also to be like rfc5424micro which I would recommend, but seems like in your case it is not configured like that.
I have to send HL7 message to web service. I am adding CHAR(13) (carriage return or \r) as segment terminator in stored procedure and calling a web service to send the HL7 message. When the service receives the message they are saying I am adding extra CHAR(10) (line feed or \n ) in my segment terminators. I have looked into my values and just before sending it only has \r as segment terminators. How to make sure that the service also receives it as only \r without extra \n. I have looked around but haven't found any solution so far.
Have you looked at the message in Fiddler or TCP Spy depending on how you are sending your message?
It will at least prove if you are providing anything other than the /r
I've been caught by messages having multiple ways of breaking the line. \r, \n and also a combo of the 2.
Have you tried redirecting the message to somewhere you can actually read yourself at different stages of the processing? It's getting changed somewhere and reading it out at different stages caught the error for me. Or just a series of the below at different stages.
content = hl7message.read()
if "\n" in content:
print "ERROR"
I have read the RFC1928 several times and still couldn't understand what a compliant SOCKS 5 server is supposed to reply in case of failure. This doubt comes from the fact that the ATYP, BND.ADDR and BND.PORT fields from a SOCKS reply simply don't make sense if, for instance, a request with an invalid command is received. Must the server not send these fields or just send blanks?
I just red putty source code, and found out that, when there is an error in reply (REP != 0) ATYP is IPv4 (1) BND.ADDR and BND.PORT are all NULL bytes.
I guess this behavior helps developpers to parse requests ?
In a failure reply, only the VER and REP fields are meaningful. The other fields may be present but are not used. You don't even need to look at those bytes unless REP is zero.