|
== What about the simple case (implicit mx rule)?
| | == What about the ''"implicit MX"'' rule?
|
| |
|
When a domain has no MX records, we assume that an A record will suffice.
| | When a domain has no <tt>MX</tt> records, SMTP ([[http://tools.ietf.org/html/rfc2821#section-5|RFC 2821, section 5]]) assumes that an <tt>A</tt> record will suffice.
|
| |
|
SPF can be similarly intuited. Mail::SPF::Query provides a [[FAQ/Best_guess_record|"Best Guess"]] method, which pretends the domain has "a/24 mx/24 ptr" defined. Even in the absence of SPF data, we can suggest that a transaction is legitimate, (though we can't suggest that it is not legitimate, only that we don't know). And finding legitimate transactions helps other antispam approaches reduce false positives.
| | SPF can be similarly intuited. Some SPF libraries provide a [[FAQ/Best_guess_record|"best guess"]] method, which pretends that domains without an SPF policy have a policy of "<tt>a/24 mx/24 ptr</tt>" defined. Even in the absence of SPF data, we can suggest that a transaction is legitimate (although we can't suggest that it is ''not'' legitimate, only that we don't know). And finding legitimate transactions helps other anti-abuse techniques reduce false positives.
|
| |
|
| | ''Note:'' The ''"implicit MX"'' rule defined by RFC 2821 is [[Google:implicit-MX|considered generally problematic]] by many. For example, consider a mail server wanting to validate the mere "existence" of a domain used in an e-mail address. Assuming the ''"implicit MX"'' rule applies, ''any'' domain name that has even just an <tt>A</tt> record (i.e. every host name!) has to be considered a valid e-mail domain, whereas probably less than 0.01% of those domain names are actually used as a sender address in e-mail.
|
What about the "implicit MX" rule?
When a domain has no MX records, SMTP (RFC 2821, section 5) assumes that an A record will suffice.
SPF can be similarly intuited. Some SPF libraries provide a "best guess" method, which pretends that domains without an SPF policy have a policy of "a/24 mx/24 ptr" defined. Even in the absence of SPF data, we can suggest that a transaction is legitimate (although we can't suggest that it is not legitimate, only that we don't know). And finding legitimate transactions helps other anti-abuse techniques reduce false positives.
Note: The "implicit MX" rule defined by RFC 2821 is considered generally problematic by many. For example, consider a mail server wanting to validate the mere "existence" of a domain used in an e-mail address. Assuming the "implicit MX" rule applies, any domain name that has even just an A record (i.e. every host name!) has to be considered a valid e-mail domain, whereas probably less than 0.01% of those domain names are actually used as a sender address in e-mail.
