Thanks for this Andrew.
Do you appreciate the difference between a HELO check vs. a
MAILFROM/PRA/SUBMITTER check?
A resounding yes.
Do you understand the semantic differences between a CSV check on
HELO and an SPF/Sender-ID check on HELO?
Yes.
Is it clear to you that CSV has definite security advantages over
SPF/Sender-ID?
Yes, but more true if you said "offers some security advantages over.." But
what is very important to understand the two are important. They can work
together. I hope to show this in my trust analysis (second point below).
I will outline my reasoning to help explain my answers to your questions:
o In general (CVS or otherwise), a validation at HELO offers an inherent
presumption of M2M (machine to machine) trust concept. I agree with the
concept especially in internal networks where routers are involved. This may
include analysis of the first hop (assuming no tampering) to help in the
generation of the trust in non-internal routed situations. It has to do
with the circle of trust idea. Dave Crocker has provided excellent writes
up/presentations on the concept 1-2 years ago or more. Its on his web site.
However, I believe this is all based that the enforcement or following of
the traditional SMTP operation of:
- Non-Authentication/Trust is not required for Final Destination.
- Authentication/Trust required for routes
Otherwise you have open relay situations and security violations in internal
networks.
o I have a LMAP trust analysis showing how HELO validation can help change
the results of a SPF MAIL FROM validation. I hope to clean this up for
publication here. CSV was not available at the time of this write-up, but
it
wasn't necessary per se. It is an trust analysis showing how HELO LMAP
results can prevail, alter or change or not, the results of a MAIL FROM
LMAP results.
o The problem with CVS specifically, its in augmentation of a 3rd party
concept (accreditation). This introduces a barrier for implementation
(atleast for me). I prefer to work with a SMTP based functional protocol,
not a system-wide, product or application protocol.
o The problem of PRA/SUBMITTER or any related idea (including CVS first hop
analysis) is its dependency on post 2821 operations. Basically, what it
means from a implementation standpoint, it is outside our design scope. We
push all responsibility for post SMTP mail analysis to the system operator
(sysop) - by product design which has its beginnings related to product
liability. In short, if the sysop wants to use "SpamAssassin, or SendedID",
he is on his own here.
o To help address the growth of 2822 analysis and also keeping with the
design of the system, we offer a DATA hook so that they can run a mail
content analysis (like SpamAssasin or McAfee AVS) by hooking it into at 2821
DATA state. The key reason for this was to help solved the huge growth
problem of having "good but spoofed return path address" perpetuated with
the growth of SORBIG-based email viruses. This exploitation has taken on a
Code Red Principle mentality of attacking POST SMTP systems and all the
legacy systems that operate in this mode, to help the virus with 2nd tier
bounce distribution. Running a mail content analysis/rejection at DATA
helps this situation because it eliminates the second level (bounce mail)
assault.
Basically what the above says from my standpoint, is that I think SPF can
help provide additional HELO validation security with a modification of its
SPF lookup specifications. CSV can help add more weight with first hop
analysis.
But all overall, the merging of other concepts such as accreditation is not
a
welcome idea for me as it makes the whole issue of providing a customer a
reliable anti/spam security product or feature more dependent on external,
more likely than not, profit driven service bureaus. I wish to keep and
implement a solution purely on technical and SMTP/internet standard
compliancy grounds. Not saying it can't be offered, but it will make CVS
less adoptable in my view.
The same is basically true with SenderID.
In this case, it requires a change in software and compliance by VALID
systems. Therefore, unless we are ready to enforce the idea non-compliance
will add some level of acceptable mis-trust and thus rejection and/or
scrutiny, I don't see it working very well at all. To support it, we then
go back in circles with encouragement of payload transmission. Sure, it
can be supported at the DATA hook, but it definitely not something I can't
see it putting any weight on the trust concept:
- A spammer complies. It doesn't address the validity of the
address?
- A spammer does not comply. It could be a valid legacy system?
My prediction with SenderID or any promotion of a new world-wide standard
that requires 2822 analysis:
Spammers/Hackers will discover that there is new growth of Microsoft
Exchange servers in the market place will accept payload. They increase the
payloads to levels that is just under a system limit (ours is 5 megs per
email I believe).
The goal?
Frustrate systems to turn off the option due to new scalability and load
balancing problems. Systems that don't support it won't have this problem.
Systems that rely solely Microsoft's SenderID are in big trouble. Systems
that rely on other 2822 validation ideas suffer too because they will see
the growth of higher payloads on their systems too.
Of course, I reserve the right to be completely wrong. Nonetheless, right
or wrong, it is a valid engineering design consideration that helps reduced
consumers risk.
Ideas like SendedID and any other 2822 validation logic "cries" for a change
in the SMTP transaction protocol, basically a new command to provide the
headers. If this was to happen, I'll be among the first to jump on board.
In my view, MARID can probably be assisted with other ideas that may help
address the current items in discussion:
- How will the Spammer React?
- Where are we enforcing change? Are the operator or spammer? This is
related to Meng's reflection of the "Chaos Theory" - Chaos promotes
change/adaptation. Well, we are changing, but is the spammers? How?
- Can I lower of cost of operation (TCO) by using CVS, SPF, SPF2? Or is
this still going to be a problem, and if so, this MARID help in the
tracking/audit process which is required by CANSPAM if you wish to use the
new law against a spammer.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
To: "MARID WG" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Wednesday, June 30, 2004 10:28 AM
Subject: Differences between CSV and Sender-ID
I have been observing that the recent discussion on CSV in comparison
to the SPF/Sender-ID solutions have been between a small, consistent
subset of the participants of this mailing list. I can only conclude
that others either do not care about these issues or do not understand
these issues. After reading every single message over the past couple
of threads, I must admit that I do not comprehend many of the points.
Therefore, I'd like to get feedback from others:
Do you appreciate the difference between a HELO check vs. a
MAILFROM/PRA/SUBMITTER check?
Do you understand the semantic differences between a CSV check on
HELO and an SPF/Sender-ID check on HELO?
Is it clear to you that CSV has definite security advantages over
SPF/Sender-ID?
I'm only asking these questions so that we can hopefully refine the
conversation on this topic.