I agree with new stuff going to SPF2. I believe I have stated this a few
times.
However, the HELO issue was an very early debated issue and in the end, I
was left to believe that it was going to be address. But obviously did not,
or more correctly, it was not worked out.
I understood all the issues of why SPF might not want to deal with it. Meng
said he based it on that idea that DMP was doing it and that was one thing
he wanted to improve on - one less lookup.
I agreed with the general issue with DNS overhead and "redundant lookups",
after all, the research, test beds were all based in a world with
essentially no records, so obviously, there were near 100% in NONE lookups.
But DMP proved that it could not be ignored. As I indicated, when I added
SPF and turned off DMP, my local domains which were protected by DMP at
HELO were now being bypassed by SPF.
So during the debate of this issue, I had to do something;
a) Create a SPF variant?
b) Design a new LMAP protocol which I did called DNV (Domain Name
Validation)
c) Enhancing our ruled based filter language to support a new DIP concept.
I did all three. I did A. But I didn't want to step on Mengs toes with "a
different SPF". So I reverted back to standard SPF and I did DNV which
concentrated on HELO and PTR stuff. At this point, after all the HELO
debate, Meng said he will add a provision for his. I strongly felt it was
a loophole and could not be ignored.
However, I completely UNDERSTAND the concern with the HELO, especially with
the fact that was a high candidate to be wrong in a high degree.
But if there was one thing that was 100% absolute about the LMAP concept,
is that it offer 100% protection for your own local domains.
So what I recommended to MENG, that at a minimum, the SPF system should have
a provision to check the HELO for local domain spoofs because this is 100%
reliabile and byfar it was how people were getting in:
IP: some non-winserver.com IP
HELO winserver.com
MAIL FROM: user(_at_)some-non-spf-domain(_dot_)com
The SPF1 rule completely ignored this obvious spoof which were at 12%.
But during DNV work I saw that all this was probably better suited if was
part of the filter language. So I enchanged our white/black filter
scripting language with LMAP ideas built-in using something called
DIP - Domain/IP pair.
So in the end, what we have his this:
- Check Filters
- RBL
- SPF
- CBV
and in the filters, we have DIP rules like so:
; Note:: %DIP% expands to %RPD%[%IP%]
accept if %DIP% = bellsouth.net[209.152.59.66]
accept if %CIP% in 205.152.*.* and %RPD% = bellsouth.net
reason Local Domain/IP accepted
accept if "%RPD%[%CIP%]" = "%LDN%[%LIP%]"
accept if %CIP% = 208.247.131.9 ; winserver connection
accept if %RPD%[%CIP%] = winserver.com[208.247.131.9]
reason Remote Domain/IP accepted
accept if %DIP% = lists.xml.org[209.202.168.102]
accept if %DIP% = ietf.org[132.151.6.22]
accept if %DIP% = mmx.engelschall.com[195.27.130.252]
etc.
So we solved it for us. We don't have the problem? So why am I here? To
help the standard. Not all other systems are going to have the flexibile and
power like our system. If so, great.
But it can't be ignored. Meng can't go on the promotion tour to talk about
SPF implementation and when people begin to added it and still see 12% of
the above like messages getting in, what do you think is going to happen?
So whether is it added or not inherently into the SPF1 spec, it is 100%
prudent to make it a provision in the documentation so that implementors are
aware of this.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, October 05, 2004 10:36 PM
Subject: [spf-discuss] Re: What to include...
Hector Santos wrote:
You need HELO checking. You defeats the purpose. Now, this
can be done independently of SPF1, but it is needed because
it is a LOOPHOLE otherwise.
As you say, it's independent of v=spf1, and your elaborated
procedures were not part of v=spf1. The "optional" clauses
in v=spf1 don't cover all of your ideas.
If I got this right you're not talking about a dedicated MX
implementig v=spf1, but about a mailer acting as MSA on one
side (to its local users), and as MX on the other side.
So if one of your local users says HELO OEMcomputer you're
prepared to ignore this as nonsense, but if a Spamcast box
says HELO OEMcomputer you can reject it without further ado.
And you certainly won't try to get the SPF sender policy of
a "host" OEMcomputer. The host tv is funny, fortunately it
has no sender policy, yet ;-)
That's all very interesting, but it's not exactly a part of
v=spf1. Your ideas could be documented separately in a new
spf2.0/helo or a similar text, simply copying the "optional"
v=spf1 part isn't good enough.
Most of us agreed on Mark's proposal "no new features" for
draft-mengwong-spf-02, with the exception of the new DNS RR
justifying an experimental status.
Please put everything else into spf2.0. Please don't delay
the v=spf1 update now by new features. As you said it's
independent of v=spf1, let's discuss it now for spf2.0. My
first question: Where do you see a "loophole" in v=spf1 ?
Do you have an example where a MAIL FROM test results in PASS,
but shouldn't, or is it about a FAIL, or where is this v=spf1
"loophole" ?
Bye, Frank
-------
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