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.
More mail will get delivered more easily, as you establish a strong reputation with accrediting services.
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.
mailhost IN A <MTA IP address>
IN PTR _vouch._smtp.csv_vouch
_client._smtp.mailhost SRV 1 2 0 mailhost
And surely the authorization info, recorded in a Received header, will prove helpful in directing spam reports.
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).
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.
CSV does not seek to change how email is done. It does not seek to say anything must be done differently.
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".
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".
OTOH, 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.
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.
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.
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
$TTL 7200
@ IN SOA jlc.net. tech.jlc.net. (
1
7200 ;
900 ;
86400 ;
7200 )
IN NS ns1.jlc.net.
IN NS ns2.jlc.net.
mailhost.jlc.net TXT "MARID,1,A"