|
Re: Meta: Managing the list
2004-10-28 00:21:20
Thank you for the feedback. Looks like I am not the only one passionate
about SPF and keeping the list free and open!
1. I will try not to let my personal opinions get in the way of managing
the list. I have a successful track record of handling lists in an
even-handed, fair, and consensus-based way. You are good at developing
software, well, I am good at this. I see this as one way that I (a lowly
admin-type) can contribute to the community.
2. I would certainly welcome any assistance. If other people want to be on
the "admin team" (as long as Meng is willing) that's a great way to
double-check that admin actions are carried out diplomatically.
3. I think you missed the point of my message, which is that I would much
prefer NOT to exercise "control" and that I would much prefer the list to
manage itself. We are all adults here.
4. Some threads might need to be taken offline, especially if they are
off-topic, or not really "discussion" anymore, or both. Also, any list
member is free to respond privately, especially if he is not sure whether
the thread or his reply is on-topic. These are two different things. I
believe a responsible admin makes choices based on the actual charter,
consensus-based guidelines, and listening to actual user complaints, and
doesn't take his own opinions on the subject as guidance for admin action.
I expect to be held to this as I would hold any other admin to his own
rules :)
I'm not responding to the second half of your message because you are
talking about SPF itself, not about managing the list. You have some good
ideas, and hopefully someone else will reply to those and have a
discussion.
I would ask anyone following up to this to please change the subject if you
are going to talk about SPF and not about list management.
Thanks
gregc
--Hector Santos <winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:
----- 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
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID. To unsubscribe, change your address, or
temporarily deactivate your subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|