(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 agressive
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.
(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 agressive 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?
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.
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. 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.)
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 subdomain 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.
2)Checking randomstring.domain (or fixedCachableString.domain) for a CSV
record would be a fairly good detector of such a wildcard record.
3)We could specify that a CSV record at SomeOtherFixedString.domain
states such a policy.
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.
5)Or we could not change things, and say that the burden Tony is
complaining about is not unreasonable.
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.