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
- 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> 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
_______________________________________________
mailop mailing list
mailop@mailop.org
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
