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(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]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(_at_)microsoft(_dot_)com <mailto:seansun(_at_)microsoft(_dot_)com>)
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(_at_)elvey(_dot_)com> 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.