Sorry for the following tone, but I got to say this.
Come on! where is the common sense?
This is a perfect example of a MIX POLICY issue that SPF/SUBMITTER/SRS does
not address.
It is *fundamentally illogical* to make an assertion for a FROM::IP
association without having a consistent assertion with the HELO::IP.
Impossible!
All you had to do is check the HELO and the problem is solved!
You ask for all this compliancy for SRS/SUBMITTER/SENDERID? Boy, are you
going to be severely disappointed.
Think about what you are saying:
If software needs to be compliant with SRS, SUBMITTER or SENDER, then it
must be compliant with HELO, including across all routes!!
And what if a system does support all this?
The spammer adapts and you will see this:
IP: 82.77.64.5
EHLO Schiopu.com
MAIL FROM: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
submitter=anyone(_at_)schiopu(_dot_)com
with a compliant SPF spammer domain and with all the matching 2822 stuff
with or without submitter isn't provided!
Now what? You solved nothing with this huge design change requirements!
Look, the smart vendor is going to what he things is required for 20+ years
of old SMTP standards. Not what you and Microsoft wish to force down our
throats. If it was a valid and sound idea, no problem. But they are not.
If SPF2 is going to have HELO provisions, I am not going waste time with
submitter or senderid.
Also about relax provisions:
You know I have suggested to get rid of the relax provisions or to use it
with an stated expiration policy in the specification.. A domain is either
ready to use a SPF record or it is not.
You ignored that suggestion. I don't know why, "Expiration" ideas helps
people get going to completing what they need to do. I don't know why you
didn't take it serious or even a considered it.
Look, SMTP started with an loophole that created many problems.
SPF attempts to plug up this LOOPHOLE ---- But introduces new ones!!
OY VEY! It doesn't make sense.
Meng, again sorry for the tone, but I just went to a software design change
cost estimate for SUBMITTER/SENDERID and the cost is too high with LITTLE
benefit!
For what? When all you have to do is be more consistent with HELO checking
as well and get rid of that stupid relaxed provision? Or atleast make it
with an expiration concept?
Sure, I don't need SPF to implement these ideas. In fact, I am finishing up
a "SPF Variant" to offer new options for my customers to support an
expiration concept for neutral and softfail. I had it in before, but I took
it out. I'm putting it back in.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, July 12, 2004 7:58 PM
Subject: [spf-discuss] spf-discuss record changing to -all
Has anyone else been getting these forged viruses?
Received-SPF: softfail (dumbo.pobox.com: transitioning domain of
spf-discuss(_at_)v2(_dot_)listbox(_dot_)com does not designate 82.77.64.5 as
permitted
sender)
Received: from Schiopu.com (unknown [82.77.64.5])
by dumbo.pobox.com (Postfix) with SMTP id DE7694AC
for <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>; Mon, 12 Jul 2004 01:40:09
-0400 (EDT)
Date: Sat, 19 Jun 2004 20:43:04 +0200
To: "Mengwong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
From: "Spf-discuss" <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
They're forging spf-discuss(_at_)v2(_dot_)listbox(_dot_)com, which is pretty
annoying. Fortunately, we can do something about it!
I've just set up per-user records for v2.listbox.com, and
I'm going to set spf-discuss to -all. Previously the site
default for listbox.com was ~all.
This means that anybody who:
- subscribed to spf-discuss using a forwarding alias
which does not perform SRS/SUBMITTER/SenderID-prepending
- and checks incoming mail using SPF
will reject messages due to SPF fail.
If you don't get any more messages after this one, that's
probably what happened :)
Any comments before I pull the trigger? Here's the full virus:
Received-SPF: softfail (dumbo.pobox.com: transitioning domain of
spf-discuss(_at_)v2(_dot_)listbox(_dot_)com does not designate 82.77.64.5 as
permitted
sender)
Received: from Schiopu.com (unknown [82.77.64.5])
by dumbo.pobox.com (Postfix) with SMTP id DE7694AC
for <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>; Mon, 12 Jul 2004 01:40:09
-0400 (EDT)
Date: Sat, 19 Jun 2004 20:43:04 +0200
To: "Mengwong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
From: "Spf-discuss" <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Subject: Notification
Message-ID: <whfjozptnraadeduvbc(_at_)dumbo(_dot_)pobox(_dot_)com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="--------ryccdfxqlrzqaoadmrub"
[-- Attachment #1 --]
[-- Type: text/html, Encoding: 7bit, Size: 0.1K --]
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
[-- text/html is unsupported (use 'v' to view this part) --]
[-- Attachment #2: Details.scr --]
[-- Type: application/octet-stream, Encoding: base64, Size: 27K --]
Content-Type: application/octet-stream; name="Details.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Details.scr"
[-- application/octet-stream is unsupported (use 'v' to view this
part) --]
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
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