Mailing List Archive

FYI from the I-D factory
Hi, some interesting I-Ds I've seen in the last weeks, add
<http://www.ietf.org/internet-drafts/> to get working URLs:

Mar 23: draft-irtf-asrg-iar-howe-siq-01.txt
Mar 23: draft-malamud-subject-line-03.txt
Mar 09: draft-crocker-abnf-rfc2234bis-00.txt
Mar 07: draft-hutzler-spamops-03.txt
Mar 07: draft-iab-dns-choices-01.txt
Feb 25: draft-otis-mass-reputation-00.txt
Feb 23: draft-main-ipaddr-text-rep-02.txt
Feb ??: draft-gellens-submit-bis-01.txt
Feb 20: draft-ietf-marid-csv-csa-02.txt
Feb 20: draft-ietf-marid-csv-dna-02.txt
Feb 18: draft-ietf-marid-csv-intro-02.txt
Feb 14: draft-crocker-email-arch-03.txt

The latest draft-irtf-asrg-iar-howe-siq-01.txt is interesting,
if I get this right a SIQ server could use SPF FAIL and maybe
other SPF results for its "MAIL FROM" requests. Bye, Frank


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: FYI from the I-D factory [ In reply to ]
> some interesting I-Ds I've seen in the last weeks

Not everything moves as slow as SPF, some updates:

2005-03-28 85933 draft-crocker-email-arch-04.txt
2005-03-25 25357 draft-hoffman-hash-attacks-00.txt
2005-03-25 81649 draft-delany-domainkeys-base-02.txt
2005-03-25 52114 draft-otis-mass-reputation-01.txt

The latter is an example for "FUD and flame wars by I-Ds".
Doug should patent this idea if there's no prior art. Bye.


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: Re: FYI from the I-D factory [ In reply to ]
FE> Doug should patent this idea if there's no prior art. Bye.

Publishing the "Doug should patent this idea" message to this list
places the idea into the public domain, making it no longer
patentable, FYI...

(well - given the pathetic track record of the patent office; they
would probably grant the patent anyway - but it would never be
*enforceable* afterwards...)

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: FYI from the I-D factory [ In reply to ]
Chris Drake wrote:

> given the pathetic track record of the patent office; they
> would probably grant the patent anyway - but it would never
> be *enforceable* afterwards...

As soon as it's patented the enforcement is only a question
of the available money for the lawyers,,. :-( At the moment
"they" spend huge amounts (for bribes) to install the same
system in the EU.

After a meeting with "Sir Bill" the new president of the EU
commission was very eager to overrule unanimous votes by the
EU / DK / DE / ... parliaments. I don't believe for a second
that this former socialist turned into a fascist without some
heavy bribes.

Back to something on topic, a new I-D:

2005-03-?? 29245 draft-kucherawy-sender-auth-header-01.txt

The defined result tokens sound familiar:

result = "pass" / "fail" / "softfail" / "neutral" /
"temperror" / "permerror"

Bye, Frank


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: Re: FYI from the I-D factory [ In reply to ]
At 06:05 AM 3/30/2005 +0200, Frank Ellerman wrote:

> > some interesting I-Ds I've seen in the last weeks
>
>Not everything moves as slow as SPF, some updates:
>
>2005-03-28 85933 draft-crocker-email-arch-04.txt
>2005-03-25 25357 draft-hoffman-hash-attacks-00.txt
>2005-03-25 81649 draft-delany-domainkeys-base-02.txt
>2005-03-25 52114 draft-otis-mass-reputation-01.txt
>
>The latter is an example for "FUD and flame wars by I-Ds".
>Doug should patent this idea if there's no prior art. Bye.

Nice list. I'm not smart enough to tell if draft-otis is FUD or real
worries. I do see that there is a big push to make the DNS queries really
efficient, and capable of withstanding the worst DoS attack
imaginable. CSV does the authentication check in one query, using an SRV
record.
<http://mipassoc.org/csv/draft-ietf-marid-csv-intro-02.html>http://mipassoc.org/csv/draft-ietf-marid-csv-intro-02.html
As I understand it, the IP addresses returned in an SRV record are single
addresses, and only a few will fit. There is also some really awkward
re-definition of existing fields in the SRV record. I think the need for
authentication is universal enough that it deserves its own new record type.

Seems like we need an "SPF-Lite", with nothing but IP blocks. If an ISP as
large as rr.com can list all their mail servers in one SPF record, I can't
imagine there will be many that need "SPF Heavy". Having a compact
notation to indicate large groups of servers will make SPF records much
easier to set up than a zillion little SRV records.

Here is rr.com's entire list:
v=spf1 ip4:24.30.203.0/24 ip4:24.28.200.0/24 ip4:24.28.204.0/24
ip4:24.30.218.0/24 ip4:24.93.47.0/24 ip4:24.25.9.0/24
ip4:65.24.5.0/24 ip4:24.94.166.0/24 ip4:24.29.109.0/24
ip4:66.75.162.0/24 ip4:24.24.2.0/24 ip4:65.32.5.0/24 +mx ~all

Here are some more compact alternatives:
m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,
24.25.9/24,65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,
24.24.2/24,65.32.5/24 ...

m=24(24.30.203,24.28.200,24.28.204,24.30.218,24.93.47,24.25.9,
65.24.5,24.94.166,24.29.109,66.75.162,24.24.2,65.32.5) ...

m=24(181ecb,181cc8,181ccc,181eda,185d2f,181909,411805,185ea6,
181d6d,424ba2,181802,412005) ...

Remember, this is the output of an SPF compiler. The input can be a nice
tabular display.

Can SPF3 have *fewer* features than SPF1? That will give everyone enough
time to organize their domains so they don't need macros and redirects.

-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: FYI from the I-D factory [ In reply to ]
David MacQuigg wrote:

> I'm not smart enough to tell if draft-otis is FUD or real
> worries.

Pure FUD. The usual tactics of first mixing SPF and Sender-ID,
then get unsubstantiated hype from spf.pobox and other pages,
and finally prove that Sender-ID is not really good as anti-
phishing scheme, and SPF is even worse. Never mind that SPF
never claimed to be anti-phishing, it's anti-forgery, but the
MAPS-CSV-BATV-gang styling itself as "MIPA" uses always the
same chains of pseudo-arguments.

Another chain of pseudo-arguments used by MIPA:

Obviously -all doesn't work well for "traditional forwarding"
to 3rd parties. Obviously that's a feature, in fact it's the
only real feature of SPF, either test SPF at the MX, or don't
test it at all.

But the MIPA-gang simply assumes that it's a bug (as soon as
you read "bounces-to" instead of "Return-Path" or "MAIL FROM"
you can be sure to have met a MIPA-fan). Therefore they say
that SPF makes only sense without FAIL, because otherwise some
receivers with forwarding to 3rd parties could have a problem.

Next they prove that SPF minus FAIL isn't very useful, spammers
can always set up a throw-away domain with a dummy policy to
get a PASS. Therefore a PASS from unknown strangers is in fact
useless. Therefore SPF is useless, and besides BATV could get
almost all bogus bounces independent of the receiver.

This chain of arguments is bogus. And because Dave / John /
Doug / etc. are not stupid they do this deliberately, shame on
them. Of course SPF minus FAIL is rather useless, Like a car
without wheels, so what ?

> CSV does the authentication check in one query, using an SRV
> record.

Up to six queries for John's pseudo-zone-cut (right to left but
excl. TLDs to protect the root servers).

> Seems like we need an "SPF-Lite", with nothing but IP blocks.

That would be RMX, but it's now too late to change the winning
team. If you want "SPF-Lite" you can have it today: Ignore
all policies with a / mx / ptr / exists / include / redirect.

IMHO that's not clever, but ignoring all policies without the
chance of a FAIL could make sense: SPF minus FAIL is rather
useless.

> Can SPF3 have *fewer* features than SPF1?

Of course, it should. The exp= is more than baroque, it's near
to ridiculous. Who cares about the "personal reasons" of the
publisher for a FAIL ? If we want I18N for why.html then let's
just do it.

Okay, in theory you could do smart things with exp=, e.g. offer
a form where the poor sender can fix the sender policy which
caused a FAIL. But in practice, who needs this ? Bye, Frank


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: Re: FYI from the I-D factory [ In reply to ]
...... Original Message .......
On Wed, 30 Mar 2005 19:37:58 -0700 David MacQuigg <dmquigg-spf@yahoo.com>
wrote:
>At 06:05 AM 3/30/2005 +0200, Frank Ellerman wrote:
>
>> > some interesting I-Ds I've seen in the last weeks
>>

>>2005-03-25 52114 draft-otis-mass-reputation-01.txt
>>
>>The latter is an example for "FUD and flame wars by I-Ds".
>>Doug should patent this idea if there's no prior art. Bye.
>
>Nice list. I'm not smart enough to tell if draft-otis is FUD or real
>worries. I do see that there is a big push to make the DNS queries really
>efficient, and capable of withstanding the worst DoS attack
>imaginable. CSV does the authentication check in one query, using an SRV
>record.
><http://mipassoc.org/csv/draft-ietf-marid-csv-intro-02.html>http://mipassoc.org/csv/draft-ietf-marid-csv-intro-02.html
>As I understand it, the IP addresses returned in an SRV record are single
>addresses, and only a few will fit. There is also some really awkward
>re-definition of existing fields in the SRV record. I think the need for
>authentication is universal enough that it deserves its own new record
type.
>
CSV only deals with HELO/EHLO. Since so many mail servers have a bogus
HELO/EHLO these days it's near term utility seems questionable.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com
Re: Re: FYI from the I-D factory [ In reply to ]
At 04:25 AM 3/31/2005 +0200, Frank wrote:

>2005-03-?? 29245 draft-kucherawy-sender-auth-header-01.txt

Wow!! It's finally coming together. This is exactly what I was thinking
of, with all the details worked out.

We need to change section 7.2 of draft-schlitt to conform.

Now if we can just standardize this damn query syntax, all the methods will
work together.

-- Dave


************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com