configuration error in lists.isc.org

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Thu Aug 13 21:15:16 UTC 2015



On 2015-08-10 17:12, Reindl Harald wrote:
> truncated the long, hard to understand and unrelated stuff....
> 
> Am 10.08.2015 um 23:49 schrieb Lawrence K. Chen, P.Eng.:
>>> 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.
> 
> well, when you can't say from where you send mail you should refrain from
> setup SPF at all
> 

Except there are external forces that demand an SPF, and that it contain 
specific strings at all times.  Namely Office365, the add domain to tenant 
process can't be completed until things are just the way it wants.

And, if you temporarily switch back and the back again....its flagged that it 
wasn't write already and the extra bits don't match...so went through the 
whole verification and setup process again (I wouldn't have thought the 
verification stuff was needed again after the first time, but I may have 
skimmed the docs wrong....or the group that admins it and generates those DNS 
tickets....

>> 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
> 
> the shared resource don't enforce SMTP authentication?
> 
Doesn't matter if there'll be at least one person among the group that'll 
fall victim to a spearphishing email, and they run a mail system where 
sending forged emails is permitted.  Though Office365 seemed to be the first 
that I've encountered that only allows you send from addresses that your 
approved for.  Our previous and in-house system allow anything once 
authenticated.

Some of these phishers can be weird....until recently we used to still 
provide an on-premise auth. smtp server (a certain group has people in the 
field with an email client that only supported export ciphers....

So, its weak and exposed...but some people had responded to spearphishing 
emails, and the phishers used the credentials to connect to our VPN and the 
authenticate into smtp to send their spearphishing emails.  (sad thing is our 
non-authenticated smtp could also have been reached with VPN, now the ports 
are blocked from VPN.  By default our VPN is split tunnel, so its not needed 
to hit Office365.

>> .... or permit a
>> visiting research to continue to send with his email address but through
>> our servers....)
> 
> this has *nothing* to do with *your* SPF policy
> 

I had explained that, the only thing I didn't do was suggest they contact 
their own admins to get us added to their SPF....

Though I wouldn't be surprised if there had been such requests....

> 
>> 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.
> 
> in that case it has to be ruled out if you made a mistake by not include all
> your sending servers in your SPF
> 

No that's....was it my mistake to not include all my sending servers in your 
SPF....ummm, no.

>> 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....)
> 
> that's a lame excuse and finally means "don't setup SPF/DMARC at all if
> you have no clue who is sending from where with what enevlopes"
> 
> "since it has always worked" is a bad attitude - you enforce policies or
> just don't touch them at all
> 
> 
We don't do DMARC, though it has come up that we should do DKIM (plus 
everything we send should be signed, so they won't yield >100 passwords by 
sending a forged email that looked like it was from our CIO.  Except we 
permit an overly diverse selection of email clients to be used, where most of 
them don't support S/MIME.

The DMARC issue is largely due to yahoo and aol.  Not sure about aol, but 
there are a lot of faculty and students with yahoo or hotmail addresses 
(there's no restriction on forwarding university email address to another, 
and its not uncommon for students to do that. And, it turns out when we 
generate class mailing lists, it'll the forwarded to account is on the list 
directly cuts down on the extra hop, and when it was our servers it helped 
cut the load....

But, the DMARC issue hit our listserv.

Don't know if there's a breakdown of what's forwarded...but we always had 
lots of problems with getting blocked by yahoo or hotmail in the past (since 
forward all, includes all the spam a user receives, and some places realize 
that it we're just the messenger, while other places don't care who they 
shoot.  But, aol came up again due to DMARC.  I think they're one of the few 
places we have feedback service on whether we have a spammer on our systems 
or not.

Though we had been told my Microsoft that by using their EOP service we'll 
never get blocked by their other mail services ever again....

Probably true, though taking care of email got reassigned to the Windows 
group because its from Microsoft :)

My first mail server was on an Amiga....


-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
                                    with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally


More information about the bind-users mailing list