我正在寻找用于处理电子邮件的 ActiveX 组件的推荐
我正在寻找能够轻松实现以下功能的 ActiveX 组件：
- 通过 SMTP 和 POP3 获取和发送电子邮件，
- 删除并保存附件。
- 将 RTF（Outlook 电子邮件）转换为 HTML
- 清理 HTML。
您会推荐哪些组件？ 您使用什么组件？
I'm looking for ActiveX components that can easily:
- get and send emails via SMTP and POP3
- strip out and save attachments.
- Convert RTF (Outlook emails) to HTML
- Sanitize HTML.
What components would you recommend? What components do you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 CDOSYS 发送和接收电子邮件非常简单。 RTF 并不是真正需要处理的复杂格式。
但我认为 Chilkat SMTP/POP# ActiveX 组件是您可能想要研究的东西。
Sendong and receiving email is simple with CDOSYS. And RTF isn't really that complex a format to handle.
But I think Chilkat SMTP/POP# ActiveX component is something you migth want to look into.
Seanyboy，我可以在这里帮助您，但在您考虑商业解决方案之前，您需要了解一些事情。
首先，有数百或数千个控件可以完成您想要的操作。
但是，您必须考虑如何使用它们。 我曾经在一家防病毒公司工作，当我们决定将我们的产品连接到 Exchange 时，很明显我们选择的解决方案行不通。 问题是，商业应用程序（通常）遵循 RFC（或者是 TEE？我不知道..）但是，病毒永远不会遵循 RFC 标准。 因此，我最终为我们的扫描仪编写了自己的 Mime 解析器，并且我的检测率比我们尝试过的任何其他方法都要好得多。 为什么？ 因为每次我发现一封破坏 RFC 的电子邮件时，我都会调整代码来处理它。 我想到的一个例子是“Content-Type: maintype/subtype; param =”。 注意 param 和 equals 后面的空格。 这违反了 RFC 规则，但大多数邮件阅读器都会处理它，从而允许病毒做它的事情。
但是，这也是一枚双面硬币......在我的代码中，我无法解码格式如下的附件：
......
内容类型：应用程序/八位字节流
内容传输编码：base64
http://virus.virussite.com< br>JVBERi0xLjMgCiXi48/TIAo3IDAgb2JqCjw8Ci9Db250ZW50cyBbIDggMCBSIF0gCi9QYXJlbnQg
NSAwIFIKL1Jlc291cmNlcyA2IDAgUgovVHlwZSAvUGFnZQo+PgplbmRvYmoKNiAwIG9iago8PAov
...
但是，商业应用程序在解析它时没有问题...很可能是因为它们再次遵循了 RFC，并且如果长度不是 77 个字符，则不接受 Base64 数据（我认为 77 是 RFC 标准） ..我必须参考它。）。
但是，我遇到了更大的问题，即损坏的 B64 以及全部在单行上运行的 B64 等，并且必须对其进行解码，因此我将数据块中的所有内容都作为 Base64 数据，这实际上是有效的 Base64 字符。 其他一切都被简单地跳过了......
无论如何，关键是，决定你需要脱离这个控制，然后决定你是否想考虑编写自己的，购买商业的，甚至付钱给某人（比如我自己）为你写一篇。
（我不太确定我的最后一句话是否符合 Stack Overflow 规则，所以我不是在招揽你，只是告诉你知道你的选择。我提到这个选项是因为你可以访问源代码，并且会如果您决定与开发人员断绝关系，您可以自己维护它，或者找其他人来维护它，这不是 99.99% 的商业解决方案的选择……）如果他们做出了让您或您的人陷入困境的更改。应用程序，你很好，搞砸了..:)
希望这有帮助，或者至少给你一些东西可以阅读。 呵呵..
如果我能提供更多帮助，请告诉我。
seanyboy, I can help you out here, but before you look at commerical solutions, there are a couple things you need to understand.
First, there are hundreds, or thousands of controls out there to do what you want.
But, you have to consider HOW you are going to use them. I used to work for an Anti-virus company, and when we decided to hook our product into Exchange, it became obvious that the solution we chose was NOT going to work. The issue was, the commerical apps follow the RFC's (usually) to a T. (Or is it TEE? I dunno..) But, viruses NEVER follow the RFC standards. So, I ended up writing my own Mime parser for our scanner, and my detection rate was MUCH better than anything else we tried. Why? Because each time I spotted an email that broke the RFC's I tweaked the code to deal with it. The one example that comes to mind was the "Content-Type: maintype/subtype; param =". Notice the space after param and equals. This breaks the RFC rules, but most mail readers deal with it, allowing the virus to do it's thing.
But, this also is a double sided coin.... In MY code, I was not able to decode an attachment formatted as follows:
....
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
http://virus.virussite.comJVBERi0xLjMgCiXi48/TIAo3IDAgb2JqCjw8Ci9Db250ZW50cyBbIDggMCBSIF0gCi9QYXJlbnQg
NSAwIFIKL1Jlc291cmNlcyA2IDAgUgovVHlwZSAvUGFnZQo+PgplbmRvYmoKNiAwIG9iago8PAov
...
But, the commerical apps had no problem parsing it... Most likely because they followed the RFC's again, and did not accept Base64 data if it was not exactly 77 chars long (I think 77 is the RFC std.. I'd have to reference it.).
But, I had bigger problems with broken B64, and B64 that ran all on a single line, etc, and it had to be decoded, so I took everything in the data block as Base64 data that was in fact a valid base64 char. Everything else was simply skipped over...
Anyways, they key is, decide what you NEED out of this control, and then decide if you want to consider writing your own, buying a commercial one, or even paying someone (like myself) to write one for you.
(I'm not exactly sure my last sentence is acceptable by Stack Overflow rules, so I'm not soliciting you, just tell you know your options. I mention this option because you'd have access to the source code, and would be able to maintain it yourself, or find someone else to maintain it, if you decided to break relations with your developer. This is not an option for 99.99% of the commercial solutions...) If they make a change that screws you or your application, you are well, screwed.. :)
Hope this helps, or at least gives you something to read. heh..
Let me know if I can be of any more help.