 Mutual Internet Practices Asssoc. |
| About | Scope |
CSV Frequently Asked Questions
J. Leslie
2004-11-18 11:01
Revised:
D. Crocker — 2005-02-28 16:15
Goals
- Q: What are the design goals for CSV?
- A: CSV's principal design goal is to ensure the identity of an accountable entity for the sending SMTP client. This ensured identity will improve reputation services by tying the MTA to a clear statement of responsibility by the domain management, that the MTA is acting as authorized by the domain, and is subject to its control.
This is fundamentally different from the current IP-blacklist idea, where the assignment of IP addresses is often not under the control of the domain management; thus reports by reputation services can be out of date several hours before they're published. And control of the IP assignment is strictly top-down; so that we're almost assured to pass through a "don't care" management level before we find our way to the domain management that wants its MTA to work.
Sender Benefit
- Q: As the operator of an email-sending service, what is the benefit to me of using CSV?
- A: Senders should want to do this in order to demonstrate your good reputation to the recipient.
More mail will get delivered more easily, as you establish a strong reputation with accrediting services.
Differences from SPF and Sender-ID
Short answer:
CSV is a simple mechanism performing a single task using with modest, stable administrative requirements. SPF and Sender-ID are complex, multi-functioned, fragile and difficult to administer correctly.
Initial Accreditation
- Q: What if a sender doesn't have any accreditations yet?
- A: Even without accreditation by third parties, operators of email sending services can obtain significant benefit.
- They can explicitly list those systems that they authorize to send email versus those they explicitly prohibit. Among other benefits, this is a far safer and less disruptive mechanism than wholesale blockage of port 25. In the extreme, a listing of "SRV 1 1 0" states that no mail should be sent from the listed domain.
- Operators of email receiving services frequently maintain their own whitelists and blacklists. In effect, these are accrediting mechanisms. Although not as automatic as using third-party accreditation services, it is still useful for receivers to be able to register safe senders, with CSV.
- They can explicitly list those systems that they authorize to send email versus those they explicitly prohibit. Among other benefits, this is a far safer and less disruptive mechanism than wholesale blockage of port 25. In the extreme, a listing of "SRV 1 1 0" states that no mail should be sent from the listed domain.
Receiver Benefit
- Q: As an operator of an email receiving service, what is the benefit to me and my users?
- A: Receivers should want to do this in order to cheaply and dependably evaluate the reputation of the sending SMTP client.
CSV permits distinguishing sources of email that are relatively safe, from those that are unknown or known to be unsafe. This allows much faster and safer handling of users' primary email.
Sender Burden
- Q: Does sender-verification shift too much burden onto the operators of email-sending services?
- A: Creating a burden to verify the sending operator sis similar to the "sender-pays" model used by postal services. There's nothing wrong with shifting "some" administrative burden to the sender. The sender should be able to demonstrate an acceptable reputation before asking the recipient to bear any cost whatsoever.
Sender Effort
- Q: How does a sender implement CSV?
- A:Two easy steps
- Make sure that your sending SMTP clients are announcing an appropriate HELO or EHLO <domain name>.
- Add an SRV record at: _client._smtp.<domain name > as described in draft-marid-csv-csa.
Sender Bind
- Q: What does that look like in "bind" format?
- A: I advertise the DNS SRV as:
mailhost IN A <MTA IP address> IN PTR _vouch._smtp.csv_vouch _client._smtp.host.example.com SRV 1 2 0 host.example.com
Accreditation Benefit
- Q: What happens if a receiver can't do the accreditation checks?
- A: Without a real-time accreditation check, receivers are at risk trusting a CSV report of "authorized"; but until spammers adjust, it would be relatively safe to let this override an IP-based blacklist.
And surely the authorization info, recorded in a Received header, will prove helpful in directing spam reports.
Receiver Effort
- Q: How does a receiver implement CSV?
- A: Update your MTA software if necessary, and turn on the CSV feature.
- Q: What will that software now do?
- A: It will follow the steps in the Overview draft-marid-csv-intro by starting two DNS queries each time a EHLO is received:
- for
type=a,
qname=<EHLO-domain>.csv_vouch.example.com
(or whatever service)
- for
type=srv,
qname=_client._smtp.<EHLO-domain>
The reputation check is likely to come back first. If it's particularly bad, don't wait any longer, give an error (typically after RCPT-TO).
When the SRV response comes, check priority=1, weight=2, port=0. (If weight=0 or 1, you've got a repudiation; if weight=3, it's not a repudiation, but it's not authentication either: feel free to give an error.)
Check the "additional info" section of the DNS SRV response for address records for the target string. If the actual IP address isn't among them, you've got a failure to authenticate. Give an appropriate error.
If it is, you've got authentication, so you can trust "good" reputation. Record the result in a Received header and continue.
- for
Prerequisites
- Q: What needs to change before CSV can be implemented?
- A: Nothing.
CSV does not seek to change how email is done. It does not seek to say anything must be done differently.
One-hop CSV
- Q: Can email still be exchanged if only one of the SMTP participants has implemented CSV?
- A: Yes, although the benefit from CSV will be limited.
If the sending side implements CSV, it means that the standard <domain> field in the EHLO has registered information available. It does not alter the SMTP protocol at all.
If the receiving side has implemented CSV, but the sending side has not, then it will subject the incoming mail to its usual stringent tests for spam. The extra cost to the receiving side will be one failed DNS query for the SRV record.
Operators of MTAs are free to change nothing; and things will work about as well as they do now -- until spammers escalate things so that overly-broad IP blacklists are applied widely and the MTA's IP address finds its way onto them.
If/when they get caught by that kind of problem, they need to ensure that the EHLO string the MTA uses is a legal domain name (which it should be already), and that they can cause a simple SRV record to be placed under that domain.
Alas, if they waited that long, there won't be time to acquire a good reputation, so for an instant fix they'll have to find an accreditation service which already has a good reputation; convince that service to vouch for them; and cause a PTR record to be placed at the EHLO domain.
We advise MTA operators not to wait for problems to show up, but to place the SRV record quickly, to show that they acknowledge responsibility for the actions of that MTA, and place PTR records for a few average-or-better accreditation services as well.
There is no reason you need to place any PTR records at all -- unless you've left things to the last minute and need to arrange for "instant reputation". Reputation services will naturally assign (over time) good reputations to domains which send enough "ham" and no "spam".
Existing Accreditations
- Q: Who's operating the necessary accreditation services? What's the cost?
- A: CSV is designed to support any number of independent accrediting services. Each can operate according to whatever business model it chooses. Some may charge email senders for the listing. Others may offer it for free, as part of a package of services. Some may operate as cooperatives, such as industry associations. All of these choices are at the discretion of the accrediting organizations.
We envision several different types of business adding this service at "no additional fee". The first type is the domain-name registrars. They're already taking a per-domain-per year fee and already maintaining DNS servers. This service will differentiate them; and the sufficiently clueful ones will quickly see the business case to add it.
Of course, these "no additional fee" services will delete or reverse your rating if you prove too "spam-friendly".
On the other hand , the current business model of previously-existing RHS whitelists, effectively charging postage for mass-email which bounces or generates complaints, will no doubt continue for mass-emailers.
- Q: Who's operating the reputation services you talk of querying at each EHLO?
- A: The procedure in Section 5 of draft-marid-csv-dna may be performed directly by sites receiving a small amount of email; but for sites with a significant volume of incoming email, these would be delegated to a proxy and performed in the same manner but with results cached and reported separately -- typically by a single UDP DNS query to the proxy.
Operating such a proxy would be as cheap as operating a web proxy; and there would likely be the same informal (no money changing hands) arrangements for sharing the workload.
In either case, distribution of lists recommending weights to be given to different direct-accreditation services would be out-of-band and not worth charging for.
Management Buy–In
- Q: How do I convince my boss this is worthwhile?
- A: CSV enables email operators to create an core of trustworthy participating systems. Among these accredited participants, email can be exchanged safely and efficiently, as it used to be. This is achieved not by magic and not by complex social or computer science. It is achieved by simple, direct registration of authorizations and third-party performance assessments.
CSV is a remarkably simple mechanism which gives the receiving SMTP server strong assurance that it's talking to an authorized MTA of a domain with traceable reputation and defined accountability.
But more important, it gives reputation services the same thing when they collect well-formed spam reports, and does not contaminate the process with unrelated information. Thus, they can develop good reports, and can perfectly correlate their data with administrative responsibility (unlike current IP-based blacklists, which usually have no way of knowing whether the IP addresses listed are still being used by badly-behaving computers.
And it gives domain owners a clear path to demonstrate their good reputation despite having to operate using IP addresses listed in the current IP-based blacklists, or even operate using dynamically assigned IP addresses, which may only be under their control for brief periods.
CSV Testing
- Q: Are there any CSV test sites to test/compare results?
- A: I have placed CSV records for example.com
Most of our mail goes out through "mailhost.jlc.net"; thus there are DNS records (in bind format):
mailhost IN A 199.201.159.9 IN PTR _vouch._smtp.csv_vouch _client._smtp.mailhost SRV 1 2 0 mailhost
- saying that mailhost.jlc.net is authorized as an SMTP client, and that the list of IP addresses is not empty; and
- saying that the csv_vouch.example.net reputation service will vouch for it.
DNA Testing
- Q: Are there any DNA test sites to test/compare results?
- A: CSV_vouch is a separate zone:
$TTL 7200 @ IN SOA example.com. tech.example.com. ( 1 7200 ; 900 ; 86400 ; 7200 ) IN NS ns1.jlc.net. IN NS ns2.jlc.net. mailhost.example.com TXT "MARID,1,A"