On Wed, 2004-10-13 at 12:24, Matthew Elvey wrote:
(multi-post reply)
On 10/13/2004 2:48 AM, Seth Goodman sent forth electrons to convey:
We need to be better off than before to make it useful. Otherwise,
it appears that the protocol is geared to facilitating acceptance,
which is not a compelling problem for recipients.
No, not at all. It means that blocks and filters can be more
aggressive with mail that doesn't pass the CSV test, but cause fewer
FPs*. That a big step toward solving a compelling problem for
recipients: spam.
A lapse in security is one of the biggest enablers for spam.
Identifying those responsible for security is a major step toward a
solution for abating this spam. The reputation of this entity should be
assessed by how well they respond to notifications of abuse. Security
is an ongoing challenge. The host-name clearly identifies the
administrator that must accept accountability. This is best asserted
however, when there is a clear authorization made by domain name
records.
A system could become compromised, as is often the case for spam, so
knowing this specific host is authorized to send mail would be the first
step in establishing accountability. RFC2821 forgives A records that do
not return the address of a named host, so the lack of authentication
with an A record is meaningless. Finding a mechanism to indicate
specific authorization for the host in question is important when
establishing reputation and to thwart zombie systems.
There should also be a header added to the message that does not pass
through the transport service. This header should only be added by the
MDA directly into the mailbox or MUA. This would need to be removed
when the message is forwarded or resent and a cause for rejection when
seen on reception. In cases where there is at a border MTA, an out of
band or digital signature method could allow this CSV validation
information to be seen by the user. This would go a long way toward
thwarting phishing and be highly immune from spoofing. The basic
premise is to NOT TRUST ANY HEADER within the message not directly
validated. This leaves just the HELO domain. : )
I agree another benefit would be the use of the RHSBL using the
validated CSV name to supersede a more general address based RBL.
(If senders have the option of using CSV to override BLs*, I become
able to use a large number of BLs I can't currently use because of too
many FPs*. Here's an extreme example: I'd configure one client's
servers to use a BL to block mail from a different continent today if
I had a CSV implementation in place that worked with legacy SPF
records along the lines I've discussed on MARID. For my largest
client, I'd be able to be more aggressive in blocking unwanted email
by using filtering rules that are currently too risky.)
*I created an acronym/Glossary at
http://wiki.fastmail.fm/wiki/index.php/ClientSmtpValidation#Acronyms .
Please add the definition missing a term.
It is probably best for a domain to publish policy directly, and I
suspect that is what Tony is getting at with his questions. CSV
records have the appearance of a policy statement for the domain, so
they should stand alone and be complete for the problem space they
cover. I may well misunderstand the overall goal, so please educate
me on this if I have it wrong.
Hmm... I state this as a question about a change to the spec, below.
... Given a HELO name and the lack of a CSV record,
how do I know if the base domain publishes CSV records at all
without doing an expensive zone-cut algorithm? If I know that the
base domain publishes CSV records and this sub-domain doesn't have
one, I can use it as a tool to reject. Without that, I can't. What
am I missing?
This is an ongoing debate extended from MARID now finding discussion in
CLEAR and MASS. Wildcards do not work as a defensive tactic as other
record types for a name will prevent the offering of a "policy" record.
Reliance on wildcards would also rule out the use of DNSSEC. Making
policy records at zone cuts and depending upon specific DNS
implementation to make zone discovery easier might be a possible
solution. I don't think there is consensus yet.
Receiving SMTP servers would be just-plain-wrong to treat CSA as
binary accept/deny. The spec (IMHO) is quite clear that you need
the authentication of IP address, the authorization bit in the SRV
record, and a favorable reputation report in order to bypass
blacklisting.
I don't recall anything in the spec making it clear that those are
requirements; rather it would require making a lot of assumptions to
come to this conclusion. I'd be happy to be proven wrong.
While CSA would indicate the authorization of the host, it does not
provide any assurance the host is run by a responsible entity. Having a
name does enable a simpler method to track this entity however. This
ease in tracking can also benefit this entity should they be required to
change addresses. If they have a favorable name reputation, the RHSBL
should more accurately track these entities and hence trump the RBL.
Conversely, should there be a convention developed for asserting a
general policy, then not having a CSA record for the host should create
a flat rejection. This problem is rather universal, and there are many
bits available within a CSA record to establish many different policy
assertions.
Is the answer to-
What harm is there if made-up-name.cam.ac.uk appears on an RHSBL?
really none? Some CSV-cognizant RHSBL may want to assign
made-up-name.cam.ac.uk a bad reputation if it is used in HELO in a
spam run and has no CSV record.
Not speaking for any specific company, the RHSBL could include a
wildcard of *.cam.ac.uk.rhsbl.tld. The spammer may also have a trick
DNS that offers a CSV record for random sub-domains. Much like listing
a block of addresses, I would expect the RHSBL would wildcard
sub-domains for egregious cases.
True, if it's on an RHSBL, cam.ac.uk can always use a different FQDN
in hello if it ever decides it wants to send from a server with a FQDN
that's got a poor reputation. True, the RHSBL would end up having a
huge db of made-up names. Is it a waste of space? Well, it would
mean that the service would have data so that there could be a
meaningful difference between it's C,D and E ratings. Its users could
value that. (Though I envision that most services will not bother and
only give 3 ratings: A,B and C.)
This touches upon another area of general debate by the design team. To
be continued when there is a better consensus. There is also ongoing
testing in this area as well. : )
So the MAIN QUESTION I think we should answer is: should we change the
spec to allow a domain to state as policy that any sub-domain used in
HELO that does not have a CSV record is unauthorized and rogue with a
single record?
Perhaps. I'm not sure.
1) If wildcard records could be detected directly, we could change the
semantics to say that a wildcard record is the way to do this; a
domain with a wildcard record is pretty much implying this already.
See above.
2) Checking randomstring.domain (or fixedCachableString.domain) for a
CSV record would be a fairly good detector of such a wildcard
record.
A digital certificate scheme is using a hash as a means to validate
their public keys. This scheme should also implement a consistent token
prefix as well. This still does not solve the DNSSEC issue. Should
this door be closed going forward?
3) We could specify that a CSV record at SomeOtherFixedString.domain
states such a policy.
Knowing what constitutes the domain would be the problem, if to avoid
the wildcard issues. Using _client._smtp.random.domain SRV could
provide this function as other SRV wildcards would be *._tcp.domain or
*._udp.domain instead of the *.domain for the CSA. The specification
need not adopt any location strategy for the CSA record to function as a
mail policy record. It could be placed at zone cuts to work with
DNSSEC, as example. The administrator could add such a wildcard to
encapsulate all possible other SRV names as an optimization.
Regardless, this would not need to be part of the specification. There
is talk about adding a specific sub-domain assertion bit as a means to
treat this as a specific policy record for the domain and sub-domains.
4) We could specify that a CSV record at domain states such a policy,
by setting the unused third bit-field in Weight to 1.
That has been rejected in favor of adding a new bit.
5) Or we could not change things, and say that the burden Tony is
complaining about is not unreasonable.
I think that is an issue that can be dealt with later without impacting
the current draft. (except for the addition of the new bit assertion.)
PS Could someone clarify the purpose of the Ignore Target bit? I don't
get it from the definition: The domain name in the Target field is a
placeholder, and any IP addresses it resolves to MUST NOT be used for
authentication.
This came into being as a suggestion from Paul Vixie. He noted many
current SRV records do not properly handle a target of ".". This puts a
heavy load on root servers as a result. Rather than potentially adding
to this problem, this bit was to avoid this notation. This bit allows
this to be used as a simply policy record not intended for a specific
target, such as making an assertion for the use of CSV.
-Doug