Radu Hociung wrote:
It looks to me that t-online does not use their MX servers
for outgoing mail.
Yes, they have several kinds of mailouts. I needed their MXs
in a "mailhosts" configuration for SpamCop, not in a "sender
policy". And I've never tested what T-Online exactly does
when it sends a bounce message. It's a huge organization with
many kinds of different accounts, mail servers, and addresses.
A bunch of 10 mailouts in a-mechanisms isn't better than 1+8
queries for an mx:t-online.de, it has the same effect for an
overall query limit. And Scott's policy needed 17 queries,
clearly more than 10. I got it wrong and started to count at
1 instead of 0, it's 15+2 queries for your count or 15 queries
for Wayne's count, not 16+2 or 16 as I said.
I've seen servers as high as mailout11.sul.t-online.com
IIRC they have another (additional) set for Webmail, mailfwd??,
but I'm too lazy to check this now. It's no specific problem
with T-O, other big ISPs like Wanadoo could also have complex
mail setups (and a minimal chance that they publish SPF soon).
*NO OUTGOING MAIL goes through mx:t-online.de*
Fine, inform all users with a sender policy mentioning this
beast without good reason. This is of course impossible, and
the general problem with introducing more restrictive rules.
It's more interesting to do the opposite, replace Wayne's 3*10
with a single 40, because that's what Scott among others needs,
and at the same time it's better than the old worst case 110.
Return-Path: <>
ACK, "internal" bounces (T-Online to its own customers) would
have an empty Return-Path: without <>.
[...]
Received: from mailout03.sul.t-online.com
(mailout03.sul.t-online.com [194.25.134.81])
That's a postmaster(_at_)mailout03 identity and irrelevant for users
of T-Online with their own domain and sender policy. T-Online
would need it in its own sender policy, but we're discussing
problems of T-O users as long as T-O offers no SPF policy for
"include". If (when) they'd do it I certainly hope that they
use an optimal CIDR as determined by your SPF policy optimizer.
It looks to me like if anyone is using t-online.de for their
vanity domain *cannot publish a good SPF record*
ACK. They have to enumerate the mailouts. Dunno how you'd do
this, but I'd use a bunch of a:mailout??, efficient or not, at
least it's robust.
Have you ever sent mail through t-online have it was
delivered after being checked for SPF records?
I'd use frank(_dot_)ellermann(_at_)t-online, not nobody(_at_)xyzzy(_dot_) In
fact
the T-O server I use _fixes_ MAIL FROM and From whatever I say.
But they have other servers which accept what the user says -
not for my account, and I won't pay fo the liberty to use any
identity. For nobody(_at_)xyzzy it would be useless, that's only
a vanity host, and I can't add what I like to its SPF policy.
Please base your arguments on ISPs other than t-online.de.
Then replace it by another big IPS. And a sudden outbreak of
intelligence among ISPs is none of my assumptions. I'm still
stunned that RR was willing to simplify its SPF policy. That's
near to avant-garde. Any scheme depending on major worldwide
updates is by definition a FUSSP and never works. Hell freezes
before the likes of Wanadoo or SpamCast do something, let alone
the right thing. But SPF as it is works for those who want it,
let's _not_ try to pervert it into a FUSSP by new restrictions.
it should never return 'none' when a record is indeed
published
We probably have the same idea, and the way I put it was wrong.
If a client decides that it doesn't like a SPF policy for its
own private reasons not covered by the SPF spec, then it can
only pretend that it never tried to test SPF. It cannot say
"your policy is broken" if the spec clearly says that it's not.
It can also not say FAIL if it never matched any "-" in the
given policy.
it does not check SPF, it should not give an SPF result.
ACK.
I think I do understand MUST. It means non-optional,
non-negotiable, right?
Yes, REQUIRED in RfC 2119, no excuses. More than SHOULD or
RECOMMENDED, where good excuses for not doing it are possible.
Hundreds of patent holders and FUSSP iventors only wait
for a stunt like this, and then kill SPF with a reason.
Explain why please?
They want SPF to fail, because they have a commercial FUSSP
doing something in the direction of "anti-spam" which is not
free. Or they have a commercial PKI where they could sell
certificates if only nobody finds a simpler scheme not based
on signatures / encryption. They work for MicroSoft, VeriSign,
Cisco, MAPS, Symantec, Brightmail, Maillabs and what else, and
these companies sell solutions, they generally don't distribute
them for free. "Anti-Spam" is an industry.
SPF is dangerously close to a lever to change this industry.
I hope that I'm not megalomaniac, but I think that SPF is the
last chance to save SMTP as it is.
That's how drafts work, (un)fortunately.
If you want to describe "common practice" (as Wayne did), then
you can't mix it deliberately with new features. There's an
invisible border, fixing rarely used stuff like the "zone cut"
is okay, clear limits instead of fuzzy limits are fine, and if
it breaks near to no real policy minor adjustments are also
okay. But major changes like your clear limit far below what
we had in 2004 won't do.
That the IESG insists on calling this an "experiment" is only
fictitious, because MicroSoft wants to steal it for Sender-ID.
In reality v=spf1 is long past the point of a mere experiment.
If they'd ask for the two independent implementations for a
proper "draft standard" they'd find much more than only two.
[DoS detection]
I agree. An implementation guide of some sort is needed. Most
of the DOS-related recommendations belongs there.
Maybe combined with an updated test suite, and a new reference
implementation. But if you have some text ready for a part of
this it's also fine. If you love the peculiar I-D format you
could use Wayne's XML as boilerplate. Or my XML attemtpt with
the op= modifier (less text to delete to get a boilerplate ;-)
Actually I'd love to discuss draft -01pre very soon, like last
week or yesterday. Apparently the SPF Council didn't meet for
more than two weeks, and Wayne never said a single word about
your ideas for better processing limits. Or about the "deadir"
- I still don't know what it is and does.
It think it handles the "iburnu.com" worm quite poorly, to my
understanding. No-one has ever denied it, or had any
arguments against it.
That's the first time that I see "iburnu.com worm", is that
something I need to know if I'm only interested in a perfect
v=spf1 RfC ?
BTW, the stuff about 512, UDP, DNS: I never checked all the
details, but it's some kind of compression with offsets and
lengths. If you have the same sequence of bytes in a DNS
reply, you can address it with a "near pointer" - very vague,
but maybe it explains why there's no precise limit.
Wild guess, with a high chance to be completely wrong: If you
have " mx:12 mx:34 mx:56 mx:78", then that's 20 characters
(and a length byte somewhere). You coul split it into " mx:"
(4+1=5), "12", "34", "56", "78" (4*(2+1)=12), and "compress"
it into 8 offsets to the pieces. Bad deal, 5+12+8 = 25 would
be more than 20+1=21, but it could start to make sense for a
longer piece like "example". If that's how it really works,
I've no idea, have fun with the DNS RfCs... ;-)
I believe 40 too high.
In the case of the old RR policy it would be consistent with
Scott's result of 78 queries without or 39 with Wayne's limits.
Is this list available anywhere?
Of course not, the adoption roll was voluntary, and about 10%
of all inhabitants of TLD .lu volunteered (in other words I'm
not convinced that the adoption roll has much to do with the
real world).
What makes you think it's impossible to get the existing,
early-adopter publishers to change their record ?
It's (fortunately) publish and forget in many cases. And be
very mad if it breaks for reasons not related to changes on
the side of the publisher. The idiocy of applying PRA on all
v=spf1 policies with an "opt-out" scheme comes to mind.
Bye, Frank