Re: IP::DOMAIN Associations [Re: Bounce/System Notification Address Veri

On Mon, 04 Jul 2005 18:43:13 EDT, Hector Santos said:

> c:> nslookup - query=txt  vt.edu
> I intentionally separated each SPF directive by line to make it easier to
> read for a reason discussed below.
Right.  But what the <expletive> does that have to do with what name
is claimed on the HELO/EHLO, which is what you *started* complaining about
on Claus's box?

> Now,  I suppose you also want hear my PROS and CONS of your SPF policy. 
Actually, no, but we probably can't get you to shut up about stuff you have
no idea of why it's set up the way it is, so I guess we need to sit through
your discussion of how it would be set up in *your* corner of the world, with
total disregard of any local conditions that don't match your preconcieved
notions of How It Should Be Done.

> First, look at what you just done with your SPF relaxed provision (~all).
> You just invited all SPF spoofers to use your vt.edu domain to spoof and hid
> behind your domain across the network.
OK. Tell you what.  Give me your cell phone number, and I'll give it to our
help desk, and *YOU* can field all the calls if we change that ~all.  That was
set there for a *REASON*, namely that there still exist infrastructure issues
that mean that mail *can* pop out from other places.

You see... we have this chalet.  In Switzerland.  (seriously).  Among other
things, which emit *.vt.edu mail.  Oh, and some 70K users - the vast majority
of which aren't on campus at the moment, it being summer and all (more about
that later...)

> Second, with such a long SPF policy you have added a higher DNS overhead on
> the SPF server/receiver, and for what?  Even if a mismatch is found, you
> told the receiver "don't trust the result." So why bother?
If you prefer, I'll tell the guy in the next cubicle to pull it out, and that
will be one less domain supporting SPF.

> Look at the number of DNS function calls needed here for your policy:
>
>    "v=spf1
>          ip4:128.173.0.0/16
>          ip4:198.82.0.0/16
> 1         mx
> 2         ptr a:lennier.cc.vt.edu
> 3         a:lyta.cc.vt.edu
> 4         a:dagger.cc.vt.edu
> 5         a:vivi.cc.vt.edu
> 6         a:steiner.cc.vt.edu
> 7         a:zidan e.cc.vt.edu
>          ~all"
>
> Although, you will argue DNS caching will save the day, the potential is
> still there for long timeouts per attempt on a poorly setup system.  You
> just imposed 7 additional DNS lookups on the receiver.  If you are sending a
> significant amount of mail out, lets say, X number of systems,  you have
> just include the DNS overhead by a factor of 7 on each X system.
Tell you what - we'll modify this to more accurately reflect our *actual* mail
architecture - but then you're going to be looking at about 30 or 40 a:
entries, and quite likely a backoff to a TCP connection for the DNS lookup if
the DNS stub at the far end isn't EDNS0-capable (the reply is at 410 bytes now
- it *was* 513 bytes until we trimmed out some useful-to-us TXT records just
for the sake of SPF lovers).

And don't you *DARE* give me any "just fix your architecture" noise - you're
talking here about a mission-critical mail server for (what would be if we were
a private corporation) a $400M/year company with 15K employees worldwide (yes,
worldwide.  Researchers all over the place, and that site in Switzerland..)

You're welcome to contact us during our next fund drive and contribute enough
money to underwrite changing it.  Our last major upgrade ran close to $1M,
and did *not* involve dealing with all the departmental mailservers.

> It big waste because you have RELAXED the results of the lookup.  Why
> Bother?
Mostly because *SOME* of us are concerned about *actually* getting mail
through, and we really have better things to do than to break our *own* user's
mail just because their MUA is accidentally configured to send with a From:
user(_at_)vt(_dot_)edu address, but to send to their ISP's mail server.

But of course, you know more about what conditions are present at our site than
we do, because we're *totally* clueless about how to run a mail system that
handles more than 2 million pieces of mail every day.

(I gave up at this point - it's pretty obvious by here that Hector Knows All
about how to configure this stuff, and that anything he disagrees with must be
a stupid misconfiguration on our part rather than a carefully considered 
decision
made by people who know what's going on....)

pgp1Ogw9PoBYb.pgp
Description: PGP signature