DEPLOY - IP, HELO & touch count. DOC-BUG too.

There are some problematic issues regarding my possible Sender ID 
deployment that I'd like to (re-)raise.
I wish I had more time to research and polish this post and participate 
more, but I'm leaving for nearly 2 weeks tomorrow AM.
My second and third points are more or less 'me too' comments, but my 
first one is extremely important and underexposed.

1)A good fraction (I'd estimate 1/2) of my end users have their MTAs 
configured to send through several SMTP servers, using different 
From:'s.  (I send through several, myself. About 1/4 of my users have 
more than one MTA.)  We will have to somehow discover each of my users 
SMTP configurations, the Sender ID configurations for the From:'s they 
use, and figure out if there's a way for them to continue to use those 
From:'s, and walk them through configuring their MTAs to use the SMTP 
servers that will allow them to use those From:'s.  If Sender ID had 
embraced Unified SPF, in particular: a mandatory HELO check, the checks 
on HELO would be able to tie to a reputation often enough that an end 
user using an SMTP server not authorized for their From: would be an 
occasional issue, instead of an overwhelming support issue.  The SMTP 
servers used by my end users would have good enough reputations that the 
PRA check would be unnecessary, and the message would get through even 
if the server didn't support SUBMITTER and was used by a mobile/guest 
user using their usual domain.  The PRA checks would not fail because 
they would not be run.  Setting up user.[remote|mobile]-users (the 
example of which I'm unable to grok) won't be necessary.  I have made 
these points before; see 
http://asrg.sp.am/wiki?Client_SMTP_Validation#Advocacy .   This change 
(a mandatory HELO check) would make MARID work well with ORDERS OF 
MAGNITUDE less work.  I was expecting to see this change in this 
proposal set, as it seemed to meet with little resistance, and was in 
Unified SPF, and getting serious support from key players.  I wonder if 
folks are happy to make it close to mandatory for everyone to upgrade 
their MTAs.  (In addition, Sender ID appears to require that all _MUAs_ 
be updated to show the PRA, for full effectiveness.)  No real downside 
to mandatory HELO checks (using the pass/fail/continue logic of Unified 
SPF) has been presented to date.
Phrased differently:
Sender ID fails to be a solution that only requires sysadmin action; it 
mandates end-user reconfiguration on a massive scale, because, IIRC, it 
doesn't say that HELO checking should/must be done.  Hence I (of 
elvey.com) would have to get all my domain's end users to use MSAs that 
I (as DNS admin of elvey.com) knew about.  For fastmail.fm, my email 
provider, who hosts mail for thousands of domains, they would have to 
support this for each user of each domain!)  If HELO checking is 
mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm 
has a good reputation.
2)IP.  The Microsoft IP is encumbered, therefore, as others pointed out 
in threads like "DEPLOY: Microsoft Patent license unworkable with GPLed 
MTAs", I'll have trouble using, e.g. debian and Sender ID.  Microsoft 
has belligerently refused to make the changes that it has been made 
clear are a problem.  I say belligerently not to poke at Microsoft, but 
because their statement in Q7 of their Sender ID IP FAQ is belligerent.  
It's been said that only individuals are members of the IETF, and that 
is certainly true, but that in NO way implies that an individual who is 
paid by and managed by a company to participate in the IETF must not be 
considered to represent that company; no IETF policy suggests that the 
interests of an individual's employer are not relevant to discussion.
3)DDoS vulnerability.  (~-protocol, Section 6.2)

I find the spec acceptable as is in this regard, but think it could be improved.  10 evaluations of check_host() could result in >> 100 DNS queries, a significant amplification, yes?  
I think the DNS queries are the expensive part of the calculation, and the limit should be on the # of DNS queries.

=-=-=-=--=-=

Another TYPO in -protocol-02
s/than one strings./than one string./

I like the way that the wildcard and TXT RR situations have been 
handled.  The Sender ID drafts have come a long way (I considered them 
hopeless when I first read 'em and almost didn't send in my 
suggestions!) but there's a ways to go.
Out of time.  Thanks for reading.