We "can" limit it the RFC's, and the companies that fail that otherwise
would pass, should clean up those records..
But mainly for the opposite way you expect.. we don't 'fail' to process
those, they simply are treated as too weak to be reliable.
SPF can help the reputation of the sender, but only if they use it
correctly.. if it isn't correct, then well we kind of have to accept it
from anywhere, so if one of their customers gets 'phished', it is on them.
But we do have to educate don't we? If they don't know it's bad, will
they fix it? Many times we are the 'first' company that lets someone
know they have bad KSF records..
Be nice if the DNS resolvers would test it like they do all other
configs, before allowing it to be used..
But the really scary part, given the size of some clouds, is that
allowing ALL the IPs in the clouds SPF record, means any malware or
miscreant on the same cloud can impersonate them.
On 2022-08-15 19:59, Brandon Long wrote:
I mean, you can either limit it to the limits in the RFC and fail a
bunch of things that would otherwise pass, or
acknowledge that those limits are much smaller than practical given the
proliferation of third party senders
that are used by companies.
Especially since some larger companies will not break the limit
themselves, but make it much harder for
their users to stay within the limits (ugh, yeah, that's workspace
customers).
Brandon
On Fri, Aug 12, 2022 at 10:59 AM Michael Peddemors via mailop
<mailop@mailop.org <mailto:mailop@mailop.org>> wrote:
Addendum: It's amazing how many billion dollar companies can't even get
SPF right.. Pop Quiz.. how many recursive DNS queries are supposed
to be
in SPF max?
On 2022-08-12 10:24, Michael Peddemors via mailop wrote:
> And frankly, for most people it is the easiest solution.
>
> So many time we tell people, turn off IPv6 and all their problems go
> away, but asking them to set up all the extra layers such as SPF,
DKIM
> etc, and to do it right.. well.. in practice, people have better
things
> to do..
>
> We of course still say:
>
> * Sane PTR, only a single one unless you are forced to have two
(small
> subnet DNS responsibility)
> * Only a couple of A records, keep the list small (UDP vs retry
to TCP0
> * Implement a sane SPF record (Amazing how many people have
trouble with
> this, or simply add everyone.. if you include all of google,
amazon, and
> microsoft, why bother having an SPF record ;)
> * Turn off ipv6 for MTA->MTA mail. (I know the IPv6 evangelists
scream
> when I say this, but email operators just want it to work) Slowly we
> work towards first MTU->MTA over IPv6, I think we will see
IPv4->IPv4
> for server to server communication for some time yet.
>
> Let's not try to make it too difficult for the little guys, we
should be
> encouraging more people operating email servers, not making it so
> difficult that they throw their hands in the air, and move to Gmail..
> (of course, that might be the plan all along ;)
>
> On 2022-08-12 09:47, Al Iverson via mailop wrote:
>> Hey Jesse,
>>
>> This is sort of controversial and you'll get some people saying very
>> vehemently that you should never do this ever, for various
reasons of
>> interoperability or strong opinions about how the internet
works. But
>> instead, here's my take from an operational perspective...
>>
>> I personally would keep forcing mail to Gmail over IPv4, and I do
>> indeed do this on my own hobbyist systems. Every time I spin up
a new
>> VPS and forget this, I notice it rather quickly because of bouncing
>> mail. Not only are they quicker to block IPv6 mail overall (IMHO),
>> they also are more likely to block IPv6 mail from IPs without rDNS,
>> and mail that lacks either SPF or DKIM authentication. Their filters
>> are evolving and it feels as though their IPv4 blocking is
catching up
>> a bit -- more likely to block unauthenticated IPv4 mail today
versus a
>> year or two ago, but that doesn't really mean it suddenly became
>> easier to send over IPv6.
>>
>> I blogged about this a couple year ago - nothing you don't already
>> know, really -
>>
https://www.spamresource.com/2020/11/honestly-dont-send-to-gmail-over-ipv6.html
<https://www.spamresource.com/2020/11/honestly-dont-send-to-gmail-over-ipv6.html>
>>
>> - but recently that article got linked to on Reddit and a bunch of
>> nerds made noise that I don't know what I'm talking about and that
>> they can get mail to Gmail over IPv6 just fine. So, YMMV. (My
point is
>> that it's not impossible, but it is annoying and that it has
exacting,
>> but unclear requirements.)
>>
>> Cheers,
>> Al Iverson
>>
>> On Fri, Aug 12, 2022 at 11:26 AM Jesse Hathaway via mailop
>> <mailop@mailop.org <mailto:mailop@mailop.org>> wrote:
>>>
>>> Back in 2013[1] we changed our mail config to force MX lookups
for gmail
>>> to only use IPv4 addresses. We made these change after hearing
reports
>>> of higher spam scoring when sending mail via IPv6. Would anyone
from
>>> Google be able to comment as to whether forcing IPv4 is still
needed?
>>> Yours kindly, Jesse Hathaway
>>>
>>>
>>> [1]: https://gerrit.wikimedia.org/r/c/operations/puppet/+/79753
<https://gerrit.wikimedia.org/r/c/operations/puppet/+/79753>
>>> _______________________________________________
>>> mailop mailing list
>>> mailop@mailop.org <mailto:mailop@mailop.org>
>>> https://list.mailop.org/listinfo/mailop
<https://list.mailop.org/listinfo/mailop>
>>
>>
>>
>
>
>
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com <http://www.linuxmagic.com>
@linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
<http://www.wizard.ca>
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 <tel:(604)%20682-0300> Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and
intended
solely for the use of the individual or entity to which they are
addressed.
Please note that any views or opinions presented in this email are
solely
those of the author and are not intended to represent those of the
company.
_______________________________________________
mailop mailing list
mailop@mailop.org <mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop
<https://list.mailop.org/listinfo/mailop>
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
