I am just finish reading the JABBER session. Here are some comments I wish
to add:
o CVS
Reviewing CSV more over the last few days, it will present a more or larger
implementation issue. I need to ask more questions about, but it has
overlapping issues with some SPF logic and more importantly the dependency
on other concepts such as accreditation is somewhat, what's the word without
offending anyone, well not something I think ready to impose on my
customers, atleast not yet.
o HELO vs MAIL FROM lookups.
One jabber comment was made with a indirect reference to me:
"spf has a clause for checking HELO when mail from = <> - some have
suggested to just turn that on all the time (i.e. Hector)"
Correction: The issue was this:
DMP was the first LMAP concept added to my system. DMP offered a dual
lookup logic, MAIL FROM and HELO. DMP was protecting very nicely Local
Domains Spoofs - the LMAP #1 benefit. In addition, I added configuration
options to avoid remote domain look ups because the majority were NONE or
NXDOMAIN results creating a new large DNS overhead issue.
When SPF was added and DMP was deprecated, Local SPF domain lookup options
were offered as well but the default was to check all incoming domains since
the SPF database was rapidly growing. Plus we wanted to get some real
stats.
It wasn't too long when we started to see Local Domain Spoofs into our mail
system once protected by DMP.
Recognizing the redundancy issue, I suggested to Meng that a new SPF
provision be made to allow for HELO checking in NON-NULL situations and also
added that it probably only necessary in order to protect local domains.
In order words, if the HELO was local, then you can check for it.
Otherwise, follow the normal specs. I considered it a "Loophole" that
needed to be closed in a young new specification.
A major debate started. Fearing that the tide was against the suggestion, I
added a variant SPF logic to my package to solve the problem by performing a
Local Domain Check rule first.
After more field testing and an important high focus to reduce DNS lookups
and overall overhead, I moved the Local Domain Checking to SMTP itself. So
a Local Domain/IP association without DNS lookups is done now because our
SMTP server is 100% aware of the local domains it needs to be aware of
anyway as part of the Final vs. Route determination.
I removed the variant logic and it is now back to the original SPF lookup
logic of only doing a HELO check when MAIL FROM = NULL.
Eventually (all a few pulled teeth), Meng added a provision I thought would
help SPF. I don't recall reading it in any new spec revisions but did see
the message.
For me, its a toss up: Check all or minimize it to local domains check only
o Mix Policies
On a related note, besides the DNS overhead issues, I think it is also
important to recognize the following assertion:
A MARID result based on HELO lookup should not conflict with a MARID
result based
on a MAIL FROM lookup.
Yet, the additional assertion can be made:
A MARID result based on HELO lookup can alter or change a MARID result
based
on a MAIL FROM lookup.
So whether I use CVS or SPF at HELO, I would be more interested in seeing
how this can resolve, maybe the forwarding or MUA problem. I have some
analysis in his area I hope to finish in the next few days or sooner.
-- Hector
----- Original Message -----
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, June 28, 2004 5:19 PM
Subject: Problem scenarios for SPF vs CSV
During the Jabber chat, which is viewable at
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-06-28.html
We agreed to explore the scenarios in which using an SPF
query against the HELO domain leads to problems due to
overloading.
Problem scenarios should start out with:
HELO xxx
MAIL FROM:<yyy>
They should go on to describe how CSV views the situation,
how SPF-against-HELO views the situation, and how the SPF
story is problematic in a way the CSV story is not.
We should leave aside for now questions of whether the SPF
lookup is significantly "heavier-weight" than the CSV
lookup.
thanks
meng