I'm developing a imap service for our company.
Below messages are the logs of communication between MS Outlook 2016 (Windows 10) and my IMAP server.
C: hj38 APPEND {13}/r/n
S: + /r/n
C: 한글폴더2
C: (\Seen \Answered) " 4-Jan-2017 16:42:14 +0900" {14402603}/r/n
The issue I have is {13}. The size of next message should be 13 bytes. But it is bigger than I expected... I'm sure it is more than 13 bytes.
한글폴더2\r\n(\Seen \Answered) " 4-Jan-2017 16:42:14 +0900" {14402603}\r\n
APPEND takes two mandatory and some optional arguments. In this command there are two optional arguments, so the arguments are, in order:
the mailbox name, a 13-byte literal
the list of flags, \seen \answered
the message date
the message content, a 14402603-byte literal.
Read page 46 of RFC 3501, and the following pages.
Related
I'm writing an api to an SMS receiving device and one of the fields I see is SCTS - Service Center Timestamp. I've sent an SMS to it at 15:26 UTC and I have the following SCTS: 22082211263196, so the time in this string is 11:26:31, i.e. UTC-4.
I can't make sense of the timezone offset - 96. It's supposed to be the number of quarter-hours + the sign. In binary this value translates to 1100000 so if the first 1 means minus, what remains is 100000 or 32 in decimal, i.e. 32/4 = 8, so UTC-8? Am I missing something? How do I get the correct timezone from SCTS?
I have an issue in being unable to recive the URC message from the modem whenever it receives an SMS.
I know that it receives them since i can find and read them if I use AT+CMGL but, i don't receive any notification when the modem gets them. I played around with the URC related commands but I've been unable to get it to work (other URCs work fine).
The modem is a BG600L M3 from Quectel and following is the sequence of commands i'm sending ("AT" is always omitted and the first command is literally "AT\r", basically an empty one).
//general config
AT\r
CFUN=1,0
E1
+QCFG=\"urc/ri/other\",\"pulse\",8,1
H0
&F
V1
+CMEE=1
&D0
E1
+CREG=2
+CGREG=2
+CEREG=2
//sms config
+CPMS=\"ME\",\"ME\",\"ME\"
+QINDCFG=\"smsincoming\",1
+CMGF=1
+CSDH=0
+CSCS=\"GSM\"
+CNMI=2,2,0,2,0
//doing some deleting and reading
+CMGD=1,3
+CPMS?
//getting the gps fix
+QGPS=1
+QGPSCFG=\"gnssconfig\",3
+QGPSLOC=1
+QGPSEND
//resetting the gms connection
+CFUN=0
+CFUN=1,0
//setting up the gsm connection
+QICFG=\"dataformat\",0,0
+QICFG=\"viewmode\",0
+QICFG=\"recvind\",1
+QICFG=\"tcp/retranscfg\",3,600
+QISDE=0
+QCFG=\"band\",0xf,0x80085,0x80085,1
+QCFG=\"nwscanmode\",1,1
+QCFG=\"nwscanseq\",010101,1
+QCFG=\"iotopmode\",2,1
// checking if it's connected
+CREG?
+QNWINFO
+COPS?
//Getting the time
+CTZU=3
+CTZR=0
+QLTS
+CCLK?
You can set AT+CNMI=2,1,2,0,0 , that should do the trick.
According to specification ETSI TS 127 005 V11.0.0 (2012-10)
+CNMI: <mode>,<mt>,<bm>,<ds>,<bfr>
by keeping <mt> value to 1 we should get indication when message is stored in ME/TA
<mt>: integer type (the rules for storing received SMs depend on its
data coding scheme
0 No SMS-DELIVER indications are routed to the TE.
1 If SMS-DELIVER is stored into ME/TA, indication of the memory location is routed to the TE using unsolicited result code:
+CMTI: <mem>,<index>
I have an application, where I send approx. 125 data items via a named pipe.
Each data item consists of data block 1 with max. 300 characters and data block 2 with max. 600 characters.
This gives 125 data items * (300 + 600) characters * 2 bytes per character = 125 * 900 * 2 = 225000 bytes.
Each data item is surrounded by curly braces like {Message1}{Message2}.
I noticed that if I send the messages, there are sending/receiving problems. Instead of {Message1}{Message2} the receiving application gets {Messa{Message2}.
Then I changed the sending code so that the messages are sent in 500 ms intervals. Then, the problem disappeared.
If I do everything correct (no bugs on my side, no misconfiguration of named pipes), how much time is required to send 225000 bytes over a named pipe from application in Delphi 2009 to application in .NET on the same machine?
What is a reasonable time for sending data of that size?
I have a procedure to send mail using utl_smtp.
What is the maximum mail body size that I can send and if my mail body size exceeds this limit, then how can I send it?
Just send it in chunks:
l_offset := 1;
l_amount := 1900;
utl_smtp.open_data(l_connection);
while l_offset < dbms_lob.getlength(l_body_html) loop
utl_smtp.write_data(l_connection,
dbms_lob.substr(l_body_html,l_amount,l_offset));
l_offset := l_offset + l_amount ;
l_amount := least(1900,dbms_lob.getlength(l_body_html) - l_amount);
end loop;
From Oracle Documentation:
Rules and Limits No limitation or range-checking is imposed by the API. However, you should be aware of the following size
limitations on various elements of SMTP. Sending data that exceed
these limits may result in errors returned by the server.
Table 178-5 SMTP Size Limitation
Element | Size Limitation
user | The maximum total length of a user name is 64 characters.
domain | The maximum total length of a domain name or number is 64
characters.
path | The maximum total length of a reverse-path or forward-path is
256 characters (including the punctuation and element separators).
command line | The maximum total length of a command line including
the command word and the is 512 characters.
reply line | The maximum total length of a reply line including the
reply code and the is 512 characters.
text line | The maximum total length of a text line including the
is 1000 characters (but not counting the leading dot duplicated
for transparency).
recipients buffer | The maximum total number of recipients that must
be buffered is 100 recipients.
Anyway, I think if your email body is too big, the destination will reject it...
UPDATE
Anyway, if you send so big data over email, something is wrong. You shoud use another solution. A client that reads data from database and presents it to the user in a friendly format.
There is oracle discoverer, or you can develop an application with java, or php... there are many options...
I'm developing an SMS Gateway and I was thinking about the features that I should implement in it. So I reviewed some SMS gateways (SMSNOW, SMS studio, and Ozeki) for examples.
I almost finished the implementation but I came across a feature in almost all SMS gateways which allows the user to specify TON/NPI for SMSC and ESME.
I understand that when the SMS gateway is preparing to send the sms using the SMPP protocol it would need to parse the sender/reciever number and based on that, specify TON/NPI. And I understand that it's great to allow you to override the defaults and specify your own TON/NPI.
What I don't understand is why all SMS gateways give you the option to specify your own TON/NPI for the SMS gateway when it acts as SMSC (when it receives SMS, not sending them).
What would the SMS gateway do with the specified TON/NPI when it recieves an smpp SMS?
The full specification of an SMS source address involves 3 attributes:
TON
NPI
The actual Address
TON = Type of Number.
This specifies whether the number is a full International Number (i.e. needs the + prefix), or a National Number, or even an alphanumeric sender (i.e. includes up to 11 characters of text instead of a numeric sender, quite useful for advertising).
NPI = Numbering Plan Indicator
This specifies which numbering standard the number is following. It could be the E.164 standard international numbering, or the operator's private numbering (for premium rated services for instance).
The actual Address.
An SMSC would need the TON/NPI to know how to interpret the bytes stored in the Address. If for example the TON is alphanumeric (5), it knows the bytes in the address need to be interpreted as characters and encoded accordingly, while if it is International (1), it would split each byte into 2, with each half byte representing a different digit for the sender.
You can refer to the SMPP 3.4 specification Sections 5.2.5 and 5.2.6 for a full list of these TON/NPI possibilities. The specific SMS gateway you're using might restrict you from using some of them.
TON (Type of Number)
If you wish to specify a special value for the TON, the available options are:
0: Unknown
1: International
2: National
3: Network Specific
4: Subscriber Number
5: Alphanumeric
6: Abbreviated
NPI (Numbering Plan Identification)
For NPI, the available options are:
Unknown = 0
ISDN/telephone numbering plan (E163/E164) = 1
Data numbering plan (X.121) = 3
Telex numbering plan (F.69) = 4
Land Mobile (E.212) =6
National numbering plan = 8
Private numbering plan = 9
ERMES numbering plan (ETSI DE/PS 3 01-3) = 10
Internet (IP) = 13
WAP Client Id (to be defined by WAP Forum) = 18
TON and NPI Defaults
Short Code (3 digits to 8 digits in length)
If the source code/address is a Short Code
TON = 3
NPI = 0
Long Code (10 digits to 15 digits in length, excludes the plus sign)
TON = 1
NPI = 1
Alphanumeric
If the source code/address is Alphanumeric (contains both letters and numbers or only letters)
TON = 5
NPI = 0