North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: [policy] When Tech Meets Policy...
> On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote: > > > > Accepting messages from a domain lacking MX records might be risky > > > due to the high rate of domain turnovers. Within a few weeks, > > > more than the number of existing domains will have been added and > > > deleted by then. Spammers take advantage of this flux. SMTP > > > server discovery via A records is permitted and should be > > > deprecated. > > > > All it would require is a couple of large ISP's to adopt > > such a policy. "MX 0 <self>" really is not hard and benefits > > the remote caches. > > Agreed. While some suggest deprecating A record discovery requires > adoption by a standards body, it really only requires a few ISPs to make > their intentions public. A small minority of domains lacking an MX > record are likely to comply quickly. At that point, adoption by a > standards body becomes possible. It is rare to find a standards body > willing impose additional requirements on email, but this is a case > where such a requirement is clearly necessary. > > That point forward, spammers would be less able to take advantage > of domains in flux, and policy schemes would be far less perilous for > roots or second level domains. > > > > Once MX records are adopted as an _acceptance_ > > > requisite, domains not intended to receive or send email would be > > > clearly denoted by the absence of MX records. SMTP policy > > > published adjacent to MX records also eliminates a need for email > > > policy "discovery" as well. Another looming problem. > > > > Better yet use MX records to signal that you don't want to > > receive email e.g. "MX 0 .". It has a additional benefits > > in that it is *much* smaller to cache than a negative > > response. It's also smaller to cache than a A record. > > > > Since all valid email domains are required to have a working > > postmaster you can safely drop any email from such domains. > > Use of root "." as a name for a target may create undesired non-cached > traffic when applications unaware of this convention then attempt to > resolve an address for servers named root. All modern iterative resolvers are required to support negative caching. > The use of root as a convention will complicate a general strategy > identifying adoption of a protocol by publication of a discovery > record. The use of root as a target name in SRV records has been > problematic, although this convention was defined for SRV records at the > outset. > Using an MX record to mean "no email is accepted" by naming the > target 'root' changes the meaning of the MX record. Not really. It's entirely consistant with existing DNS usage where "." is a domain name / hostname place holder. Lots of RR types use "." to indicate non-existance. > It is also not clear > whether the root target would mean "no email is sent" as well. That is, I'll agree, more of a issue but no one can reasonably expect people to accept non-repliable email. > A clearer and safer strategy would be to insist that anyone who cares > about their email delivery, publish a valid MX record. Especially when > the domain is that of a government agency dealing with emergencies. At > least FEMA now publishes an MX record. This requirement should have > been imposed long ago. : ) I much prefer positive data vs the absence of data to make a decision. "MX 0 ." is a definative response saying you don't want email. > -Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected]
|