On Tue, 2004-06-29 at 08:11, Meng Weng Wong wrote:
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.
Details? Where is the draft?
"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.
This could be a bad idea. How is the HELO name authenticated and
authorized?
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 :)
Is there an Internet Draft on the Unified SPF. It is hard to do a
meaningful review with so many details missing.
Also there is yet to be a Internet Draft that documents the current
"Core" documents. There is also a very telling item missing.
What do you expect to be the average number of indirections per SPF
record? What is the maximal depth of recursion?
How is path permissions differentiated from administrative ownership?
| 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.
The major problems result from weak transversal authorization determined
by SPF. You may consider these the same, but the details entailing such
is important. ACCREDITATION can not be administered if the
Authentication and Authorization are not confirmed for unknown, in
addition to that determined to be accepted. It is apparent that SPF
only provides weak path assurance regarding an accepted message. The
assurances for either unknown or rejected messages are nil. That is a
huge category left open.
| 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.
Where is the draft? I do not think these are equivalent and making such
claims remains allegation without substance.
| 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.
Again, this overlooks details involved to establish administrative
ownership, authentication and authorization.
| 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".
What does this say exactly? Go look for an address? I would not call
this as being the same. In addition, these statements are not about
which domain administers the mail server, this makes a statement about
what domains may transverse this mail server.
| 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.
It is also equally important to assess accountability properly. Do not
force individuals to accept accountability for every machine they must
list to allow their mail to transverse these other machines.
This argument is made at
http://spf.pobox.com/slides/unified%20spf/0429.html
A slide show provides no details and therefore provides no additional
information.
-Doug