I'm working with Gammu and PostgreSQL to send sms from my computer.
I have success sending a normal text sms.
But i have some problem now when trying to send 8bit (Binary) message to my devices. Here's my simple query to inject message to gammu 'outbox' table.
INSERT INTO outbox (
"DestinationNumber",
"Text",
"TextDecoded",
"Coding",
"UDH",
"CreatorID") VALUES (
'202555xxxx',
'02616A03776C66JF010000198C000403E800013003F200013003F30002323003F400023230',
'',
'8bit',
'06050407d50000',
'ConfigurationSMS');
as you can see 02616A03776C66JF010000198C000403E800013003F200013003F30002323003F400023230 is my SMS text encoded using hex values. The value is correct while in outbox table.
But when the message has been sent and i'm look on my inbox table, the Text value change to this 02616A03776C66BF0100000D8C000203E800013103F2000131FD00 00007400650073007400
Does anyone know why Gammu send different text? and how to prevent the changes occur? Thanks.
As mentioned before, there is invalid char in the HEX encoded string.
But I think Gammu should complain on such error, so I'll work on fixing that upstream, see https://github.com/gammu/gammu/issues/185 for progress.
Related
I am trying to understand the mime encoding. I have 2 instance of message with subject header :
1) Reply to Comment in Is my stone dead? Constantly quick-flashing white side-LED =?= in ICS Webtop Update = useless lapdock?
2)Reply to Comment in Is? white side-LED =?= in ICS Webtop Update = useless lapdock
I see different behavior in both the cases, while the former is getting encoded the later is not. Having read through some of Mime documentation, I understand the theory that when there isn't a 7bit non-ASCII character clients may encode the message. But why is the difference in above messages ? Is message length a factor too ?
I receive offline message from openfire server, but it contains empty jabber:x:delay extension.
The message I receive is:
<message id="qU7N8-64" to="ac1#server.jj.ru" from="ac2#server.jj.ru/4847791" type="chat">
<body>test message</body>
<delay xmlns="urn:xmpp:delay"></delay>
<x xmlns="jabber:x:delay"></x>
</message>
This message I receive with smack library.
But when I connect to openfire with Miranda IM, openfire sends extension jabber:x:delay with data.
Why openfire sends empty jabber:x:delay only to smack library?
Add this line after connection.
ProviderManager.getInstance()addExtensionProvider("x","jabber:x:delay", new DelayInformationProvider());
Openfire doesn't do anything different since it doesn't know (or care) what client is connected. The packet you are showing is very peculiar, since it contains both the legacy and current versions of Delayed Delivery, but with missing required attributes in both.
Try running with VM argument -Dsmack.debugEnabled=true set. Then check the incoming raw packets for the actual message content. There is most likely one of 2 things happening.
The time is missing, so Miranda is compensating by populating it with some default value, like current date.
The time format is not according to spec, so the parser in Smack is omitting it.
I am using mailparser by andris(https://github.com/andris9/mailparser). I am sending an email via redis to an nodejs app. The mailparser for somereason is unable to parse it. What could be causing the issue?
The code to get the email from redis. client is an instance of node_redis Client. MailParser is andris' mailparser. The email in redis is sent via another server, to whose channel i have subscribed. The email sent, when saved in a text file and parsed using andris' test.js, gives the expected output.
client.subscribe('email1');
client.on('message', function(channel, message){
var Parser = new MailParser();
Parser.on('headers', function(headers){
console.log(headers.addressesTo[0].address);
});
Parser.feed(message);
Parser.end();
});
I found the reason for this. The input I saw receiving had \r\n converted to \n
Instead of
Parser.feed(message);
I believe you want
Parser.write(message);
I couldn't find the feed method in the documentation. I am using the write function and it's working. The message is the original unaltered email message, including headers, body, and attachments.
I need your help in order to send email message that includes text in Greek, from within R, using the function sendmail {sendmailR}.
I tried using the function iconv, like that but it didn't work
subject <- iconv("text in greek", to = "CP1253")
sendmail(from, to, subject, msg, control=list(smtpServer="blabla"))
The mail arrives immediately but the greek characters are unreadable. Any ideas?
EDIT
Another question that came up:
The second argument to accepts one recipient. What if want to send it to more than one? (I think 'll try sapply ing the sendmail function to a vector of recipients) - Ok, that worked. However, I'm not completely satisfied because each one of the recipients has no way to know who else has received the message.
Mail client won't be able to understand any encoding without Content-Type: charset=..., so you must add it:
msg<-iconv("text in greek", to = "utf8");
sendmail(from, to, subject, msg,
control=list(smtpServer="blabla"),
headers=list("Content-Type"="text/plain; charset=UTF-8; format=flowed")
);
that is for UTF8 (which I believe should be used), for CP1253:
msg<-iconv("text in greek", to = "CP1253");
sendmail(from, to, subject, msg,
control=list(smtpServer="blabla"),
headers=list("Content-Type"="text/plain; charset=CP1253; format=flowed")
);
multisend by hidden copies can also be done with header magick, still I think sapply loop is a better idea -- then the user will see that the mail was send directly to her/himself.
I'm trying to make an "IMAP fetch" command to retrieve the message body. I need to pass/use the correct charset, otherwise the response will come with special characters.
How can I make the IMAP request/command to consider the charset I received in the BODYSTRUCTURE result??
The IMAP server will send non-ASCII message body data as an 8-bit "literal", which is essentially an array of bytes. You can't make the FETCH command use a specific charset, as far as I know.
It's up to the IMAP library or your application to decode the byte array into a string representation using the appropriate charset you received in the BODYSTRUCTURE response.