.NET如何在Azure VWindows Server 2012上解密来自AT＆T gophone的SMS文本消息

Question

I wrote a cool .NET Windows application that communicates by SMS text messages with users, or by email. It treats SMS text messages just like email. When my Windows server 2012 receives a text message from a mobile device, or an email, both kinds arrives into C:\\inetpub\\mailroot\\Drop\\ and my app processes them.

It all has been working great with email from Gmail, Hotmail, etc., and from SMS from Verizon. But then my friend comes over and we test receiving from his AT&T gophone... Blooey! I get the email (see below) from his mobile device's SMS and all looks normal, except the actual text message payload is scrambled.

How do I descramble? Why is the text scrambled, in the first place?

X-SENDER: ##########@MMS.ATT.NET
X-RECEIVER: xxxxxxxxxx@xxxxxxx.COM
RECEIVED: FROM BTHCEG-MOMTA01-MMS.MYCINGULAR.NET ([]) BY WITH MICROSOFT SMTPSVC(8.5.9600.16384);
     MON, 5 JUN 2017 17:42:02 -0700
RETURN-PATH: <##########@@MMS.ATT.NET>
RECEIVED: FROM [] ([:14264] HELO=ALPNMS03)
    BY BTHCEG-MOMTA01 (ENVELOPE-FROM <##########@@MMS.ATT.NET>)
    (ECELERITY 3.0.23.37692 R(37717)) WITH ESMTP
    ID D2/65-04620-B5AF5395; MON, 05 JUN 2017 17:42:03 -0700
X-MMS-MESSAGE-TYPE: M-SEND-REQ
X-MMS-TRANSACTION-ID: 1496709721-5
X-MMS-MMS-VERSION: 1.2
TO: PRAY@##########@COM
FROM: ##########@@MMS.ATT.NET
DATE: MON, 5 JUN 2017 20:42:02 -0400 (EDT)
X-MMS-SENDER-VISIBILITY: SHOW
CONTENT-TYPE: MULTIPART/MIXED; 
    BOUNDARY="----=_PART_7984369_300459990.1496709722943"
MIME-VERSION: 1.0
MESSAGE-ID: <1096997833.194273661496709722943.JAVAMAIL.NEMS@ALPNMS03>
X-ORIGINALARRIVALTIME: 06 JUN 2017 00:42:02.0454 (UTC) FILETIME=[B6A1AF60:01D2DE5D]

------=_PART_7984369_300459990.1496709722943
CONTENT-TYPE: TEXT/PLAIN; CHARSET=UTF-8
CONTENT-DISPOSITION: ATTACHMENT; FILENAME=TEXT_0.TXT; CHARSET=US-ASCII
CONTENT-ID: 0
CONTENT-LOCATION: TEXT_0.TXT
CONTENT-TRANSFER-ENCODING: BASE64

..................BELOW IS THE SCRAMBLED TEXT MESSAGE: ............

TXKGCHJHEWVYIGLZOIBMB3IGSGVPZGKGDG8GAGF2ZSBWZWFJZSBPBIBOZXIGZMFTAWX5

......THE ACTUAL MESSAGE WAS: "My prayer is: for Heidi to have peace in her family" ------=_PART_7984369_300459990.1496709722943--

X-SENDER: ##########@@MMS.ATT.NET
X-RECEIVER: PRAY@##########@.ORG
RECEIVED: FROM BTHCEG-MOMTA02-MMS.MYCINGULAR.NET ([##########@]) BY PRAYSHEP WITH MICROSOFT SMTPSVC(8.5.9600.16384);
     MON, 5 JUN 2017 18:14:30 -0700
RETURN-PATH: <##########@@MMS.ATT.NET>
RECEIVED: FROM [##########@] ([##########@:51516] HELO=ALPNMS03)
    BY BTHCEG-MOMTA02 (ENVELOPE-FROM <##########@@MMS.ATT.NET>)
    (ECELERITY 3.0.23.37692 R(37717)) WITH ESMTP
    ID 29/CD-12903-7F106395; MON, 05 JUN 2017 18:14:31 -0700
X-MMS-MESSAGE-TYPE: M-SEND-REQ
X-MMS-TRANSACTION-ID: 1496711669-7
X-MMS-MMS-VERSION: 1.2
TO: PRAY@##########@.ORG
FROM: ##########@@MMS.ATT.NET
DATE: MON, 5 JUN 2017 21:14:30 -0400 (EDT)
X-MMS-SENDER-VISIBILITY: SHOW
CONTENT-TYPE: MULTIPART/MIXED; 
    BOUNDARY="----=_PART_7989525_395020720.1496711670941"
MIME-VERSION: 1.0
MESSAGE-ID: <1241288163.194397521496711670942.JAVAMAIL.NEMS@ALPNMS03>
X-ORIGINALARRIVALTIME: 06 JUN 2017 01:14:30.0518 (UTC) FILETIME=[3FC4A960:01D2DE62]

------=_PART_7989525_395020720.1496711670941
CONTENT-TYPE: TEXT/PLAIN; CHARSET=UTF-8
CONTENT-DISPOSITION: ATTACHMENT; FILENAME=TEXT_0.TXT; CHARSET=US-ASCII
CONTENT-ID: 0
CONTENT-LOCATION: TEXT_0.TXT
CONTENT-TRANSFER-ENCODING: BASE64

................. SCRAMBLED FROM TEXT MESSAGE SMS: ........... QWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFHYWFH ............ACTUAL WAS ALL "AAAAAAAAAAAAA..." ------=_PART_7989525_395020720.1496711670941--

Answer 1

So this HttpRequest is a Multi-part form.

Each file is split between the boundary:

BOUNDARY="----=_PART_7984369_300459990.1496709722943"

And then each file has its own set of information:

------=_PART_7984369_300459990.1496709722943
CONTENT-TYPE: TEXT/PLAIN; CHARSET=UTF-8
CONTENT-DISPOSITION: ATTACHMENT; FILENAME=TEXT_0.TXT; CHARSET=US-ASCII
CONTENT-ID: 0
CONTENT-LOCATION: TEXT_0.TXT
CONTENT-TRANSFER-ENCODING: BASE64

This boundary has the CONTENT-TRANSFER-ENCODING Header, meaning that all of its contents ( TEXT_0.TXT ) is encoded as BASE64 .

I took a look at what you posted the message was and it should be case sensitive resulting in TXkgcHJheWVyIGlzOiBmb3IgSGVpZGkgdG8gaGF2ZSBwZWFjZSBpbiBoZXIgZmFtaWx5 , so you may have some data corruption, or the way you are viewing the encoding is changing it.

I can't provide a code sample as I'm not sure if you are using Webforms or MVC, but here is an example with asp.net MVC Web Api 2