On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote:
|
| 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.)
To provide clarity, can you explain if by the above "SPF"
you mean "Unified SPF" or "SPF Classic"?
"Unified SPF" always examines the HELO domain, offers an
authentication status, and gives receivers an opportunity to
perform whitelisting or rejection operations based on that
result. It does this independent of examination of the
return-path or the PRA.
"SPF Classic" by comparison only performs spoof detection on
the HELO name, and always checks the return-path.
Unified SPF even solves the forwarding problem by allowing a
receiver site to whitelist forwarders by HELO name,
overriding the return-path result.
It appears to me that the set of features offered by Unified
SPF overlaps with the features offered by CSV. Please
correct me if I'm wrong; my understanding of CSV is
obviously not as good as yours :)
| 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. ;^)
The above is also true of Unified SPF.
| 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.
The above is also true of Unified SPF, except that the
record is the SPF TXT or MARID record.
| 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 above is also true of Unified SPF.
| 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.
The syntax of the SPF record for the MTA is TXT "v=spf1 a -all".
| 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. ;^)
Yes, it would be a great benefit to the wrongly-blacklisted
folks if they could positively accept responsibility at the
HELO or return-path levels and thereby override
provider-based negativity.
This argument is made at
http://spf.pobox.com/slides/unified%20spf/0429.html
if we replace "MTAMark=no" with "listed on DUL blacklist".
cheers
menmg