On Aug 12, 2007, at 6:41 AM, John Levine wrote:

The problems with domain tasting more affect web users, with vast number of typosquat parking pages flickering in and out of existence.

Domain tasting clearly affects assessments based upon domains. With millions added and removed daily as part of "no cost" domain tasting programs, the number of transitioning domains has been increased by an order of magnitude. Many of these new domains often appear as possible phishing domains. The high number of tasting domains obscures which are involved in criminal activities. This high number also makes timely notification of possible threats far less practical. There is no advanced notification of new domains nor reliable information pertaining to domain ownership. There are significant costs associated with analyzing and publishing domain assessment information. Registries blithely ignore this reality by permitting the dangerous activity to continue free of change. Perhaps those harmed by the resulting chaos that domain tasting creates could start a class action. A coalition of financial institutions might prevail in both getting this program to end, and perhaps even require advanced notification of new domains. Domain tasting is clearly buying criminals critical time due to the resulting high flux created for domain assessments. -Doug

Barry Shein wrote:

On August 13, 2007 at 10:11 dotis@mail-abuse.org (Douglas Otis) wrote:

...

On Aug 12, 2007, at 6:41 AM, John Levine wrote:

...

The problems with domain tasting more affect web users, with vast number of typosquat parking pages flickering in and out of existence.

Domain tasting clearly affects assessments based upon domains. With millions added and removed daily as part of "no cost" domain tasting programs, the number of transitioning domains has been increased by an order of magnitude. Many of these new domains often appear as possible phishing domains. The high number of tasting domains obscures which are involved in criminal activities. This high number also makes timely notification of possible threats far less practical.

This sort of chain of reasoning, one behavior for one purpose might sometimes be a more insidious behavior for other purposes, makes me nervous. I just think it's a treacherous way to make policy, except in extreme cases.

Then again I'm not particularly bugged by people who run these ad-only sites. Seems to me that's between them and the advertisers who pay them so long as it's not inherently criminal. And where it is criminal that should be dealt with, take any advertising medium in existence and you'll find a percentage of fraud.

The real sin here is indicated by the terminology, "domain tasting". Domains should be paid for in advance, not necessarily "by law", but by liability.

That is, if you extend domains on credit w/o any useful accountability of the buyer and this results in a pattern of criminality then the liability for that fraud should be shared by the seller.

I am not sure tasting is criminal or fraud.

This would not be unique, there are lots of real world examples (e.g., if you rented cars for cash and asked for no id's and they were often used in crimes...)

The car rental example falls apart: no ID = no way to track you down if you don't return the car. I don't believe there are any real world examples, where "real world" deals with anything physical. I think this problem only exists in the electronic world, where what is being bought and sold is just a few bytes in a database. Carl K

J Bacher wrote:

Carl Karsten wrote:

...

...

That is, if you extend domains on credit w/o any useful accountability of the buyer and this results in a pattern of criminality then the liability for that fraud should be shared by the seller.

I am not sure tasting is criminal or fraud.

You got what you ordered. You used it. You pay for it. It's that simple.

That doesn't make anything criminal or fraud any more than free samples. If a registrar wants to give a refund, I don't see anything wrong with that. It is not even close to that simple, Carl K

That doesn't make anything criminal or fraud any more than free samples. If a registrar wants to give a refund, I don't see anything wrong with that.

It is certainly fraud to take an entire pile of free samples. Domain tasting is more like buying a plasma TV to watch the big game and then returning it to the store on Monday. However, when it's as blatant and obvious as it is now (more tasted domains than legitimate registrations), and no policies are made to stop it despite it being so easy to do so (simply limit the number of refunded domains to 10% of registrations or charge a 20 cent fee for refunded domains), you can argue that it's now an understood and accepted practice. It's not fraud if both parties know it's going to happen, can easily act to stop it, and neither one chooses to. DS

David Schwartz wrote:

...

That doesn't make anything criminal or fraud any more than free samples. If a registrar wants to give a refund, I don't see anything wrong with that.

It is certainly fraud to take an entire pile of free samples.

can you cite how that law reads? Oddly enough I am in possession of 20+ fee samples that were the left overs from a hand out, and I was cleaning up the place. pretty sure I did not break any laws. I know that isn't what you meant, but it is what you said. One of the tricky parts about law is defining it. If you can't define it, it is really hard to make it illegal.

Domain tasting is more like buying a plasma TV to watch the big game and then returning it to the store on Monday.

Which is also like buying a TV and not being satisfied with it and making use of the sores generous return policy. pretty sure not fraud.

However, when it's as blatant and obvious as it is now (more tasted domains than legitimate registrations), and no policies are made to stop it despite it being so easy to do so

I don't think it is "so easy."

(simply limit the number of refunded domains to 10% of registrations

I don't know what you mean.

or charge a 20 cent fee for refunded domains), Didn't someone already shoot this down? something about consumer protection.

you can argue that it's now an understood and accepted practice.

don't have to.

It's not fraud if both parties know it's going to happen, can easily act to stop it, and neither one chooses to.

um, not fraud?

On Aug 13, 2007, at 2:01 PM, Carl Karsten wrote:

I am not sure tasting is criminal or fraud.

Tracking domain related crime is hindered by the millions of domains registered daily for "domain tasting." Unregistered domains likely to attract errant lookups will not vary greatly from unregistered domains useful for phishing. The large flux in domain names significantly inhibits anti-phishing efforts. Although some may see delays in publishing as problematic, often domain facilitated crime depends upon the milli-second publishing rapidity used to evade protective strategies. A publishing process that offers notification will allow protection services a means to stay ahead of criminals. Exceptions could be granted on an exigent or emergency basis, where of course additional fees might be required. Just as background checks are normally part of the hand gun trade, a background check should be normally part of the domain trade. Many are deceived by "cousin" domains frequently used in crimes netting billions in losses. Money garnered by capturing errant domain entries can not justify criminal losses that are likely to have been otherwise prevented. Domain tasting is worse than a disgrace. For domains to play any role in securing email, a published MX record should become a necessary acceptance requirement. Using MX records also consolidates policy locales which mitigates some DDoS concerns. -Doug

On Mon, 13 Aug 2007, Douglas Otis wrote:

On Aug 13, 2007, at 2:01 PM, Carl Karsten wrote:

...

I am not sure tasting is criminal or fraud.

Tracking domain related crime is hindered by the millions of domains registered daily for "domain tasting." Unregistered domains likely to attract errant lookups will not vary greatly from unregistered domains useful for phishing. The large flux in domain names significantly inhibits anti-phishing efforts.

maybe I'm just thick, but how exactly does tastinng inhibit anti-phishing efforts? There are several studies that show no matter the content of the URL or displayed URL people still click on the links in email... So, whether its 'bankofamerica.com' or 'banksofamericas.com' isn't really relevant to the clickers :( Phishing seems like the current 'bad thing' that people want to use as a hammer against all perceived badness, even where it doesn't seem to fit.

Although some may see delays in publishing as problematic, often domain facilitated crime depends upon the milli-second publishing rapidity used to evade protective strategies. A publishing process that offers notification will allow protection services a means to stay ahead of criminals. Exceptions could be granted on an exigent or emergency basis, where of course additional fees might be required.

I agree that some sort of 'expedite' fee would be fine, I'm not sure I like the 'notification service' though... what if I have a new product launch I need to protect PR-wise? why would I want to release that anytime before the launch date/time? -Chris

On Tue, August 14, 2007 1:48 am, Douglas Otis wrote:

For domains to play any role in securing email, a published MX record should become a necessary acceptance requirement. Using MX records also consolidates policy locales which mitigates some DDoS concerns.

What if there's no intention to use the domain for email? I've become annoyed enough in the other direction, owning domains *only* used for email and dealing with irate people insisting I'm domain-squatting and must sell them the domain cheaply right now because there's no A record for www.what.ever. Functioning, correct and coherent DNS prior to registration, now that I support whole-heartedly. Regards, Tim.

On Aug 14, 2007, at 9:29 AM, Al Iverson wrote:

On 8/14/07, Tim Franklin <tim@pelican.org> wrote:

...

On Tue, August 14, 2007 1:48 am, Douglas Otis wrote:

...

For domains to play any role in securing email, a published MX record should become a necessary acceptance requirement. Using MX records also consolidates policy locales which mitigates some DDoS concerns.

What if there's no intention to use the domain for email?

I've become annoyed enough in the other direction, owning domains *only* used for email and dealing with irate people insisting I'm domain-squatting and must sell them the domain cheaply right now because there's no A record for www.what.ever.

I'm annoyed enough in the original direction. I, like many thousands of people, have some domains that I don't use for email, so they don't have an MX record. How do you enforce this new requirement? Who chases it down? How does it stop domain tasting? If this is ultimately to stop domain tasting abuse, why not instead stop domain tasting? It seems like this simply add rules that somebody has to figure out to who enforce, and I'm not exactly inspired to think that it'll be enforced regularly or properly.

All registrations MUST incur a nominal charge applied uniformly. Remove the option permitting domain registration at little or no cost. End of problem.

This seems like creating a requirement that people must implement mosquito nets to solve the mosquito problem, instead of focusing on removing the mosquitos.

This comment was added as a follow-on note. Sorry for not being clear. 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. Unfortunately SMTP server discovery via A records is permitted and should be deprecated. 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. Don't accept a message from a domain without MX records. When there is no policy record adjacent to the MX record, there is no policy, and don't go looking. -Doug

On Tue, 14 Aug 2007, Al Iverson wrote:

On 8/14/07, Douglas Otis <dotis@mail-abuse.org> wrote:

...

This comment was added as a follow-on note. Sorry for not being clear.

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. Unfortunately SMTP server discovery via A records is permitted and should be deprecated.

Should be (perhaps) but clearly isn't. When you run it through a standards body and/or obtain broad acceptance; great! Until then, it's pipe dreaming.

Okay I wasn't reading this thread but the last few posts have gone a little over the edge. I don't know where this whole "Must have MX record to send email" thing came from but I would have thought domains that don't want to send email can easily mark this fact with a simple SPF record: v=spf1 -all Trying to overload the MX record is pointless when there is a simple method that the domain owners, registrars can choose to use or not. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

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. 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. It is also not clear whether the root target would mean "no email is sent" as well. 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. : ) -Doug

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: Mark_Andrews@isc.org

On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:

...

...

On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:

...

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.

Indeed, RFC 2308 changed negative caching support from optional for any caching resolver. Those that have negative caching may significantly truncate the duration. There are several websites recommending negative caching be disabled to permit faster recovery from intermittent negative answers. In other words, a negative answer is less likely to have been cached. Use of root target names will impact roots in cases where:

- an assumption of negative caching is wrong, - for MX records where the root name convention is not in place.

With email, transaction rates are high and highly distributed which tends to diminish negative caching protections.

...

...

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.

Yes, and this convention still generates nuisance root traffic whenever the application fails to comprehend "." is a special target. This is true even when _defined_ as a special target for the specific resource record, as with SRV. In the case of an MX record, there is _no_ such definition.

So we write a RFC. That I though was implicit. If you have applications which don't honour SRV's "." processing rules report the bug.

...

...

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.

That would have been made clear by simply requiring MX records for acceptance!

...

...

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 definitive response saying you don't want email.

Not having an SMTP server and no MX record provides a clear indication of a policy "I don't want email."

Which requires a SMTP server to attempt the TCP connection. It also requires the SMTP server to re-try until it times out the messages which could be days. SPF is optional. MX processing is NOT optional. Most SMTP client will fail immediately if they get a positive indication that there are no address records for the MX. Fixing them not to ask the question is a optimisation.

Policy will often require a greater amount of information.

This is a simple binary decision. I want email for this domain or not.

To discovery policy must the entire domain be queried?

You have the name. It has a address. You don't want email to be sent there. You add a single MX record next to the address. No seaching. Just direct query.

A wildcard MX record and root name convention exposes a domain to an SPF script attack, where a different convention is expected for no email.

No the presence of the record with "." as the MX target would stop all further processing. You don't go to SPF processing as the source address is non repliable.

In this case, one cached SPF record may utilize a sequence of originating email-address local-parts in a spam campaign to generate 10, 20 or perhaps 30 MX record transactions per message. Each MX transaction might be given a maximal label size as well. This attack would completely free for spammers and would not expose their 0wned systems, as the attack will emanate from the recipient's resolvers. Email logs may not offer clues in how the attack happened, as victim domains might have been obfuscated by a combination of local-part and SPF script. And yes, SPF is another method some recommended for expressing email policy.

When can the recipient of a message know whether the originating domain expressed policy that goes beyond NO? Query all TXT RR? Examine policy at some policy location? The only place where policy should published is at a protocol discovery record. In the case for email, it would be at the MX record. Wildcards for policy will likely create other problems.

The XPTR proposal by Phillip Hallam-Baker envisions such a wildcard scheme where a new pointer record is to be published at _every_ existing node.

http://www.ietf.org/internet-drafts/draft-hallambaker-xptr-00.txt

A simpler scheme would be to require a protocol discovery record and then expect any related policy be published adjacent to the discovery record. For email, the MX record would be a protocol specific discovery record.

-Doug

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote:

...

...

Yes, and this convention still generates nuisance root traffic whenever the application fails to comprehend "." is a special target. This is true even when _defined_ as a special target for the specific resource record, as with SRV. In the case of an MX record, there is _no_ such definition.

So we write a RFC. That I though was implicit.

Do not depend upon applications not to resolve addresses for root names, even when a convention is explicit. Depending upon root answers to support a protocol feature unrelated to DNS is normally considered a design mistake isn't it?

No. The root must exist. To many things break when there is no root.

...

If you have applications which don't honour SRV's "." processing rules report the bug.

Even Paul Vixie, the author, will likely agree the RFC has the "bug".

No, it's the implementations that have the bug. If you want really scary "A 0.0.0.0" to indicate that you are offline but exist. This is actually using 0.0.0.0 as it was intended. i.e. I exist but I do not know my address.

...

...

Not having an SMTP server and no MX record provides a clear indication of a policy "I don't want email."

Which requires a SMTP server to attempt the TCP connection. It also requires the SMTP server to re-try until it times out the messages which could be days.

Who would be motivated in making the change? Trying every address record is unsuitable for today's email environment. Its time for a change.

I suspect the SMTP vendors would pick it up reasonably quickly. I suspect everyone that uses "MX 0 nonexistant" today would pick it up. I suspect everyone has a SPF record indicating they don't send email would pick it up. They don't want the bounce traffic. It's usable by sites with idiotic resolver libraries that can't return unknown record types.

...

SPF is optional. MX processing is NOT optional.

MX records should not optional, but they are.

I said MX processing. You *have* to do the lookup.

...

Most SMTP client will fail immediately if they get a positive indication that there are no address records for the MX. Fixing them not to ask the question is a optimisation.

Publishing wildcard MX root records everywhere represents a poor and possibly hazardous solution.

...

...

Policy will often require a greater amount of information.

This is a simple binary decision. I want email for this domain or not.

A policy may need to express whether the domain signs some or all of their outbound messages. Not very binary is it?

...

...

To discovery policy must the entire domain be queried?

You have the name. It has a address. You don't want email to be sent there. You add a single MX record next to the address. No seaching. Just direct query.

Policy is not normally published for inbound traffic. SMTP extensions negotiate inbound policy requirements. However, policy could be essential for outbound traffic. A domain name might be the subject of phishing attacks. How policy is applied must ensure even sub-domains are covered.

A safe strategy for applying an outbound message policy is to:

- check whether there is a discovery (MX) record

- no discovery record, refuse the message

If there is a "MX 0 ." record, refuse the message

- check whether a policy record is adjacent to the discovery record

- no policy record, there is no policy

...

...

A wildcard MX record and root name convention exposes a domain to an SPF script attack, where a different convention is expected for no email.

No the presence of the record with "." as the MX target would stop all further processing.

The SPF script processing is looking for address matches, which may or may not include those within the MX record. SPF libraries might not quit after hundreds of no answers. This behavior is just one of the reasons these libraries are hazardous. Remember an outbound path may not be the same as the inbound.

...

You don't go to SPF processing as the source address is non repliable.

When the originating domain fails to offer a discovery record? Section 5.1 of the updated version of 2821 allows A or AAAA when there is no MX. This allowance must become obsolete and the process ends when there is no MX record. This means one does not have to wait for unmotivated domain owners to adopt the MX root strategy. Instead, those wishing to have their email accepted have a powerful motivation to publishing a valid MX record. At that point, much sooner than for your scheme, no MX will then mean no acceptance or will indicate where policy can be found.

There are lots of people who have "MX 0 nonexistant" today for domains for which they don't want email. All of those break sanity checks for MX records. Have exactly one exception, "." is codable.

Your scheme now means that: - both the MX root records must be wildcards published at every existing node - policy records must also be wildcards published at every existing node - or the recipient must walk up the domain

No. You don't need policy records if you treat "MX 0 ." as no email shall be sorced from this domain. You want to block email from sites with no MX records. "MX 0 ." is equivalent to having no MX records.

Your scheme will not scale, especially when replicated by other protocols. This approach risks root and second level domains. However, policy at the discovery record can scale and is much safer.

What other protocols are unauthenticated PUSH transfers? Just about all the other protocols a pull transfers and / or authenticated.

-Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

Section 5.1 of the updated version of 2821 allows A or AAAA when there is no MX. This allowance must become obsolete and the process ends when there is no MX record.

This idea is fundamentally flawed. There is an assumption in the Internet that email is a universal service. In otherwords, everyone can potentially be contacted via an RFC 822 et al. email address. Part of this fundamental assumption would require every Internet connected domain to have some means of email contact for various default addresses such as abuse@example.com. This does not mean that domain owner must run an email server. They may rely on someone else for email service and divert email with an MX record. But if a domain exists to service a single point on the Internet, i.e. a single server, then even if we say that domain owners MUST publish an MX record, we should still be liberal in what we accept, and search for an A or AAAA record to see if this device will possibly accept email for the domain. Note that there are other possible ways to change the email architecture to accomplish what an MX record does today, but these things need to be done from an architectural point of view, considering the entire email architecture, not just point changes in one narrow area. It may be that we can build a better email architecture if we remove the universal email assumption. Or maybe we could remove anonymous email relaying to any arbitrary port 25 with a system of email peering (like BGP or USENET peering) based on prearranged agreements. In that case we may assume that email to a domain can be delivered by looking at the last hop IP address, checking the PTR and then doing an RR lookup for the destination domain name. Or some sort of redirection protocol such as HTTP so that every domain must have an A or AAAA record and that device must accept connections and identify the correct email relay agent for incoming messages to the domain. The key to this is not to propose or make point changes in one narrow area, but to open up the entire architecture, look at what works, identify the areas that need to be fixed, agree on goals and then fix all the weaks spots at once. Personally, I am tired of seeing solutions to the SPAM problem. I don't agree that there is a SPAM problem with email. Instead, we have an inconsistent email architecture that was never designed as an integrated entity and this architecture does not have an end-to-end chain of accountability built out of bilateral trust arrangements. If we did have such a chain, then the ISP at the end of the chain could escalate problems up the chain until they either resolve it or discover a breakdown in trust. At that point, blocking email becomes easier because all relays in the chain of accountability up to the trust breakdown can be identified and mail can be blocked, returned to sender, or whatever. There will be several orders of magnitude less trusted links than there are email senders, i.e. there may be 2 billion email senders but only 20,000 trusted mail relays worldwide. This makes problem resolution far more scalable than in todays world where any of those 2 billion email senders are allowed to send email to any arbitrary email server. Flat architectures do not scale, hierarchy does. The existing email architecture is largely flat. It needs to be made hierarchical and therefore scalable. I hestitate to get into any in-depth discussion on any particular technical proposal because I believe all of them are fatally flawed as long as we have no overall agreed email architecture. Today different groups have different understandings of what the email architecture is. People who like SPF don't see the same architecture as people who like DKIM or people who like Bayesian filtering or people who like blacklists or people who like whitelists or people who use Yahoo or Gmail. In this schizoid environment all we do is force the criminal classes to get smarter than us, and to increase their exploitation of us. In order to bring order back into Internet email, we need to come together and agree on what we want from email, what is a scalable Internet email architecture, and only then, what needs to be changed to make it so. --Michael Dillon

On 8/15/07, Barry Shein <bzs@world.std.com> wrote:

...

I am not sure tasting is criminal or fraud.

Neither am I, we agree. I meant if there's subsequent criminality or fraud that should be dealt with separately.

Dumb question, not necessarily looking to call you or anyone out, but I'm curious: What valid, legitimate, or likely to be used non-criminal reasons are there for domain tasting? Then my next question is, what reasons are there where it'd be wise/useful/non-criminal to do it on a large scale? Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA

On Wed, Aug 15, 2007 at 02:38:48PM -0500, Al Iverson wrote:

I'm curious: What valid, legitimate, or likely to be used non-criminal reasons are there for domain tasting?

From my point of view, it's too bad that the registries have to carry

Making money on the basis of the published policies of a registry? If this were some sort of "Web 2.0" application, everybody would be impressed with the "mash up" the "domainers" had managed to spot: you take a bit of capital, a grace period without any clear rules for its application, and another application on the web (Google, in this case), and in one go you produce revenue out of some domains and none out of others. By learning which ones are poor earners, you learn things about which kinds of names are (at least currently) likely to attract web traffic. You therefore learn which pool of names _do_ attract traffic, and which will therefore be profitable. It isn't plain to me that all this speculation is even bad. When people do it with land or stocks, we don't seem to mind too much. the cost without getting any benefit from it. Some registries have introduced methods to try to recover some of their costs when dealing with this sort of behaviour. But I don't believe that there's anything criminal, or even "invalid" or "illegitimate" (whatever those would mean in respect of domain names) going on. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <andrew@ca.afilias.info> M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110

On August 15, 2007 at 14:38 aiversonlists@spamresource.com (Al Iverson) wrote:

On 8/15/07, Barry Shein <bzs@world.std.com> wrote:

...

...

I am not sure tasting is criminal or fraud.

Neither am I, we agree. I meant if there's subsequent criminality or fraud that should be dealt with separately.

Dumb question, not necessarily looking to call you or anyone out, but I'm curious: What valid, legitimate, or likely to be used non-criminal reasons are there for domain tasting?

Well, not all of us agree that these ad-only pages are particularly a problem. They're certainly not necessarily criminal or fraudulent except by some stretch. It seems to me that this should be an issue between the domain registrars and their customers, but maybe some over-arching policy is making it difficult to do the right thing? Charging a "re-stocking fee" sounded perfectly reasonable. I don't think anyone has any *right* to "domain tasting", that is, to any particular pricing structure. But I don't see why it requires anything beyond some pricing solution as suggested.

Then my next question is, what reasons are there where it'd be wise/useful/non-criminal to do it on a large scale?

It's a relatively passive activity when used for ad pages, no one forces anyone to look at them. I'm not sure what the problem is with that except it seems to offend some people's sensibilities. If the behavior is used to hide illegal activity such as spamming (e.g., botnet use) then that should be more of a reputation issue. The example which came to mind was ordering a couple of hundred phone lines. In the early days of the internet people like myself did that for modem banks (there was a time it was a lot cheaper to punch up 256 1MBs than to try to demux T1s or T3s or PRIs, I think I still have 66-block punch tool scars in my palm.) A friend who ran an ISP did that and the police showed up thinking he might be setting up a boiler room (telephone stock scam.) He was amused. They weren't sure what he was doing (internet? modems? WTF?) but decided it wasn't a boiler room so left. But that's what a lot of this reminds me of, except of course that ordering hundreds of phone lines required some sort of credit relationship with your local telco which seems to be what's lacking here. But obviously boiler room ops got away with it, that's why they were a problem. I assume the telcos got better at screening such criminals, they probably never paid their phone bills anyhow. But the concept of ordering hundreds of phone lines wasn't at issue, just some borderline criminal behavior and how to suppress it. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

On Aug 15, 2007, at 2:55 PM, Barry Shein wrote:

...

Then my next question is, what reasons are there where it'd be wise/useful/non-criminal to do it on a large scale?

It's a relatively passive activity when used for ad pages, no one forces anyone to look at them. I'm not sure what the problem is with that except it seems to offend some people's sensibilities.

If the behavior is used to hide illegal activity such as spamming (e.g., botnet use) then that should be more of a reputation issue.

This 'almost' hits the nail on the head. While domain tasting may not intend to obfuscate various nefarious activities related to domain names, it does. Domain assessments are impeded by a vast amount of domain name chaff caused by domain tasting. Domain tasting represents a significant burden in both assessment costs and performance. An unnecessary expense, an unnecessary overhead, and an unnecessary risk. As IPv6 is introduced, reliance upon IPv4 address assessment must transition to greater reliance on domain name assessment. There are too many IPv6 addresses and too many translators and proxies. Attempting to retain an open system makes domain assessment essential, and an open system seems like the "right thing." -Doug To quote Benjamin Franklin, "Sell not virtue to purchase wealth, nor Liberty to purchase power."

On Mon, 13 Aug 2007, Barry Shein wrote:

That is, if you extend domains on credit w/o any useful accountability of the buyer and this results in a pattern of criminality then the liability for that fraud should be shared by the seller.

+1 I find the ad-only sites irritating, but what's really annoying is the way spammers use throwaway domains as a cheap way of escaping from accumulating a bad reputation. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

On Mon, 13 Aug 2007, John C. A. Bambenek wrote:

That's exactly the problem.... "the goal of tasting is to collect pay per click ad revenue"...

Ten years ago the internet was for porn, now it's for MLM/Affiliate/PPC scams. As long as we put up with companies abusing the Internet as long as they are making a buck, they'll keep doing it.

to be very clear, this 'domain tasting' (no matter if you like it or not) is just using a 'loophole' in the policy/purchase that's there for the safe guarding of normal folks. It just happens that you can decide within 5 days that you don't want a domain or 1 million domains... So, to be clear folks want to make it much more difficult for grandma-jones to return the typo'd: mygramdkids.com for mygrandkids.com right? -Chris (yes, domain tasting is unlikeable)

On Mon, 13 Aug 2007, Carl Karsten wrote:

...

So, to be clear folks want to make it much more difficult for grandma-jones to return the typo'd: mygramdkids.com for mygrandkids.com right?

Not just that, they want registrars to take a revenue cut.

I am assuming that A. a registrar would get less business being "less forgiving" than others. B. a registrar gets revenue from tasted domains that taste good.

I think the policy change would most likely be at the ICANN level or perhaps at the registry level. I got the impression that the current policy 'loophole' was at the registry or ICANN level already. So, this would probably

I see no finical incentive for a registrar to change their policy.

because they are often part of the tasting ... so they don't want to cut off their revenue stream, which in no way touches grandma-jones and her typo'd domain purchase, fyi.

John Levine wrote:

...

...

I am assuming that A. a registrar would get less business being "less forgiving" than others.

Do you know what your current registrar's refund policy is? Do you know what other registrars' policies are? Why haven't you switched to the registrar that offers the cheapest refunds?

Don't care, because I don't do the kinds of transactions where it would matter.

I have a lot of criteria for what makes a good registar, and in my case, which I think is not atypical, refund policy is so far down the list as to be invisible.

ditto. That doesn't mean there aren't people who care: the tasters. No, I am not trying to protect them. I am looking out for the registrar. Carl K

On Mon, 13 Aug 2007, Douglas Otis wrote:

On Aug 13, 2007, at 11:03 AM, Chris L. Morrow wrote:

...

So, to be clear folks want to make it much more difficult for grandma-jones to return the typo'd: mygramdkids.com for mygrandkids.com right?

Grandma will still need to make a payment for the domain. Grandma is also unlikely to find a clause in her contract which removes a payment obligation after a few days. Provisions that enable domain tasting are unlikely to benefit individuals.

but today that provision is: If you buy a domain you have 5 days to 'return' it. The reason behind the return could be: "oops, I typo'd" or "hurray, please refund me for the 1M domains I bought 4.99 days ago!". The 'protect the consumer' problem is what's enabling tasting.

On Mon, 13 Aug 2007, Sean Donelan wrote:

Do people really not plan that far ahead, that they need brand new domain names to be active (not just reserved) within seconds?

I'm really not sure, but I can imagine a slew of issues where 'marketting' doesn't plan properly and corp-ID/corp-branding end up trying to register and make-live a domain at the 11th hour... This also seems like the quick/easy fix. I'm not against any particular fix, but people need to understand (and Sean you probably do, as does Doug I suspect) what the implications of these design changes are and who'd be affected. -Chris

On Mon, 13 Aug 2007 Valdis.Kletnieks@vt.edu wrote:

On Mon, 13 Aug 2007 19:52:37 -0000, "Chris L. Morrow" said:

...

I'm really not sure, but I can imagine a slew of issues where 'marketting' doesn't plan properly and corp-ID/corp-branding end up trying to register and make-live a domain at the 11th hour...

"Failure to plan ahead on your part doesn't mean a crisis on my part".

that's fine in theory, in practice it just doesn't work so well :(

What happened to suits who failed to plan ahead *before* we had the Internet?

less spectacular failure? :) I really don't know, I imagine this sort of thing happened with 1-800 numbers for customer support type things. Say, speaking of 1-800 things, how does that system work? why don't the equivalent 'domain tasters' on the phone side exploit the ability to sign up 1-8XX numbers like mad and send the calls to their ad-music call centers?

On Mon, August 13, 2007 11:27 pm, Roland Dobbins wrote:

2. People tend to be much more careful about punching numbers into a telephone than typing words on a keyboard, I think. There's also not a conceptual conflation of common typo mistakes with common telephone number transpositions, I don't think (i.e., I'm unsure there's any such thing as a common number transposition, while there certainly is with linguistic constructs such as letters).

Having a home land line with the last two digits transposed from that of a local fast food establishment, I beg to differ :) Regards, Tim.

On Aug 13, 2007, at 12:28 PM, Sean Donelan wrote:

On Mon, 13 Aug 2007, Chris L. Morrow wrote:

...

but today that provision is: If you buy a domain you have 5 days to 'return' it. The reason behind the return could be: "oops, I typo'd" or "hurray, please refund me for the 1M domains I bought 4.99 days ago!". The 'protect the consumer' problem is what's enabling tasting.

So combine these ideas with the possibility that someone will claim various consumer protection laws apply to these transactions and want to cancel the contract within three days.

The whole "consumer protection" thing is bit of a red herring.

Instead, why don't we have a three day waiting period when the domain is "reserved" but not active. Grandma could notice her typo, credit card processor's could notice fake card numbers, and so on and rescind the registration.

The typo-or-whatever is likely not to be noticed until the domain is actually in use, assuming that such a thing ever actually happens.

After three days the sale is "final." Only then the name is made active in the zone files.

Do people really not plan that far ahead, that they need brand new domain names to be active (not just reserved) within seconds?

Yes. Legitimately so, too. Sometimes because of mistakes, sometimes because someone sees a need for a new domain name, and is ready to use it the same day. The problem is not instant registrations. The problem is free registrations. Cheers, Steve

On Aug 13, 2007, at 1:32 PM, Justin Scott wrote:

Usually it revolves around the marketing department not being in-touch with the rest of the company and the wrong/misspelled domain name ends up in a print/radio/tv ad that is about to go to thousands of people and cannot be changed.

There's a case to be made that a policy which results in organizations registering and owning domain names which are close to the intended domain anme but represent a common typographical transition is desirable from a security standpoint . . . ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company

Ken Eddings wrote:

At 4:32 PM -0400 8/13/07, Justin Scott wrote:

...

...

Do people really not plan that far ahead, that they need brand new domain names to be active (not just reserved) within seconds? I can say from my experience working in a web development environment, yes. I can recall several cases where we needed to get a domain online quickly for one reason or another. Usually it revolves around the marketing department not being in-touch with the rest of the company and the wrong/misspelled domain name ends up in a print/radio/tv ad that is about to go to thousands of people and cannot be changed. We end up having to go get the name that is in the ad and get it active as quickly as possible.

Been there. But it's rare enough in real life that I'd happily waive the right for full refund return for immediate domain publishing. Maybe marketing would learn to spell after a few costly mistakes.

Any other domain registrations getting a 3 day wait before publishing can have a more lenient return policy, maybe with a small processing fee. That's not unreasonable, and has something for the registrars.

And grandma would be able to correct her typo, and the regstrars would have time to check grandma's credit card, since she's so typo-prone.

I am not sure if this is what you are saying, but here is what just came to mind: 2 choices, same price: 1. instant, no refund. 2. 3 day hold, not active, but refundable till the point it goes live. I also just noticed something that doesn't seem to have been brought up: by registering, wait, refund, repeat - you can sit on a name for free. (under both current and my proposed.) To prevent this we need a small processing fee. Carl K

On Mon, 13 Aug 2007, Justin Scott wrote:

Perhaps it would be better to allow for domain returns, but shorten the time limit to 24 hours. That should be long enough to catch a typo, but too short to be much use for traffic tasting.

Still long enough to be useful for spammers :-( Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

On Mon, 13 Aug 2007 11:40:32 PDT, Steve Atkins said:

If grandma-jones orders custom stationery and doesn't manage to spell her name correctly, she'll end up with misspelled stationery. The main difference is that a misspelled domain name is likely to be a much cheaper mistake than misspelled stationery.

I once ordered replacement checks, and even though I checked them carefully when they arrived, I *still* went through several dozen before I noticed the '106' in my street address was printed as '160'. And yes, I ended up swallowing the cost on that one.

Chris L. Morrow wrote:

On Mon, 13 Aug 2007, Steve Atkins wrote:

...

On Aug 13, 2007, at 11:03 AM, Chris L. Morrow wrote:

...

So, to be clear folks want to make it much more difficult for grandma-jones to return the typo'd: mygramdkids.com for mygrandkids.com right? If grandma-jones orders custom stationery and doesn't manage to spell her name correctly, she'll end up with misspelled stationery. The main difference is that a misspelled domain name is likely to be a much cheaper mistake than misspelled stationery.

I picked on example, there have been plenty of examples in the past of folks just barely able to come up with 7$/yr for domain registration and using donated hosting for their non-profit thing. I think the root isue is: there is consumer protection today in the purchase system, do we want to remove that in the future. Or do we want to find another method to crack down on this problem without hurting consumers?

Assuming a change takes place (which I doubt, but will ignore) I bet a small non refundable fee (like $1) would drastically reduce the problem. Carl K

I picked on example, there have been plenty of examples in the past of folks just barely able to come up with 7$/yr for domain registration and using donated hosting for their non-profit thing.

I have my doubts imagining someone who is able to afford $500 for a computer, but not $10 for a domain, but even if we grant that such people exist, why is it essential for them to use a 2LD rather than one of the free 3LDs that are widely available?

I think the root isue is: there is consumer protection today in the purchase system, do we want to remove that in the future. Or do we want to find another method to crack down on this problem without hurting consumers?

This is an unanswerable question because it is based on the false assumption that the current abusive speculation does not hurt consumers. R's, John

A question to the registrars here: What fraction of legitimate domain registrations are reversed because the customer didn't know how to spell, and noticed that within the five day "dictionary time"?

Registrar stats fall into two groups. One group is the tasters, who refund essentially all of their domains. The other group is everyone else, who refund about 1%. So that's a reasonable estimate for the number of "legitimate" refunds. We can't tell how many of those are typos, how many are amateur tastes. This whole mess started when people complained that it was far too easy for a domain to expire by mistake and then get scooped up and held for ransom, so ICANN invented the current three stage process where your domain sits expired for a while when you can renew it normally, then goes into redemption for a while when you can renew it for a $200, and only then gets released. Some ICANN staffer took it on him or herself during this process to invent the AGP to solve the non-existent problem of mistaken registrations. According to Karl Auerbach, who was on the ICANN board at the time, the AGP was never debated or really noticed by the board and was just waved through. They had no inkling that it would enable large scale speculation. The important difference between the two grace periods is that if a domain expires by mistake, the registrant loses all of the value he has built around the domain during all the time it was registered, a potentially large amount of money. But if Grandma registers a domain by mistake, all she's out is the ten bucks or so she paid for it. Even now most registars charge a nuisance fee of a dollar or two when you refund a domain, so most of us don't bother to do it. The right solution for domain tasting is just to get rid of it, since the AGP serves only to facilitate abusive speculation. R's, John

The real way to get rid of tasting would be to persuade Google and Yahoo/Overture to stop paying for clicks on pages with no content other than ads, but that would be far too reasonable.

I don't see a practical way to enforce it. I believe the Net is an unstable system that will eventually be rendered useless by spam/etc. It is a cheap unlimited resource - you pay for your connection, and you get access to things you are in no way paying for. I don't see a way to fix it. Carl K

Or perhaps domains can be on-line instantly for a $100 non-refundable "rush" fee, or be cheaper and more refundable if you don't mind waiting longer (long enough to fix the tasting issues) And yes, I suppose ICANN or similar would have to collect or mandate the costs for it to affect all areas of the problem? On 8/13/07, Dorn Hetzel <dhetzel@gmail.com> wrote:

Yes, if grandma ordered a sign printed one way, and proofread it, and agreed to pay for it, and the printer printed it, then the printer is normally going to want money to make another different sign. If grandma, or anyone else, orders a domain, and confirms that's the domain they want, and get's it activated, then they should pay at least the first years fee, no matter what...

On 8/13/07, Carl Karsten <carl@personnelware.com> wrote:

...

...

The real way to get rid of tasting would be to persuade Google and Yahoo/Overture to stop paying for clicks on pages with no content other than ads, but that would be far too reasonable.

I don't see a practical way to enforce it.

I believe the Net is an unstable system that will eventually be rendered useless by spam/etc. It is a cheap unlimited resource - you pay for your connection, and you get access to things you are in no way paying for. I don't see a way to fix it.

Carl K

On Aug 15, 2007, at 10:46 AM, Andrew Sullivan wrote:

On Sun, Aug 12, 2007 at 01:41:17PM -0000, John Levine wrote:

...

The real way to get rid of tasting would be to persuade Google and Yahoo/Overture to stop paying for clicks on pages with no content other than ads, but that would be far too reasonable.

Another way would be to eliminate all registrar grace periods, which is a significant part of making tasting profitable. But I don't think the registrars would allow such a change.

Or to penalize registrars based upon the number of returns. Many moons ago I worked for a registrar -- at the time a large number of domains were registered using false / stolen credit cards -- this led to a large number of charge-backs. The credit card companies raised the rates that they charged us and threatened to stop servicing us if we didn't fix this -- suddenly a lot more effort was dedicated to confirming registrations, card info, etc. and the number of charge-backs dropped well below the requirements. Somewhere earlier in the thread I saw some statistic that 0.6% of domain deleted during the grace period were legitimate (whatever that means -- I also saw 5% somewhere else...). If a registrar's continued ability to operate was based upon keeping this number low, each registrar could make up their own policies to fix this issue -- they could create a "restocking fee" or non-refundable processing fee or come up with some method to verify the registrant or... If a registrar exceeds whatever the threshold is they would start incurring additional fees (either for all registrations or just for deletions or something) -- under extreme cases their license could be yanked. W

A

-- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <andrew@ca.afilias.info> M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110

-- "I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is." --Terry Prachett