RE: User experience; RHSBLs; Strong From: check seems possible

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

I think we are stepping way outside the charter scope here.

What I see as being in charter is the fact that with the ability to
authenticate a domain name via the IP address you have the ability to
perform filtering based on the properties of the domain name.

I do not think the term 'RHSBL' is informative or useful. It is built on a
false assumption that the only type of domain name property that is of
interest is blacklisting - i.e. negative reputation.

Blacklists have a large number of known pathologies and problems, none of
which appear to be reduced or eliminated by moving from IP based properties
to domain name based properties. In fact they are likely to get worse since
a domain name is more easily replaced than an IP address.

The domain name properties that are of interest are generally positive
accreditation attributes. It is possible to tie positive attributes to IP
address or to the domain name, but a domain name has the positive advantage
that it is that is the property of the party we are trying to hold
accountable - the email sender. The IP address is generally held by the ISP
providing service and is subject to change without notice. Furthermore we
send email to a domain name and not to an IP address.

Over the past five years the Internet moved to a model where senders have to
establish their bona fides in order to send mail. It is a simple fact that
any mail system administrator of any system of any size is required to spend
a considerable amount of time negotiating to have their email accepted. At
present those relationships are bilateral. The emergence of mediated
multilateral agreements in the near future is inevitable. It is considerably
cheaper and more convenient for an email administrator to establish their
bona-fides affirmatively with a single reputable agency than to establish
and maintain bilateral relationships with all the parties they might want to
send email to.


I believe that the accreditation issues themselves are outside the scope of
MARID, how that information is published is not the concern of this group.
What is the concern of this group is that a MARID record should be at least
as capable with respect to accreditation use as existing SPF and CallerID
records.

Natural prudence suggests that MARID should support some form of
extensibility mechanism, the simplest possible of which being a list of
attribute value pairs. I regard providing such a mechanism to be a deal
breaker issue. 


The simplest possible form of accreditation protocol support in MARID would
be a statement in the profile record that informs the client that there is a
third party accreditation record which may be verified by the specified
protocol. something like:

example.com   MARID 10.2.1.2/24 smtp.example.com ACCRED=class3.bondsman.com




> -----Original Message-----
> From: owner-ietf-mxcomp@xxxxxxxxxxxx
> [mailto:owner-ietf-mxcomp@xxxxxxxxxxxx]On Behalf Of Matthew Elvey
> Sent: Sunday, April 11, 2004 3:08 PM
> To: MXCOMP
> Subject: Re: User experience; RHSBLs; Strong From: check 
> seems possible
> 
> 
> 
>  > RHSBLs better than what we have now? 
> http://spf.pobox.com/faq.html#churn answers that question.
>  Here's my response:
> They seem no better than IPBLs (like the RBL). The 
> countermeasures apply 
> equally to IPBLs.
> The same pressure that SPEWS, for example, applies to ISPs would be 
> applied to registrars. Except I know of no registrar that is 
> cooperative 
> and supports SRS, so no one would actually use this hypothetical 
> registrarBL. So we start from a worse position. (Godaddy is 
> cooperative, 
> but does not and has no plans to support SRS, et. al. in their DNS 
> tools, even though they advertise "Total DNS Control", so I 
> have to use 
> someone else's DNS servers.)
> 
> Interesting that the sendmail press release mentions one Sean 
> Sundwall 
> (seansun@xxxxxxxxxxxxx <mailto:seansun@xxxxxxxxxxxxx>) as 
> behind C-ID, 
> but he's never been heard from here.
> 
> 
> On 4/10/04 3:35 PM, Doug Royer sent forth electrons to convey:
> 
> >
> >
> > Matthew Elvey wrote:
> >
> >>
> >> Doug Royer allegedly said:
> >> >Benefit - saves time by allowing automated tools to track 
> spam sources.
> >>
> >> ><I can write tools that always get contact information given a 
> >> domain name, but can't given an IP. \
> >
> >
> >>
> >> I believe that's false.  Both ARIN et. al. info and domain info is 
> >> fairly often bogus.
> >
> >
> > Thank for quoting me accurately. Yes, I  can write such a tool :-)
> >
> > I never said that sometimes some of the information is a lie.
> 
> Right, what you said was true; oops-I read the word "valid" into the 
> sentence, even though it wasn't there. 
> But my point is that it doesn't allow automated tools that aren't 
> already out there.
> 
> >
> >> Registrars ignore blatantly false info in both, unless 
> there's been a 
> >> recent change I'm not aware of.
> >> So I don't believe switching from one to the other is 
> likely to to be 
> >> a benefit. 
> >
> >
> > Would you agree that it allows tracking to the spam source of an  
> > infected machine
> > where the owner is honest?
> 
>  And do a better job than IP or other schemes, e.g. 
> Spamcop.net?  No... 
> well actually:
> In the case of a small organization with its own domain, yes it is 
> likely to help some.
> The domain info is likely to be accurate, so IF the 
> organization has an 
> LMAP record, then its likely to help.
> Otherwise, spamcop.net (and scripts that do roughly what it 
> does) do as 
> good a job already - for consumer ISPs, .edu, large organizations the 
> info is probably already about as accurate, no?
> 
> On 4/10/04 9:32 PM, Alan DeKok sent forth electrons to convey:
> 
> >Matthew Elvey <matthew@xxxxxxxxx> wrote:
> >  
> >
> > ...
> >
> >>I think the folks who just want to protect HELO or MAIL FROM have
> >>failed to explain why From: is not feasible to protect.
> >>    
> >>
> >
> >  Messages get forwarded by third parties (e.g.this mailing list).
> >The MTA/DNS of the "From:" domain doesn't know who in that domain has
> >subscribed to what mailing list.  And it's impractical to distribute
> >that information outside of the mailing list.
> >  
> >
> Without SRS/verp, MAIL FROM has the same problem, to a lesser extent.
> With SRS, a From: check that failed the initial lookup could 
> look in the 
> MAIL FROM to see if the domain in the From: was there.
> If it was, then we can conclude that the From: is valid! 
> (with the same 
> confidence that we know the remailer is not a spam source 
> because an SPF 
> test that includes blacklist checking has been passed). 
> If the remailer is a spam source, we would have blacklisted 
> its domain, 
> so it's reasonable to put some trust in the SRS MAIL FROM.
> There's still the problem of mailing lists such as this one 
> which don't 
> need to implement SRS in an SPF world because they change the 
> MAIL FROM, 
> but leave the From: alone.   Perhaps a whitelist of machines running 
> mailing lists is necessary.  Perhaps RHSBLs for SPF could be 
> particularly sensitive to spam that looks like it's from a 
> mailing list, 
> and From: checks could be allowed to fail for such email.
> 
> >  This issue highlights more implicit assumptions and field
> >overloading in SMTP.
> >
> >  Alan DeKok.
> >
> >  
> >
> 
> 
>