I've been seeing a long thread about why ipv6 adoption isn't there yet. This is half a "paging someone with clue" post and half a "...really, guys?" Picard-facepalm post.
I just (earlier this week) had to disable ipv6 outbound on one of $dayjob's MX servers, because Gmail, who hosts nanog.org, was rejecting our mail due to "our domain's very low reputation". (In this parlance, "Very Low" is an actual indicative metric.) Dayjob is the people who make BIND and run a root DNS server. Totally disreputable, I'm sure.
I don't see anything indicating this in our postmaster tools.
I am certain this action is happening completely transparently and invisibly to NANOG, unless others have complained. Whatever UI google gives them to manage their domain will not show this. There are no logs they can grep.
I'm told that "gmail's filters for ipv6 are way tighter than ipv4" but that's from a non-canonical source. If this is the case, it does very little to further ipv6 adoption, that's for sure.
I've posted over on mailop, and was given a contact (Brandon), but haven't heard back. Gmail's a black box. I've reached out to a few other people, but if anyone here can loan a bat-phone, please let me know.
I'm loathe to randomly re-enable ipv6 without contact from someone saying why this happened, and how it's been fixed.
Hope the rest of the world is treating you decently!
There are a lot of bits and bobs that one has to get right for mail to flow, amongst which:
- IP -> PTR lookup -> that hostname lookup, and match to IP again
(Forward-confirmed reverse DNS - Wikipedia)
- SPF
- DKIM
- DMARC
- ARC (for mailinglists)
- SRS (When forwarding, rewrite the From and resign DKIM, and then ARC-sign that)
- Decent TLS
- MTA-STS
And that list grows and grows... and grows and grows. It is kinda a test if one has actually bothered to configure a setup, and not just are randomly sending an email by just telneting from a random server. Of course the large spam outfits have this fully automated and configured, so that their spam^Wadvertising comes through.
A wee little test tells that there are a few improvements to be made at minimum:
• Not all authenticity marks against email phishing (DMARC, DKIM and SPF)
• Failed :Mail server connection not or insufficiently secured (STARTTLS and DANE)
Greets,
Jeroen (who also runs his own full net... and had jeroen@isc for a few years... )
I've been seeing a long thread about why ipv6 adoption isn't there yet. This is half a "paging someone with clue" post and half a "...really, guys?" Picard-facepalm post.
I just (earlier this week) had to disable ipv6 outbound on one of $dayjob's MX servers, because Gmail, who hosts nanog.org, was rejecting our mail due to "our domain's very low reputation". (In this parlance, "Very Low" is an actual indicative metric.) Dayjob is the people who make BIND and run a root DNS server. Totally disreputable, I'm sure.
I don't see anything indicating this in our postmaster tools.
I am certain this action is happening completely transparently and invisibly to NANOG, unless others have complained. Whatever UI google gives them to manage their domain will not show this. There are no logs they can grep.
I'm told that "gmail's filters for ipv6 are way tighter than ipv4" but that's from a non-canonical source. If this is the case, it does very little to further ipv6 adoption, that's for sure.
I've posted over on mailop, and was given a contact (Brandon), but haven't heard back. Gmail's a black box. I've reached out to a few other people, but if anyone here can loan a bat-phone, please let me know.
I'm loathe to randomly re-enable ipv6 without contact from someone saying why this happened, and how it's been fixed.
-Dan
(Who actually operates my own network)
I also run my own mail server. I had to firewall off Google's MXes for this exact reason: silent and not-so-silent email rejection when offered over IPv6.
Every now and then they rotate their IP addresses, which causes mail to get dropped for a while.
There is no other conclusion possible than that Gmail is actively anti-email at this point. I'm pretty sure I receive more spam from them than I send to them, despite forwarding all emails for a few family members' domains.
Google has added ARC verification and sealing to their email services (Gmail, G Suite, and Google Groups). The popular Mailing List Manager (MLM) software Sympa incorporated ARC in v6.2.38, and ARC is being incorporated into the next release of the Mailman MLM – ARC configuration directives are already in the online documentation.
The commercial MTAs Halon and MailerQ incorporate ARC, and the milters authentication_milter and OpenARC can be used to deploy ARC with the Postfix, Oracle Communications Messaging Server, and Sendmail MTAs. Several open-source libraries and modules are already available for those who need to integrate ARC functions into their systems.
----->8
thus there is at least that for ARC.
For one project that sends a rather decent amount of email, adopting DMARC/ARC and @via rewriting made all mail go through (at least all the google reception works), though there might be other factors at work: unless you work in the closed corp and on that project, impossible to know why your mail really gets rejected.
... and is basically snake oil.
Unfortunately it is April 3rd, so two days late, but you are thinking of another acronym:
Now, THAT is snakeoil, or well, a scam is more like it: if you can pay and they like you, you get a logo, anybody else is out... marketing companies of the world (and the once earning money for bits ala domains and worse EV SSL certs... rejoice)
SRS (When forwarding, rewrite the From and resign DKIM, and then ARC-sign that)
Decent TLS
MTA-STS
Jeroen -
It is indeed amazing how many protocols we can spin up to address the same underlying problem, time and time again…
If anyone can anonymously join the mail-sending club and send some email [until bad reputation precludes such], and achieving bad reputation results has no real-world implications, and a new network persona (e.g. domain name) is always available, then the problem could be considered intractable by initial conditions – and no amount of anti-spam protocols (no matter how brilliantly designed and engineered) should be expected to durably address the problem.
(It might, however, be interesting to do a regression analysis on the spam mitigation protocol introduction dates – it’d be interesting to know if the expected number protocols that will need proper setup in 10, 20, 40 years…!)
/John
Disclaimer(s): my views alone. This email composed of 100% recycled electrons.
ARC resolves into a previously unsolved problem: reputation. You could do reputation with plain old DKIM too, so I don't see why changing the name of the header changes anything on the ground. And nobody could give me an answer of why signing previous Authentication-Results is useful for toward that end. It's just more magical thinking.
Thank goodness it's an experimental RFC so it can go the way of the dodo.
This comes up on mailop periodically. It kind of makes me want to drop entries for the various gmail.com MXes in /etc/hosts, because while postfix gives me a way to override the one domain (say, gmail.com) it's whack-a-mole with the various gmail-hosted-domains.
Bind9 has a filter-aaaa feature, but it doesn't quite work this way, easily, and of course it breaks DNSSEC.
It's my opinion (not that of my employer, necessarily), that gmail is to email as old-school AOL is to the internet.
Hope the rest of the world is treating you decently!
There are a lot of bits and bobs that one has to get right for mail to flow, amongst which:
- IP -> PTR lookup -> that hostname lookup, and match to IP again
(Forward-confirmed reverse DNS - Wikipedia)
- SPF
- DKIM
- DMARC
- ARC (for mailinglists)
- SRS (When forwarding, rewrite the From and resign DKIM, and then ARC-sign that)
- Decent TLS
- MTA-STS
And that list grows and grows... and grows and grows. It is kinda a test if one has actually bothered to configure a setup, and not just are randomly sending an email by just telneting from a random server. Of course the large spam outfits have this fully automated and configured, so that their spam^Wadvertising comes through.
A wee little test tells that there are a few improvements to be made at minimum:
• Not all authenticity marks against email phishing (DMARC, DKIM and SPF)
We have SPF, DKIM signing, and a DMARC policy that sets p=none.
We're not setting p=reject, considering the number of mailing lists our users are on that are outdated or based on EOL software (including this one which depends on python 2.7, and including our own which have the same problem). It's impossible to know, from the outside, how mailing lists are configured. Mailman3 is...special. That's a rant for another time.
We get about an email a week from someone emailing security-officer@ trying to get a bug bounty telling us we should set p=reject. There's an ecosystem for this stuff.
I don't think this affects our domain's "reputation".
• Failed :Mail server connection not or insufficiently secured (STARTTLS and DANE)
This has little to do with what ciphers we support outbound, and little to do with our reputation.
Unlike HTTPS, the failback to startTLS not working is plain-text. Setting a stricter cipher requirement would result in more mail being delivered in the clear.
It appears that Michael Thomas <mike@mtcc.com> said:
There are a lot of bits and bobs that one has to get right for mail to flow, amongst which:
- IP -> PTR lookup -> that hostname lookup, and match to IP again
- SPF
- DKIM
- DMARC
Yup. Gmail has made it quite clear that they will not accept v6 mail that
isn't SPF or DKIM authenticated. DKIM is more work but works more reliably.
- ARC (for mailinglists)
Seriously spend zero time on ARC. It doesn't work as advertised ...
Please, not this again. ARC does what it does, even if it doesn't do
what you might wish it did instead.
It's certainly not a magic ticket into an inbox but it is slowly
helping undo DMARC mailing list damage. It's not important unless
you forward mail like a mailing list does.
It appears that Michael Thomas <mike@mtcc.com> said:
Google at least adds ARC headers in Gmail, and did the editing of RFC8617.
ARC resolves into a previously unsolved problem: reputation. ...
No, actually it doesn't, as has been repeatedly explained.
ARC addreses the problem that mailing lists do a lousy job of spam
filtering, A list that usually sends lovely clean mail sometimes
doesn't, since a typical list forwards anything with a subscriber's
address on the From line including spam from cleverish spammers who
take pairs of from/to addresses from stolen mailboxes.
ARC lets the recipient system look back and do what we might call
retroactive filtering, using info about messages as they arrived at
the previous forwarder. While it would be nice if lists did a better
job of spam filtering, they don't, and ARC is a reasonable remedy for
that.
I also run my own mail server. I had to firewall off Google's MXes for
this exact reason: silent and not-so-silent email rejection when
offered over IPv6.
I run my own mail server and have no trouble at all delivering mail to Gmail over IPv6.
I do have SPF, DKIM, DNSSEC and DANE on my mail servers. My DMARC policy is p=none.
If it matters, the MTA is a heavily hacked version of qmail.
While I believe that Gmail rejects some people's mail, every time when
I have looked in detail, I have found that their mail authentication
isn't working properly. I'd suggest starting there.
It appears that Michael Thomas <mike@mtcc.com> said:
There are a lot of bits and bobs that one has to get right for mail to flow, amongst which:
- IP -> PTR lookup -> that hostname lookup, and match to IP again
- SPF
- DKIM
- DMARC
Yup. Gmail has made it quite clear that they will not accept v6 mail that
isn't SPF or DKIM authenticated. DKIM is more work but works more reliably.
- ARC (for mailinglists)
Seriously spend zero time on ARC. It doesn't work as advertised ...
Please, not this again. ARC does what it does, even if it doesn't do
what you might wish it did instead.
I does what it does which is DKIM. That's it.
It's certainly not a magic ticket into an inbox but it is slowly
helping undo DMARC mailing list damage. It's not important unless
you forward mail like a mailing list does.
No it doesn't. It requires the previously unsolved problem of reputation which manifestly incapable of being solved. DMARC is not the problem, ancient mailing list technology which came before security requirements is the problem.
I'll be eager to see the papers substantiating this. Until then I remain completely skeptical. It's an experimental RFC for a reason. Let's see the data.
I'd also like to see a paper substantiating your claim that mailing lists do a bad job of spam filtering. In my experience it is a non-problem.
It appears that Michael Thomas <mike@mtcc.com> said:
ARC lets the recipient system look back and do what we might call
retroactive filtering, using info about messages as they arrived at
the previous forwarder. While it would be nice if lists did a better
job of spam filtering, they don't, and ARC is a reasonable remedy for
that.
I'll be eager to see the papers substantiating this. Until then I remain
completely skeptical. It's an experimental RFC for a reason. Let's see
the data.
I'd also like to see a paper substantiating your claim that mailing
lists do a bad job of spam filtering. In my experience it is a non-problem.
People from Google have told me that is the specific reason that they
need all the complexity of ARC rather than just whitelisting mailing
lists. If you think they're lying, or you know more about their mail
stream than they do, not much we can do about that.
Then they should publish it since it's an IETF document it so everybody can evaluate it. Otherwise it's just a private vanity project. I've seen absolutely nothing to conclude it is not.
And impugning me about "lying" is an ad hominem and against NANOG's rules.
But nor are mailing lists/listservs. Most of the guidance on "lists" seems to be related to marketing lists (which I hate way more, but gmail seems to be quite forgiving of), vs discussion lists.
Also, the error message we're getting speaks to the reputation of "our domain", not our IP block. Otherwise, I would think v4 mail would bounce as well.
Now, if that's caused by our staff posting to *other* mailing lists that do not do ARC, we have zero control over that.
If it's being implied that gmail is ranking us (i.e. dkim-signed and spf-compliant mail from Mark Andrews to *this list*) with a "very low" reputation because *our* mailman lists don't presently do arc-sealing, then could someone from google please tell me that canonically?
Google has been trying to move away from Internet email for many years
now. Just let them. There is no way you can "fix" that problem on your
side.
If you care about specific recipients, then inform them that Google
randomly throws away some of their legitimate email. Send a paper mail
or phone them if necessary. That's pretty much all you can do. If
those recipients continue to use gmail, then that's their decision and
problem.
)