----- Original Message -----
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, October 28, 2004 1:42 AM
Subject: [spf-discuss] Meta: Managing the list
Meng has granted me some control over the list (spf-discuss) and I'm
prepared to enforce some rules, if need be.
Oye vey!
Greg, I've seen you in action even when you are not the moderator! I
believe you have very good arbitration skills, I really do. But with all
due respect, I believe your opinions on certain issues are incorrect and is
just as restrictive. My point is that as a moderator will need to side
aside your personal bias on conflictive issues and debates. If you can't do
this, then I think terrible decision being made. While you should have
your own input (or vote), you can't your position to just shut people up as
you tried a few times with me via personal email or worst, trying to move a
critical discussion off list where more time is wasted.
So I think you will careful here or you can make it worst.
Let me float some ideas for managing the list and possible guidelines, and
see if I'm going down the right path.
[snip]
If you can stick to your list rules, fine!
But you need to understand, atleast from my viewpoint, the issues and
debates brewing here exist for a reason based on some real bad decisions
made and a direction that is basically ignorant of these concerns.
If you are going to hold a position that against what some some may feel is
important, and try as you done in the past, quiet these concerns by going
off list with no-win direct 1 to 1 discussions, then I see problems.
Look! This isn't a LIFE STYLE or a game. For us, it is a real concern
with many issues that involves product development and commercial
implications - aka $$$!
This is how I see it:
1. SPF1 is it for now.
It beens in production for nearly 1 year with little to no benefit other
than what I always said an LMAP system provides - Local Domain Spoof Protect
ion. Now that may change as the "database" gets larger and larger, but
that just introduces some of the other technical problemss I have issue
with, namely DNS overhead.
2. SPF1 needs to get two issues resolved:
2.1 Machine Client Domain checking (HELO/EHLO)
2.2 Restrictions on SPF1 Relaxed Provisions.
These are are VERY important in my view in CLOSING some "loopholes" in the
specs. And yes, this is one of those things I call a "LoopHole" and if that
bothers you, then you should not be a moderator.
A loophole means in SPF sense, that the goal it is trying to reach can be
minimized by logic that it does not address or cover.
3. SPF is not a product.
You need to be careful on going overboard new features that attempts to
cover areas that is probably best suited somewhere else. But more
importantly, it could be a waste of time as systems are not just going to
"update" SPF if it really doesn't add any new benefit.
4. SPF does not need SENDERID. SENDERID needs SPF.
Related to #3, SPF doesn't need SENDERID. On the contrary, it is SenderID
that needs SPF.
MS can make a request for SPF developers to add "something" that may make
SenderID work better, but it would be a mistake to try to "force" SenderID
into the SPF spec.
SENDERID is a unproven technology. All expert technical people will be able
to see the problems with it immediately. I saw it right away not just
because the PRA aspect of it is unreliable but the PAYLOAD issue will be a
major problem and goes against the direction SMTP systems need to better
manage abusive transactions at 2821. Again this PAYLOAD issue is yet
another issue that you didn't agree with, but I am extremely adamant about.
I know I am correct here. The suggestion that more PAYLOAD is better in a
widely deployed network for the sole purpose of checking the PRA, well,
either some major ignorance going on or some people just haven't realize it
yet.
In any case, if SPF is going to be improved, it needs to be done in a WAY
that keeps it "separate" or independent from specific technologies.
Suggestions:
o Relook at the SPF record Language to make sure it is not restrictive in
expanding it.
This will allow it to be used for any future technology that will come out.
SenderID is not it, so there will be others.
o Make the Relax Provisions restrictive and time limited.
This is just a simple functional specification (docs) change, but will also
authorize implementers to add logic to enforce the time limit by recording
the abuse.
o Machine Client Domain checking.
You got to get this into the specs NOW! What are the issues?
- Wide bad format usage,
- DNS overhead potential.
I agree and I had said so from the beginning, that is why I said as a
compromise, you must atleast allow for Local Domain Spoof protection where
SPF and LMAP in general offers its greatest benefit.
This will allow implementers to have:
Check Local Helo Domains Yes | NO
Check Remote Helo Domains Yes | NO
The idea of trying to define this rule in a SPF record is stupid. You can't
trust what a SPF record is going to say. This has to be a server side
rule!
This will give admins the ability to decide for themselves if they want to
expend the DNS overhead to check other domains.
In summary,
In my view, if you get SPF1 finalize at a level that will minimize its
technical issues and close its current loopholes, then address the helo
checking and relax provisions and make sure the language is ready for any
possible growth with backward compatible support.
Once you do this, it won't have the "thorn on the side" once it gets adopted
at a fast rate. Trust me, if this isn't done, once people begin to adopt it
widely, people are going to be constantly asking or reporting the same
issues:
"Hey, the HELO is spoofed! Why is the mail getting in?"
"Hey, this SPF DOMAIN is constantly being spoof and its
NEUTRAL/SOFTFAIL results is allowing the mail to get in.
the SPF domain has been like this for over 1 year now! Why?
Can't I just force the rejection?"
etc, etc.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office