Andy closed the jabber session with several action items:
] andy: We were given 3 use cases today. It would be good if meng could
] take his 2 to the list, and jfenton his to the list.
] andy: Then let's let the CSV proponents explain two things for each,
] 1) how CSV handles them, and
] 2) how SPF does not.
I'm waiting on these.
] andy: Also, I'd like to see a list of current MTA behaviors that would
] have to be modified for CSV.
] andy: if any
This email will try for a reasonably complete answer on this.
The short answer, of course, is the empty list. CSV does not seek to
change how email is done. It does not seek to say anything must be done
differently. (This is why we see it as orthogonal to SPF.)
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. Possibly, they'll even be miraculously lucky
and its IP address _won't_ find its way onto any blacklist. ;^)
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; but I did say _no_ changes were necessary), 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 if they want 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.
The syntax of the SRV record is remarkably simple: you have the
"target" name, which will be the same as the EHLO string, plus two
bits of information, which for the vast majority of cases should be
set to authorized=yes and list-empty=no.
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
And let us not forget the rather significant number of individuals
who already find themselves paralyzed by IP blacklists: they can
place the SRV and PTR records, demonstrating full accountability and
good reputation; and make a convincing case that any receiving SMTP
server that now blacklists them (perhaps because they're using a
cable provider) can simply implement CSV and stop having to respond
to complaints. ;^)
John Leslie <john(_at_)jlc(_dot_)net>