电子邮件到 SMS 网关：识别回复
我正在开发一个应用程序，我希望能够在其中发送和接收 SMS 消息，并且我正在考虑使用电子邮件到 SMS 网关，因为它的成本更低，而且我需要集成的技术也更少。我已阅读使用免费电子邮件发送短信的限制->短信网关并且大多数限制不适用于我：
- 我对格式不那么挑剔
- 我不介意猜测/询问实际的电子邮件地址或至少是我用户的运营商name
- 我可以通过电子邮件处理回复
我确实遇到的问题是，至少对于某些运营商（我刚刚在美国测试了 Verizon），当收件人回复时，似乎任何消息回复内容的指示。相比之下，AT&T 保留原始 SMTP Message-ID 和主题。
这个问题有任何已知的解决方案吗？这并不是一个真正的全球应用程序（无论如何还不是），所以我不介意到处都有特定于运营商的黑客攻击，只要有某种方式来跟踪回复即可。
编辑：这是电子邮件回复的精简示例：
Delivered-To: [email protected]
Return-Path: <[email protected]>
Received: from njbrspamp5.vtext.com (njbrspamp5.vtext.com [69.78.129.150])
by mx.google.com with ESMTP id t4si5870253qcs.11.2011.05.05.14.32.20;
Thu, 05 May 2011 14:32:21 -0700 (PDT)
Date: 05 May 2011 21:32:20 +0000
Received: from unknown (HELO njbb-wigdb2) ([10.134.199.245])
by njbrspamp5.vtext.com with ESMTP; 05 May 2011 21:32:20 +0000
Message-ID: <16619319.1304631140504.JavaMail.root@njbb-wigdb2>
From: [email protected]
To: [email protected]
Subject: This is a reply!
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
I'm developing an application where I would like to be able to send and receive SMS messages, and I'm thinking of using the email to SMS gateways because it's lower cost and one less technology I have to integrate. I've read Limitations on SMS messages sent using free email->SMS gateways and most of those limitations don't apply to me:
- I'm not that picky about the formatting
- I don't mind guessing/asking for the actual email address or at least my users' carrier name
- I am able to process replies by email
The problem I do have is that at least for some carriers (I just tested Verizon in the US), when the recipient replies back there doesn't appear to be any indication of what the message is in reply to. By contrast, AT&T preserves the original SMTP Message-ID and Subject.
Are there any known solutions to this problem? This isn't really a global application (not yet anyway) so I don't mind carrier-specific hacks here and there, as long as there's some way to track the reply.
Edit: here's a stripped down sample of the email reply:
Delivered-To: [email protected]
Return-Path: <[email protected]>
Received: from njbrspamp5.vtext.com (njbrspamp5.vtext.com [69.78.129.150])
by mx.google.com with ESMTP id t4si5870253qcs.11.2011.05.05.14.32.20;
Thu, 05 May 2011 14:32:21 -0700 (PDT)
Date: 05 May 2011 21:32:20 +0000
Received: from unknown (HELO njbb-wigdb2) ([10.134.199.245])
by njbrspamp5.vtext.com with ESMTP; 05 May 2011 21:32:20 +0000
Message-ID: <16619319.1304631140504.JavaMail.root@njbb-wigdb2>
From: [email protected]
To: [email protected]
Subject: This is a reply!
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我意识到这可能是一个不太知情的答案，但我知道至少 Gmail 支持扩展名/别名，例如
[电子邮件受保护]转至您的电子邮件收件箱。我不知道这是否得到广泛支持，但如果您可以这样做[电子邮件受保护]。I realize this may be a less informed answer, but I know at least Gmail supports extensions/aliases so that e.g.
[email protected]goes to your e-mail inbox. I don't know if this is widely supported, but it seems like it would be clever if you could do[email protected].我不能代表 Verison，但我熟悉通过 ATT 短信网关发送短信电子邮件。 ATT 正在做的是重新使用原始 messageid - IOW，回复将具有与其回复的电子邮件相同的 messageid。虽然这确实保留了消息线程，但它公然违反了 RFC 2822，RFC 2822 规定每封电子邮件必须具有唯一的 messageid。尝试对这些电子邮件进行消息跟踪可能是一场噩梦，因为该 messageid 应该唯一标识日志中的每封电子邮件。
您是否查看过版本电子邮件上的所有 smtp 标头，看看它们是否添加了可能是线程引用的任何内容？
I can't speak for Verison, but I am familiar with SMS emails through ATT's sms gateway. What ATT is doing is re-using the original messageid - IOW, the reply will have the same messageid as the email it is in reply to. While this does preserve a message thread, it is a blatant violation of RFC 2822, which states that every email message must have a unique messageid. Trying to do message tracking on those emails can be a nightmare, because that messageid is supposed to uniquely identify each email in the log.
Have you looked at all of the smtp headers on the Verision emails to see if they're adding anything there that might be a thread reference?