Re: [Asrg] What are the IPs that sends mail for a domain?

On Jun 18, 2009, at 6:29 PM, der Mouse wrote:

> > > I worked for McGill [...]
> > This control is "out-of-band" from the abused protocol, and not the  
> > result of all recipients of the protocol resolving possible  
> > identities of each of university users.
> Both true.  So?
SMTP is heavily abused, and soon IPv6 is about to become a  
necessity.   To remain practical, connectivity must be based upon  
_immediate_ and _stable_ evidence of legitimate email operation, and  
not upon any number of authorization transactions.  Each additional  
transaction to support an authorization scheme will be multiplied by  
the typical number of attempts made by abusive senders.   This means  
providers need to exclude problematic users, and not become a task  
pushed toward recipients.  Such pushing is not practical and often  
leads to unfortunate mistakes.
> Responsibility, in the sense of accountability for (potential)  
> abuse, is a meatspace thing, not amentable to being part of a  
> network protocol, so at least _some_ of this must be done out-of- 
> band with respect to the protocol.
IMHO, 99% of exclusionary practices must be handled out-of-band for  
SMTP.
> > Schemes that pass accountability onto what might be feckless domain  
> > owners are inherently evil.
> I disagree, _provided_ accountability is actually passed on.
The fact that a trusting and naive user had their domain authorize a  
provider just to have their email accepted, does not mean other  
messages emitted might not be mistaken as also belonging to that  
user's domain.  Should providers check for SPF or Sender-ID  
compliance?  How many SLA include this requirement?  When the "passing- 
on" is based upon receptions at spam traps, acceptance reliance based  
on "authorization" is likely to downgrade acceptance of the domain,  
especially when A-R headers exclude the IP address of the provider.   
Will providers really care the wrong entity had been blamed?
> What you appear to be thinking of is not accountability but mere  
> identification (albeit moderately strong identification).
Moderately strong?  Without knowing the IP address of the provider, it  
would be extremely foolish to conclude any level of identification  
assurance, especially "moderately strong".
> [...] email address holders on the top few webmail systems are not  
> held accountable by the webmail provider for how they use their  
> accounts.
Exactly.

> Schemes that pass accountability on would be good.
CSV would be a good starting point.

> > Providers MUST be held _directly_ accountable.
> Right.  But until this is fixed at the top, I see little hope it  
> will happen in the lower levels, except sporadically.
Fixing this problem is likely to become an imperative.  SPF is worse  
than wrong.  It does not offer a safe form of identification, as  
wrongly advertised, and puts DNS and SMTP at risk.  Those advocating  
acceptance based on just the DKIM domain clearly expect to combine  
valid signature with SPF authorization passing.  This is not how the  
DKIM/SPF combination has been being advertised to work together.   
Email is almost certain to become even more unreliable and more  
expensive to operate. :^(
> (The places that do do it are exceptional, and, in the cases where  
> I'm in a position to know why they do it, they do it not because  
> they are held accountable by whoever assigned the resources to them  
> but because they are ethical enough to feel a compulsion to do  
> what's right even when they're _not_ overtly held accountable.   
> While this mindset is common enough for us to have words for it, it  
> is not nearly common enough to save the net from the disasters that  
> governmental disconnect between authority and responsibility leads  
> to.)
One might hope they'll do the right thing out of self preservation.    
Backing schemes that advantage their size only makes problems worse.
-Doug


_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg