In POP3, what is the expected first response line to a RETR command? - pop3

I'm learning about POP3 by reading RFC 1939.
The description of the RETR command says the following:
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
What does "120 octets" refer to? Is this optional information about the message that may or may not be included, and if so, is "message follows" not required (as specified under "Possible Responses")?

What does "120 octets" refer to? Is this optional information about the message that may or may not be included
Correct, the "120 octets" is optional informational text but is not required text nor can the number of octets be used as definitive for calculating the end of the message data.
and if so, is "message follows" not required (as specified under "Possible Responses")?
That's why it was stated to be a "possible response" ;-)
Basically, all you can really use from that first line is the first token which will be "+OK" or "-ERR". Everything after that is informational text that may be a helpful when debugging, but not guaranteed to be useful for your code to try and interpret.
I would argue that if it is of the form "# octets", you might be able to use it to show progress as you read data, but that's about the best you can do.
Even so, I would probably recommend using the octet value from the LIST command instead.

Related

JPOS Message header length and message body length mismatch

Would like to check if there is an way to validate resolve the services for jpos if the message header indicate the length as 100 however the sent length is 99? Currently when i received the message from my client end it would required to restart if not the sequence message would fail.
Thank you in advance.
Such a message is malformed an should be rejected. It expect most operators would flag this because its an indication of a major software fault somewhere along the line.

OpenNMS events varbinds decode always showing the raw value between (parentheses)

Is there a way to hide the raw value from a varbind that was decoded?
What I'm getting is:
deviceNotification trap received deviceRuleCode=browserOffline(7) notifObjType=trigger(1) notifObjSeverity=critical(6)
What i want is:
deviceNotification trap received deviceRuleCode=browserOffline notifObjType=trigger notifObjSeverity=critical
Obviously I'm passing the decoded varbinds parm[#] to the log message and/or description.
Any clue? Is it even supported?
After check the code, I've concluded that this is not supported.
The proof is here:
https://github.com/OpenNMS/opennms/blob/develop/features/events/daemon/src/main/java/org/opennms/netmgt/eventd/processor/expandable/ExpandableParameter.java#L75-L77
The token having the decoded value is always appended with the original value:
(...)
ret.append(decode.get(token).get(value));
ret.append("(");
ret.append(value);
ret.append(")");
(...)
.. and this happens for all the expanded values.

How can sign a transaction on an EMV contactless card?

I read here that EVM cards will sign some transaction data.
I would like to do this with my card, using my phone, and verify that the signature on the result is correct.
To start, I issued this command ("request APDU"):
00:A4:04:00:0E:32:50:41:59:2E:53:59:53:2E:44:44:46:30:31:00
One of the "Application IDs" was this:
A00000038410
So then I issued this command ("Select Payment application"):
00:A4:04:00:07:A0:00:00:00:03:10:10:00
and it returned this "Processing Options Data Object List (PDOL)":
9F66049F02069F37045F2A02
I read here how to decode this, because I couldn't find the official spec anywhere:
9F6604 - the tag 9f 66 represents the terminal transaction qualifiers
9F0206 - tag 9f 02 stands for authorized amount. The PDOL list must have the amount, authorized, coded into 6h bytes added to it.
9F3704 - tag 9f 37 stands for unpredictable number, thus encode such a number in 4 bytes and add it to the list
and here how to decode this:
5F2A02 - TX currency code
I understand the next step is to run "Get Processing Options" but this is where I got stuck. I tried:
80:A8:00:00:02:83:00:00
80:A8:00:00:12:83:10:01:02:03:04:05:06:07:08:01:02:03:04:05:06:07:08:00
80:A8:00:00:12:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
80:A8:00:00:02:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
All gave back a result of 6D:00 (Instruction code not programmed or invalid).
I tried looking in "emv book 3" and "emv book 4" but neither seem to contain the relevant information.
What do I need to do next in order to make a transaction, sign, and check the result?
Your GPO commands needs to provide the PDOL values requested by the card. The requested tags are:
9F66 - 4 bytes
9F02 - 6 bytes
9F37 - 4 bytes
5F2A - 2 bytes
So the commands needs to provide these in the same order, with expected lengths.
Assuming you want to send the following sample values:
9F66: 11223344
9F02: 112233445566
9F37: 11223344
5F2A: 1122
Your GPO command will look like this:
80A800001283101122334411223344556611223344112200
Where the PDOL data is 11223344112233445566112233441122.
Hope this helps
If PDOL found in response of select application, here you need to pass the value of PDOL tags in GPO command,
can find a very good article Here. hope it helps.

What is the correct SMPP error code to indicate corrupt/invalid UDH field values?

I'm trying to handle UDH data for multipart messages and I want to use an appropriate error code when there's a problem with the multipart fields. There are several error codes for bad TLV's, but I don't see anything except generic failure messages that I could use for UDH. Is that the best I can do here, or is there a more direct message I could use?
Your observation is correct - there is not a single error defined for UDH.
If you want, you can use error codes from reserved section and assign specific meaning to one/some of them. I think the "Reserved for SMSC vendor specific errors" (0x400-0x4FF) can be a good candidate.
Actually it looks to me like ESME_RX_R_APPN = 0x66 "ESME receiver reject message error." is the best error code to throw here.
It should correspond to a permanent error for this message only and let further messages be processed.

How to make Xlib print error message, but not exit?

"The action of the default handlers is to print an explanatory message and exit." (link)
Example of such message:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 12 (X_ConfigureWindow)
Resource id in failed request: 0xc0007a
Serial number of failed request: 140
Current serial number in output stream: 141
If I set (XSetErrorHandler) my own "ignore everything" error handler, the "explanatory messages" disappear.
How to make Xlib ignore errors, but still print error messages?
If you actually want those error messages you pretty much have two options:
Pull _XPrintDefaultError out of XlibInt.c along with some private headers (with all the caveats of using library-private definitions).
Redefine exit() not to actually exit when _XDefautError calls it.
Neither is especially pretty and both may break and reduce your portability, but they do work.
You have to format your own message. The contents of the message is the contents of the XErrorEvent struct:
http://tronche.com/gui/x/xlib/event-handling/protocol-errors/default-handlers.html