On 10/25/2004 5:08 PM, Douglas Otis sent forth electrons to convey:
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.
Yup.
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.
Yup.
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. : )
The input to CSV is already in the headers added by well-behaved MDAs, e.g.
Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137])
is the first line in a Received header added to my last post to the list.
It has the connecting IP, the HELO, and the rDNS of the connecting IP.
What would be the content and purpose of the header you're proposing?
Do you want to put the intermediate and final results of the CSV test in
the header? Can you provide/suggest a sample header?
Miller and Leibzon seem to have I-Ds you'll find relevant.
One argument FOR a new header is that it is hard to reliably identify
the Received: header added by the incoming border MTA. This is
particularly the case for abuse desks. Would a new header make this easier?
I agree another benefit would be the use of the RHSBL using the
validated CSV name to supersede a more general address based RBL.
Yup, I think. That sounds like agreement with/follows from my statement:
"A&R services can't reasonably
assign a good reputation to a bare domain; rather they can only do so to
a tuple of a domain and a scheme for Identification and Authentication."
(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.
[S]hould 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.
Yup. You quote me below suggesting this!
If we have bits to spare, here's suggestion for another (this would be
separate from the bit I already proposed):
If this bit is set, it indicates that no subdomain of this domain is
authorized to send mail (i.e. be used in HELO).
This could be useful because if extant, it would be a very cachable
record, and eliminate other, less cachable lookups.
Downside would be that if it was supposed to be checked every time, it's
another DNS lookup.
If checking it is optional, high volume recipients would be advised to
check it, while low volume recipients wouldn't need to.
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.
Good point. I wouldn't be surprised if a very agressive A&R svc that is
an RHSBL inserts wildcard records by default.
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.
What do you think?
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.
Right.
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.
I don't understand your statement that this need not be part of the
spec. CSV will work without this feature, but if it's to have the
feature, it needs to be in a spec, yes?
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.
I don't understand the difference. Please elaborate.
It seems that 4) is the best option.
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.)
Why so eager to avoid impacting the current drafts? IMO, they need
work to become more readable anyway.