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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
