configuration error in lists.isc.org

[Lawrence K. Chen, P.Eng.]

On 2015-08-07 22:23, Reindl Harald wrote:
> Am 08.08.2015 um 05:13 schrieb Lawrence K. Chen, P.Eng.:
>> So, when we were with this provider, our SPF had exclusive pool as good,
>> but included the other pool prefixed with '~'
> 
> can we stop that foolish discussion on the named list?
> 
How about an unnamed one?

Plus this is passing the time while I'm waiting to see if I understood

https://kb.isc.org/article/AA-00295/

And, had adjusted it for BIND 9.9.0 or greater correctly...  Not quite sure 
if use of external or internal in master vs notify is on the correct side....

It links to https://kb.isc.org/article/AA-00851/0 (and says example 4 which 
gives an example that where its hard to tell if it or how it matches like 
it....except its two server example, and while its better formatted than the 
previous article, it doesn't say what the server IPs are, so the IPs getting 
notified or being master could just as well servers not shown....let along 
whether its the other server or itself.

Plus it has master zones in one view, and then says loopback is the master 
for the slave zone in second....(should be the one if first view right?, but 
the only notify it does is some unknown external IP that could be itself the 
other server in the example or one not shown....and not its master.

Which might seem an odd thing to do normally...except that on my system, both 
views, both zones are slaves.  So, internal view does zone transfers with 
master(s), and passes it to external view so that it exposed slaves can get 
it.  And, hopefully this solution will restore sending them 
notification....which seemed to work as both sides sharing the file, but not 
as the outside by updating them by unison (for reasons unknown I have one 
internal server that updates the external view,  Though only 3 zones go to 
internal slaves...and originate from this server's master zone.

Also the one exception in direction has multimaster set, as it received 
notifications and transfers from AD servers (3)...with off by one serial 
numbers.  Presumably all the multimaster option does is shutoff the noise 
(and the highest one always wins), since the alternative is probably the 
latest one wins.  No sure how one would handle if the its middle one or 
youngest one....or a mix.  Or maybe its the one name ads1 that wins over ads2 
and ads3....but what happen when they're impossible type and diff only a 
letter or two....that were names of jedi masters (or so we were told...)

Though I thought the boss said skywalker was part of his naming servers after 
bulldozers or something.

Of servers from that time, only brutus and muskie live on....  Solaris 9 sun 
cluster, doing NFS from our 9990V (which had replaced our 9985.)  Needed to 
be retired a long time ago...but getting people to migrate to NAS has been a 
problem. especially one group that had made extensive use of sunacls, and we 
don't yet have NFSv4 working anywhere...our ksuPerson schema makes LDAP 
integration difficult everywhere...though the new devs are making progress at 
some things back, like striping it totally of any way to do or support 
groups.  Though that group's use of sunacls are on the decline since they're 
pushing the use of central cms for everything...so cms becomes the only user 
allowed to write....though it wiped out secret 'intranet' directory...and the 
idea of getting restored didn't occur until after the 90 day backup retention 
time.  And, apparently now an area covered by any archive policy. (some of 
which are subject to infinite retention.)

All future LTO drives will retain the ability to read LTO1 tapes, which 
leaves the problem of the period of time where they were NDMP backups from a 
NetApp filer.


> that above is pure nonsense - your DOMAIN has either a strict SPF policy -
> or a testing policy ~ and no mix of both
> 
> ~ means "testing, please don't reject if it don't pass" and *nothing* with
> good or bad IP's - from the moment on you have a ~ you don't enforce SPF for
> *anybody* - bad enough that this topic appeared at all but much more bad
> that so many people setup SPF without understand it
> 
Except there are people that feel a strict black and white policy is too 
limiting.

Especially when the IPs are a shared resource of the service provider where 
this little to stop another customer from pretending to be us (just as there 
was nothing for us to pretend to be.... or permit a visiting research to 
continue to send with his email address but through our servers....)

When suddenly they setup an SPF and rejected mail from us, with lots of angry 
messages and calls that its my job to fix it so it'll work again.

As the apparently lots of different universities have been originating mail 
this way for years and years.  And, they need to continue to do so, as the 
application can't do any authentication for sending....(since it had always 
worked....)

Though I haven't gotten a smarttable hack that I found that should allow me 
to send through different authenticated smtp servers, each needing different 
credentials...at least in the login name, as I noticed for a couple domains, 
all the logins have the same password.  Pretty sure password wasn't tied to 
the domain.  More likely is that I forgot passwords and reset them all at 
once and then forgot about them....  its hard generating memorable passwords 
based on login but not contain the login.  OTOH, its left over from where I 
had tried creating unique accounts for online place I shopped at.  A 
co-worker had said that's how he tells which of them sells customer email 
addresses.

But, they all just fill up with email that I don't have time to  sift 
through.  especially since my dovecot search is broken :(

Plus my read of the RFC, didn't say anything that softfail would for one 
entry would cause the entire SPF to be considered experimental.  Just that a 
sites' doing strict SPF treat softfail the same as fail.

Though I realize my error not recalling that there is a middle (neutral) 
level, and which is more appropriate, since softfail is somewhere between 
fail and neutral which is not where I had intended the servers to be.

OTOH, one of the mass mailing services, they have include an SPF record that 
ends with '~all'...though it doesn't matter, as my understand of the RFC is 
that include is treeated like an if-match....if a pass results in ends, 
otherwise continue processing.  Though there's quite a penalty of doing a new 
recursive lookup to get the include, etc.  Not much I can do with includes 
that service provides require us to set (and some do validation (and maybe 
monitoring) that they are in our SPF in the expected format, sometimes I've 
had temporarily remove parts to get validated, I've strip back for a 
revalidation once .... )

But, just about time to deploy my fix and see what happens.
-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
                                    with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally