有关电子邮件，网页等的安全性...... [英] Safety regarding e-mails, web pages and so...

问题描述

大家好，



我正在完成一个全新的网页，我正在准备所有的电子邮件联系表格。



在收到一些不错的帮助之后：bob：ians，我决定采用基于表单的方式联系我们公司，尽我所能保持电子邮件的安全性并避免垃圾邮件（不是100％，但至少没有人能够收获邮件地址）。



现在我正在考虑发送确认电子邮件邮件。

聪明吗？



在客户方面，他/她会收到一封邮件通知，上面写着他/她的所有详细信息问题，但......这是一个不好的举动？是垃圾邮件机器人和/或其他坏人使用它来获取原始邮件地址并用垃圾邮件充斥它？或者我应该服用阿司匹林，去睡觉和tomorrom实施一个小的PHP邮件，并给我的客户发送一封很好的确认电子邮件？



谢谢大家！



我尝试了什么：



没什么，只是想知道它是不是很好要做或不做的事情...

我在某处读到，向我们域内的错误地址发送电子邮件的任何人发送自动电子邮件并不是一件好事。给攻击者一个有效的邮件地址...当坏人出现时，事情是如何工作真的很神奇...

Hello all,

I'm finishing a brand new web page, and I'm preparing all the e-mail contact form.

After receiving help from some nice :bob:ians, I've decided to go for a form based method to contact our company, doing that I keep as safe as possible the e-mails and avoid the spam (not 100%, but at least nobody will be able to harvest the mail address).

Now I'm thinking on sending a confirmation e-mail.
Is that clever?

On the customer side he/she will receive a mail notification with all the details of his/her question, but... is this a bad move? are the spam bots and/or other bad guys out there using this to get the original mail address and flood it with spam? Or should I take my aspirin, go to sleep and tomorrom implement a small PHP mail call and send my customers a nice confirmation email?

Thank you all!

What I have tried:

Nothing, just wondering if it is a good thing to do or not...
I've read somewhere that it is not a good thing to send an automated email back to anyone that is sending an email to a wrong address inside our domain as this is giving the attacker a valid mail address... truly it is amazing how things are working when the bad guys appear...

推荐答案

显然，没有确认e邮件，即使你在内部使用一些邮件地址，也可以通过main向你发送数据，你永远不会公开这个邮件地址。



如果你写e-邮件确认，你显然是从/回复一个地址。客户实际上可以发送邮件。



现在，简单的逻辑应该告诉你：你有这个消息成为邮件的唯一原因是真的想要那些邮件来自用户。并且，抛开可能的邮件收集，这些人可以自己发送垃圾邮件或将您的地址信息发送给垃你的选择。有时你真的希望他们给你写邮件，但后来处理后果。



如果你不需要来自客户的真实邮件，你就不需要需要发送确认信息。为什么要向某些可能的无回复地址发送确认？ （如果你从未阅读过这些邮件，你可以自动重定向它们，但为什么要接收它们？:-)）。您可以简单地形成一个临时Web页面（只是HTTP响应，显示用户信息和其他消息详细信息）并写下这是我们从您那里收到的。真的收到了。邮件可以给你的唯一额外确认是用户的邮件地址是真实的。现在，仔细想想，为什么你需要知道这一点？我是认真的。只有当用户实际向您发送邮件消息时，您才会知道。但是后来你的一些地址曝光了。现在，彻底思考。假设用户的邮件地址是假的。但是，无论如何你永远不会知道真正的地址。你可以放心地认为它是真实的。只有当您想要写入此用户时才需要它，而不是通过自动确认。如果地址是假的，你就无法用它做任何事情。您所需要的只是简单的逻辑。我错过了什么吗？



但是现在，如果您想要用户发送这些消息（不是邮件消息，而是HTTP帖子），您必须阅读这些消息。作为邮件的替代方法，您只需在服务器上收集邮件数据，清除不需要的邮件等。我的经验表明：HTTP帖子上的垃圾邮件确实存在，但它总是比邮件垃圾邮件低几个数量级。



那么邮件地址收集不是唯一可能的利用，而不是最坏的。如果您的脚本没有经过仔细编写并且发送邮件，那么恶意艺术家可以立即将您自己的主机变成发送垃圾邮件的僵尸。这是我对现实生活中这个简单漏洞的解释：下面无法发送邮件，它在下面的代码中显示错误。 [ ^ ]。



你也不能真正依赖邮件跟踪：

正则表达式表单电子邮件验证无效 [ ^ ]，

电子邮件跟踪 - 维基百科，免费的百科全书 [ ^ ]。

-SA

Quite apparently, without confirmation e-mail, even if you use some mail address internally, to forward post data to you via main, you never expose this mail address.

And if you write e-mail confirmation, you apparently expose some address, from/reply-to one. The customer can actually send a mail.

Now, simple logic should show you: you have the only reason for this message to be a mail is really want those mails from the users. And, set aside possible mail harvesting, those people can spam themselves or cell your address to spammers. Your choice. Sometimes you really want them to write mails to you, but then deal with consequences.

If you don't need that real mail messages from customers, you don't need sending them confirmations. Why sending a confirmation to some presumably "no reply" address? (If you never read those mails, you can automatically redirect them nowhere, but why receiving them at all? :-)). You could simply form a temporary Web page (just HTTP response, show user information and other message detail) and write "this is what we received from you". Really received. The only additional confirmation a mail can give you is that the user's mail address is real. Now, think thoroughly, why would you need to know that? I'm serious. You will know that only when a user actually send you a mail message. But then some your address is exposed. Now, think thoroughly. Let's supposed the user's mail address is fake. But then you will never know the real address anyway. You can safely assume it's real. It's only needed when you want to write to this user, not through automatic confirmation. And if the address is fake, you cannot do anything with it. All you need is simple logic. Have I missed something?

But now, if you want those messages (not mail messages, but HTTP posts) from users, you have to read those posts. As an alternative to mail, you can simply collect message data on server, clean unwanted messages, and so on. My experience shows: spam on HTTP post does exist, but it always orders of magnitude less then mail spam.

By the way, mail address harvesting is not the only possible exploit, and not the worst. If your scrip is not carefully written and does send mail, a malicious artist can turn your own host into a zombie sending spam, in no time. This is my explanation of this simple exploit, from real life: unable to send mail , it showing the error in below code .[^].

You also cannot really rely on mail tracking:
Regular expression form email validation not working[^],
Email tracking — Wikipedia, the free encyclopedia[^].

—SA

这篇关于有关电子邮件，网页等的安全性......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！