使用MX记录来验证电子邮件地址 [英] Using MX records to validate email addresses
问题描述
场景:
我的网络应用程序上有一个联系表格，其中包含大量垃圾邮件.
我正在松散地验证电子邮件地址的格式，即^.+@.+\..+$
我正在使用垃圾邮件过滤服务(defensio)，但返回的垃圾邮件分数与有效消息重叠.在0.4的阈值下，一些垃圾邮件通过了，一些客户的问题被错误地记录到日志中并显示错误.
Scenario:
I have a contact form on my web app, it gets alot of spam.
I am validating the format of email addresses loosely i.e. ^.+@.+\..+$
I am using a spam filtering service (defensio) but the spam scores returned are overlapping with valid messages. At a threshold of 0.4 some spam gets through and some customer's questions are wrongly thrown in a log and an error displayed.
所有垃圾邮件均使用伪造的电子邮件地址，例如zxmzxm@ywduasm.com
All of the spam messages use fake email addresses e.g. zxmzxm@ywduasm.com
美国专用的PHP5 Linux服务器，mysql，仅记录垃圾邮件，通过电子邮件发送非垃圾邮件(未存储).
Dedicated PHP5 Linux server in US, mysql, logging spam only, emailing the non spam messages (not stored).
提案:
使用php的checkdnsrr(preg_replace(/^.+?@/, '', $_POST['email']), 'MX')检查电子邮件域解析为有效地址，登录到文件，然后针对无法解析的邮件进行错误重定向，并像以前一样继续处理垃圾邮件过滤器服务，以针对根据
Proposal:
Use php's checkdnsrr(preg_replace(/^.+?@/, '', $_POST['email']), 'MX') to check the email domain resolves to a valid address, log to file, then redirect with an error for messages that don't resolve, proceed to the spam filter service as before for addresses that do resolve according to checkdnsrr().
我已经读到了(我对此表示怀疑)，您永远不应该将这种类型的验证留给远程查找，但是为什么呢?
I have read (and i am sceptical about this myself) that you should never leave this type of validation up to remote lookups, but why?
除了连通性问题之外，无论如何我都会遇到比联系表格更大的问题，checkdnsrr还会遇到假阳性/阴性吗?
会有一些无法解析的地址类型吗?政府地址? ip电子邮件地址?
我是否需要转义传递给checkdnsrr()的主机名?
Aside from connectivity issues, where i will have bigger problems than a contact form anyway, is checkdnsrr going to encounter false positives/negatives?
Would there be some address types that wont resolve? gov addresses? ip email addresses?
Do i need to escape the hostname i pass to checkdnsrr()?
解决方案: 所有三个答案的组合(希望我可以接受多个答案作为复合答案).
Solution: A combination of all three answers (wish i could accept more than one as a compound answer).
我正在使用:
$email_domain = preg_replace('/^.+?@/', '', $email).'.';
if(!checkdnsrr($email_domain, 'MX') && !checkdnsrr($email_domain, 'A')){
//validation error
}
所有垃圾邮件都已记录并轮换. 为了以后可以升级到作业队列.
All spam is being logged and rotated. With a view to upgrading to a job queue at a later date.
有人提出要求邮件服务器供用户验证的评论，我认为这将导致过多的流量，并可能以某种方式使我的服务器被禁止或出现故障，这只是为了减少大部分电子邮件由于无效的服务器地址而被退回.
Some comments were made about asking the mail server for the user to verify, i felt this would be too much traffic and might get my server banned or into trouble in some way, and this is only to cut out most of the emails that were being bounced back due to invalid server addresses.
http://en.wikipedia.org/wiki/Fqdn 和
RFC2821
The lookup first attempts to locate an MX record associated with the name.
If a CNAME record is found instead, the resulting name is processed as if
it were the initial name.
If no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.
非常感谢所有人(尤其是ZoogieZork的A记录后备技巧)
Many thanks to all (especially ZoogieZork for the A record fallback tip)
推荐答案
我发现使用checkdnsrr()进行MX查找没有什么害处，而且我也看不到误报的显示方式.您不需要转义主机名，实际上，您可以使用此技术，并通过与MTA交谈并测试用户是否存在于给定的主机上来进一步扩展该主机名(但是，该技术可能并且很可能会使您感到错误)在某些主机中为阳性).
I see no harm doing a MX lookup with checkdnsrr() and I also don't see how false positives may appear. You don't need to escape the hostname, in fact you can use this technique and take it a little further by talking to the MTA and testing if the user exists at a given host (however this technique may and probably will get you some false positives in some hosts).
这篇关于使用MX记录来验证电子邮件地址的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
