date:20220402


On Sat, 2 Apr 2022, Michael Thomas wrote:



On 4/2/22 6:21 PM, John Levine wrote:

It appears that Michael Thomas  said:


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.


ARC is not mentioned here:

https://support.google.com/mail/answer/81126?hl=en

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?


-Dan


--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Enhance CG-NAT Re: V6 still not supported


Hi, Matt:

1)    The challenge that you described can be resolved as one part of 
the benefits from the EzIP proposal that I introduced to this mailing 
list about one month ago. That discussion has gyrated into this thread 
more concerned about IPv6 related topics, instead. If you missed that 
introduction, please have a look at the following IETF draft to get a 
feel of what could be done:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space 



2)   With respect to the specific case you brought up, consider the EzIP 
address pool (240/4 netblock with about 256M addresses) as the 
replacement to that of CG-NAT (100.64/10 netblock with about 4M 
addresses). This much bigger (2^6 times) pool enables every customer 
premises to get a static IP address from the 240/4 pool to operate in 
simple router mode, instead of requesting for a static port number and 
still operates in NAT mode. Within each customer premises, the 
conventional three private netblocks may be used to handle the hosts (IoTs).


3)    There is a whitepaper that presents an overview of other 
possibilities based on EzIP approach:


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Hope the above makes sense to you.

Regards,


Abe (2022-04-02 23:10)






On 2022-04-02 16:25, Matthew Petach wrote:



On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta 
 wrote:



If you make the stateful NATs static, that is, each
private address has a statically configured range of
public port numbers, it is extremely easy because no
logging is necessary for police grade audit trail
opacity. 


                Masataka Ohta


Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Internet soon enough; you're all
second class citizens that can't run your own servers;
if you need to do that, you can go pay Amazon to host
your server needs."

And perhaps that's not as unreasonable as it first sounds;
we may all start running IPv4-IPv6 application gateways
on Amazon, so that IPv6-only networks can still interact
with the IPv4-only internet, and Amazon will be the great
glue that holds it all together.

tl;dr -- "if only we'd thought of putting a port number field
in the NS records in DNS back in 1983..."

Matt




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Gmail (thus Nanog) rejecting ipv6 email




On 4/2/22 8:01 PM, John Levine wrote:

It appears that Michael Thomas  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.

Mike

Re: Gmail (thus Nanog) rejecting ipv6 email

It appears that Michael Thomas  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.

R's,
John

Re: Gmail (thus Nanog) rejecting ipv6 email




On 4/2/22 6:21 PM, John Levine wrote:

It appears that Michael Thomas  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'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.


Mike

Re: Gmail (thus Nanog) rejecting ipv6 email




On 4/2/22 6:16 PM, John Levine wrote:

It appears that Michael Thomas  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.


Mike

Re: Gmail (thus Nanog) rejecting ipv6 email from poorly configured senders

It appears that Niels Bakker  said:
>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.

R's,
John

Re: Gmail (thus Nanog) rejecting ipv6 email

It appears that Michael Thomas  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.

R's,
John

Re: Gmail (thus Nanog) rejecting ipv6 email

It appears that Michael Thomas  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.

R's,
John

Re: [nanog] Re: Gmail (thus Nanog) rejecting ipv6 email


On Sun, 3 Apr 2022, Jeroen Massar wrote:


Hi Dan,

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
  (https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
- 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:

https://internet.nl/mail/isc.org/

• 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.


This is a somewhat broken test.

-Dan

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Re: [nanog] Re: Gmail (thus Nanog) rejecting ipv6 email


On Sun, 3 Apr 2022, Niels Bakker wrote:

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.


I too have encountered this.

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- 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.




And it's september.



-Dan


--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Re: Gmail (thus Nanog) rejecting ipv6 email



On 4/2/22 4:05 PM, John Curran wrote:
On 2 Apr 2022, at 6:23 PM, Jeroen Massar via NANOG  
wrote:
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
  (https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
- SPF
- DKIM
- DMARC
- ARC (for mailinglists)
- 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…!)



That's why I wrote this:

https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html

Trust me, it wasn't for lack of trying on my part.

Mike

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-04-02 Thread Fred Baker

Sent using a machine that autocorrects in interesting ways...

> On Apr 2, 2022, at 5:57 AM, Abraham Y. Chen  wrote:
> 
> 1)" ...  darknet ...  ":I am not aware of this terminology. 
> Nonetheless, I believe that bringing in a not commonly known word into a 
> discussion like this is just distraction tactic.

It’s actually a pretty common word for a prefix or other set of addresses used 
to detect address scans. If an address is unused and not in DNS, a packet sent 
to it is not obviously benign, nor is the systemvv be sending it.

Re: Gmail (thus Nanog) rejecting ipv6 email




On 4/2/22 3:56 PM, Jeroen Massar wrote:



On 3 Apr 2022, at 00:29, Michael Thomas  wrote:


On 4/2/22 3:23 PM, Jeroen Massar via NANOG wrote:

Hi Dan,

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
(https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
  - SPF
  - DKIM
  - DMARC
  - ARC (for mailinglists)

Seriously spend zero time on ARC. It doesn't work as advertised... [snip, see 
below]

Unless one works at the large ESPs, hard to tell what they really care about 
and verify.

Google at least adds ARC headers in Gmail, and did the editing of RFC8617.


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.

Mike

Re: Gmail (thus Nanog) rejecting ipv6 email

2022-04-02 Thread John Curran

On 2 Apr 2022, at 6:23 PM, Jeroen Massar via NANOG  wrote:
> 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
>   (https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
> - SPF
> - DKIM
> - DMARC
> - ARC (for mailinglists)
> - 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.

Re: Gmail (thus Nanog) rejecting ipv6 email

2022-04-02 Thread Jeroen Massar via NANOG

> On 3 Apr 2022, at 00:29, Michael Thomas  wrote:
> 
> 
> On 4/2/22 3:23 PM, Jeroen Massar via NANOG wrote:
>> Hi Dan,
>> 
>> 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
>>(https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
>>  - SPF
>>  - DKIM
>>  - DMARC
>>  - ARC (for mailinglists)
> 
> Seriously spend zero time on ARC. It doesn't work as advertised... [snip, see 
> below]

Unless one works at the large ESPs, hard to tell what they really care about 
and verify.

Google at least adds ARC headers in Gmail, and did the editing of RFC8617.

MS seems to do something with it:

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide#how-microsoft-365-utilizes-authenticated-received-chain-arc

and https://prodmarc.com/knowledge/authenticated-received-chain/ states:
8<
Who has adopted ARC? 

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:

BIMI -- https://bimigroup.org

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)

At least they are 'honest' about the scam:
https://bimigroup.org/vmcs-arent-a-golden-ticket-for-bimi-logo-display/

but the big ones support it too  
https://support.google.com/a/answer/10911432?hl=en

but https://bimigroup.org/bimi-generator/

BIMI record not found for gmail.com.
BIMI record not found for google.com.
BIMI record not found for yahoo.com.
BIMI record not found for microsoft.com.

Interesting as https://bimigroup.org/bimi-infographic/ claims they 'support' 
it... view only maybe? but from where?

At least there is:
BIMI record found for bimigroup.org, and is BIMI compliant

v=BIMI1; l=https://bimigroup.org/bimi-sq.svg; a=
https://bimigroup.org/bimi-sq.svg

Oh well, 3rd of April, not the 1st... yet another Internet money printing 
thing...

Greets,
 Jeroen

Re: Gmail (thus Nanog) rejecting ipv6 email




On 4/2/22 3:23 PM, Jeroen Massar via NANOG wrote:

Hi Dan,

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
(https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
  - SPF
  - DKIM
  - DMARC
  - ARC (for mailinglists)


Seriously spend zero time on ARC. It doesn't work as advertised and is 
basically snake oil.


Mike

Re: Gmail (thus Nanog) rejecting ipv6 email

2022-04-02 Thread Niels Bakker


* d...@prime.gushi.org (Dan Mahoney (Gushi)) [Sun 03 Apr 2022, 00:11 CEST]:
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.



-- Niels.

Re: Gmail (thus Nanog) rejecting ipv6 email

2022-04-02 Thread Jeroen Massar via NANOG

Hi Dan,

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
   (https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS)
 - 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:

https://internet.nl/mail/isc.org/

• 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... ;) )

Gmail (thus Nanog) rejecting ipv6 email

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)

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Re: Let's Focus on Moving Forward Re: V6 still not supported

Hi, Christian:

1) I am a person who normally does not do hearsay. This was why I put
the unverified "street legend" about ancient Lord in parentheses to just
hint the possible extreme. Without it, the flow of my short story really
does not change. Since you spotted on it, I went back to search for the
online article that I had in mind. The following URL is likely what I
read because the keyword "Celtic" linked my vague understanding of
Ireland to England in general:

https://www.smithsonianmag.com/smart-news/tollund-man-europe-bog-body-meal-food-history-mummy-180978247/

There were several hypotheses in the above hinting the
interpretation that I got. The following citation seems to be more
specific.

“In Ireland, the king is the pivotal member of society, so when things
go wrong, he pays the price,” says Kelly. “All the new bodies discovered
since then have reaffirmed this theory.

For sure, this subject is off topic on this mailing list. Have fun to
dig into it, if you like. I will be glad to carry on with you offline.

2) " I am not assured that my interests are protected from anybody by
being told I have no direct access to people I want to communicate with
but have to go through a third party. ... ": I am not sure that I
can properly decipher your precise preference through a long paragraph.
But, based on your general tone, I get the sense that you prefer the
current "Internet way" than a more explicit and rigid communication
system convention that EzIP proposes. If so, you might be living in fantasy:

A. Note that the privacy and security issues are multi-faceted.
One has to look at them from the perspectives of both the victims and
the perpetrators. There was a "classic" paper a long time ago (2006)
that made this painfully clear.

Internet Geolocation and Evasion

https://www.ccsl.carleton.ca/paper-archive/muir-computingsurveys-09.pdf

It was a long research paper. But, a concise summary was given in
Section 6 Concluding Remarks:

*
We note that even if accurate IP geolocation is possible for 99% of IP
addresses, if the remaining 1% is fixed and predictable by an adversary,
and such that the adversary can place themselves within this subspace,
then they can evade geolocation 100% of the time.

Judging by the facts that the targeted marketing is very successful
these days, while it is very challenging to identify, let alone to
locate, a perpetrator, the above is most likely still true.

B. On the other hand, governments have been taking advantage of
the current Internet privacy practices as the excuse to actually invade
individual's privacy. See below for a recent status report:

'A free pass to seize and sift': Federal court upholds terrorism
conviction in controversial mass surveillancecase

https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/

3) Based on the master/slave relationship, the current sever/client
operation model dominates the Content Delivery Networks (CDN) that even
handles eMail services (probably by offering their off-peak spare
capacity, since eMail is time insensitive). This was evidenced by eMail
services got interrupted when Netflix service was down recently. This
means that, like it or not, individual's communications have been
buffered, relayed, etc. along the way, giving more than enough
opportunities for the "free service" third, or fourth party providers to
do whatever they wish, anyway. So, we should stop the current kind of
ostrich mentality for our own good. What EzIP proposes is to forget
about all these current fictitious "protections", but go back to the
explicit communications disciplines of yesterday years. So that, the
behind-the-scene mass surveillance will be outlawed again. Then,
whenever there is any need to monitor a suspected party, an explicit
request must be first made by a law enforcement agency to the court.
Sorry to those businesses who provide surveillance and analysis
equipment (computers and memories) as well as service to law enforcement
agencies.

Regards,

Abe (2022-04-02 17:50)

On 2022-04-02 12:13, christian de larrinaga wrote:

Your take on English history is a delightful fantasy but it is
just that a delightful fantasy. Norman barons were not typically
concerned with the health of their anglo saxon/british serfs / yoemen
other than providing the required tithes.

But taking you at what seems to be your intention. Speaking as a digital
peasant I am not assured that my interests are protected
from anybody by being told I have no direct access to people I want to
communicate with but have to go through a third party. Any addressing
model that terminates address space between me and

TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

2022-04-02 Thread John Curran

NANOGers -

As previously reported here, ARIN will be shutting down the ARIN-NONAUTH IRR 
database on Monday, 4 April 2022 at 12:00 PM ET.

It is quite likely that some network operators will see different route 
processing as a result of this change, as validation against the ARIN-NONAUTH 
IRR database will not longer be possible.

Please be aware of this upcoming event and make alternative arrangements if you 
are presently relying on upon routing objects in the ARIN-NONAUTH IRR database.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: John Curran mailto:jcur...@arin.net>>
Subject: TIMELY - IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR 
scheduled for 4 April 2022
Date: 25 March 2022 at 7:26:06 PM EDT
To: nanog list mailto:nanog@nanog.org>>

NANOGers -

Please take note of the following event that will take place in less than 10 
days time - ARIN will shut down the ARIN-NONAUTH IRR database on Monday, 4 
April 2022 at 12:00 PM ET

Any networks relying on upon routing objects in the ARIN-NONAUTH IRR database 
should be actively working on alternative arrangements.

If you have questions about this transition or need any assistance, you can 
contact ARIN by:

• Submitting an Ask ARIN ticket or chat with us using your ARIN Online account
• emailing the Routing Security Team at 
routing.secur...@arin.net
• contacting the Registration Services Help Desk by phone Monday through 
Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660

Thank you!
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: John Curran mailto:jcur...@arin.net>>
Subject: IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR 
rescheduled for 4 April 2022
Date: 16 February 2022 at 4:33:24 PM EST
To: NANOG Operators' Group mailto:nanog@nanog.org>>

NANOGers -

An important reminder – On 4 April 2022, ARIN's non-authenticated Internet 
Routing Registry (IRR) will be retired.

Please review the attached notice for details, and do not hesitate to contact 
ARIN if you have any questions about this transition or need assistance.

I ask that you do not hesitate to forward this notice to any others you know 
that are potentially unaware & impacted by this important transition.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] UPDATE: Retirement of ARIN Non-Authenticated IRR 
rescheduled for 4 April 2022
Date: 28 January 2022 at 9:01:07 PM GMT+4
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

This announcement is to inform you that the retirement of the ARIN 
non-authenticated Internet Routing Registry (IRR) has been rescheduled to 4 
April 2022 at 12:00 PM EST. After this time, users will no longer be able to 
create, update, or delete records in the ARIN-NONAUTH database, and the 
ARIN-NONAUTH data stream will no longer be available in Near Real Time 
Mirroring (NRTM) or via FTP or Whois Port 43. This date change is being made in 
order to ensure that the first day after retirement does not fall on a Friday.

The following information is from the initial announcement:

ARIN has been engaged in a multi-year project to create and deploy a new and 
improved Internet Routing Registry (IRR). As a result of these efforts, ARIN 
now provides users with the ability to create, update, and delete objects in 
ARIN’s authenticated IRR database using ARIN Online or ARIN’s RESTful API. 
Unfortunately, use of ARIN’s previous non-authenticated email-based IRR service 
actually increased after ARIN released its authenticated IRR, in opposition to 
the outcome ARIN anticipated when improving its IRR.

On 8 February 2021, ARIN held a consultation to solicit input on the retirement 
of ARIN’s non-authenticated email-based IRR service. This retirement was 
originally scheduled for 30 September 2021. Based on community input, the 
proposed date for the ARIN-NONAUTH retirement was delayed to 31 March 2022 to 
allow more transition time for users. We also notified by email Points of 
Contact (POCs) of organizations who have objects in the ARIN-NONAUTH database 
of the retirement date and offered them our assistance with the transition.

If you have questions about this transition or need assistance, you can contact 
us by:

• submitting an Ask ARIN ticket or chat with us using your ARIN Online account
• emailing the Routing Security Team at 
routing.secur...@arin.net
• contacting the Registration Services Help Desk by phone Monday through 
Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660

Regards,

Brad Gorman
Senior Product Owner, Routing Security
American Registry for Internet Numbers (ARIN)

Unsolicited marketing (was: Re: Cogent ...)

2022-04-02 Thread John Curran

On 31 Mar 2022, at 12:11 PM, Laura Smith via NANOG 
mailto:nanog@nanog.org>> wrote:
...
The ironic thing is they demand NDAs and yet they don't comply with requests to 
stop unsolicited marketing despite written historical promises that they would.

While I cannot speak to their marketing practices in general, Cogent has taken 
specific positive steps to avoid inadvertant use of the ARIN Whois data for 
solicitation (taking place after our January 2020 engagement with them on this 
topic), and in August of 2020 they regained direct access to the publicly 
available ARIN Whois data.  We do occasionally get reports of potential misuse, 
but it is definitely far fewer than before (and many track back to contact 
information provided to them via other means.)

As always, if you believe that your ARIN Whois contact information has been 
inappropriately used for solicitation by any organization, you can report it to 
us at complia...@arin.net for review and potential 
investigation.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: V6 still not supported

2022-04-02 Thread Matthew Petach

On Fri, Apr 1, 2022 at 6:37 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

>
> If you make the stateful NATs static, that is, each
> private address has a statically configured range of
> public port numbers, it is extremely easy because no
> logging is necessary for police grade audit trail
> opacity.

Masataka Ohta
>

Hi Masataka,
One quick question.  If every host is granted a range of public port
numbers on the static stateful NAT device, what happens when
two customers need access to the same port number?

Because there's no way in a DNS NS entry to specify a
port number, if I need to run a DNS server behind this
static NAT, I *have* to be given port 53 in my range;
there's no other way to make DNS work.  This means
that if I have two customers that each need to run a
DNS server, I have to put them on separate static
NAT boxes--because they can't both get access to
port 53.

This limits the effectiveness of a stateful static NAT
box to the number of customers that need hard-wired
port numbers to be mapped through; which, depending
on your customer base, could end up being all of them,
at which point you're back to square one, with every
customer needing at least 1 IPv4 address dedicated
to them on the NAT device.

Either that, or you simply tell your customers "so sorry
you didn't get on the Internet soon enough; you're all
second class citizens that can't run your own servers;
if you need to do that, you can go pay Amazon to host
your server needs."

And perhaps that's not as unreasonable as it first sounds;
we may all start running IPv4-IPv6 application gateways
on Amazon, so that IPv6-only networks can still interact
with the IPv4-only internet, and Amazon will be the great
glue that holds it all together.

tl;dr -- "if only we'd thought of putting a port number field
in the NS records in DNS back in 1983..."

Matt

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC


Hi, Pascal:

0)    As the good old saying stated: "A picture is worth one thousand 
words." Let's take advantage of such a teaching.


1)    Focusing at just the text before and after Figure 1 of your below 
draft, I found:


https://datatracker.ietf.org/doc/html/draft-thubert-v6ops-yada-yatt-01

    A.    " In the analogy of a building, */the ground floor would be 
the Interne/*t, and each additional floor would be */another IPv4 
realm/*.  ...  analog to */the full IPv4/**/addressing /*that is 
available in each realm.  ": Unless there is certain hidden refinement 
that I could not decipher, the combination of the three phrases 
highlighted above by me seems to refer to the entire IPv4 netblock, 
addresses and practices, etc., all inclusive. (By the way, the phrase 
"ground floor" appears to contradict the "(current IPv4 Internet)" label 
in the figure that is on the top floor (realm 1) of a building. Unless, 
you are presenting an underground building? But, we can regard this as a 
minor typo.)


    B.    " ... A single /24 IPv4 prefix assigned allows for*/> 250 
times the capacity of the Internet as we know it /*...   ": Are you 
visualizing that your YADA / YATT draft proposes creating >250 layers of 
cyberspace, each with the same capacity of the current Internet? If so, 
it will be fantastic. Then, how can you physically deploying that many 
layers, each fully covering the entire globe, yet without stepping on 
one another's toes (the identical IP addresses packed >250 deep)? That 
is, I failed to imagine what kind of mechanism that you have for 
isolating the layers, such as populating people accordingly.


Please clarify.

Regards,


Abe (2022-04-02 12:22 EDT)






On 2022-04-02 04:56, Pascal Thubert (pthubert) wrote:


That does not need to be long, Abe.

There’s no minimal interval between version. I already published 01… 
And I do not have a special address format beyond what’s in the draft 
already. It’s only IPv4 and IPv6. No new address format. Just assigned 
ranges, and well known IIDs.


To your point: the addresses in each realm are the full IPv4 that we 
know and they cannot talk directly between realms. They are indeed 
isolated. Nodes in different floors can only communicate through the 
shaft. Think of a human and a stairwell. The physical space reserved 
for the stair well at each level is the same.  What people do with the 
rest of the space is their own. All addresses and AS numbers are reusable.


I do not see you image of a sphere. My image of  a sphere is IPv6, 
that contains all the IPv4 “planes”, the shaft, and all the air in 
between.


You design uses the internet as shaft if you like. In that we differ. 
YADA leaves the internet as is, and allows to build other internets 
that cannot leak in one another. But participating nodes can 
communicate through the shaft.


If end nodes do not participate, then a stateful Nat is still needed. 
For most homes that means an upgrade of the stateful NAT in the 
gateway so the public side has a YATT format, and DNS snooping to 
provide a A record inside. Same for PLATs. For most servers, that 
means an update in the load balancer, and a NAT if there was none, to 
allow to speak to other realms. Whatever happened in the current IPv4 
can still do. Some levels can be created IPv6 only from the start, 
providing YATT addresses to those who need to communicate with the 
other levels.


Keep safe;

Pascal

*From:* Abraham Y. Chen 
*Sent:* vendredi 1 avril 2022 23:45
*To:* Pascal Thubert (pthubert) ; Vasilenko Eduard 
; Justin Streiner 

*Cc:* NANOG 
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not 
supported re: 202203261833.AYC


Hi, Pascal:

1)    " ... for the next version. ...   ":    I am not sure that I can 
wait for so long, because I am asking for the basics. The reason that 
I asked for an IP packet header example of your proposal is to 
visualize what do you mean by the model of "realms and shafts in a 
multi-level building". The presentation in the draft sounds okay, 
because the floors are physically isolated from one another. And, even 
the building is isolated from other buildings. This is pretty much how 
PBX numbering plan worked.


2)    When you extend each floor to use the whole IPv4 address pool, 
however, you are essential talking about covering the entire surface 
of the earth. Then, there is no isolated buildings with isolated 
floors to deploy your model anymore. There is only one spherical layer 
of physical earth surface for you to use as a realm, which is the 
current IPv4 deployment. How could you still have multiple full IPv4 
address sets deployed, yet not seeing their identical twins, triplets, 
etc.? Are you proposing multiple spherical layers of "realms", one on 
top of the other?


2)    When I cited the DotConnectAfrica graphic logo as a visual model 
for the EzIP deployment over current IPv4, I was pretty specific that 
each RAN was tethered from the current Internet core via one IPv4

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-04-02 Thread christian de larrinaga via NANOG



Your take on English history is a delightful fantasy but it is
just that a delightful fantasy. Norman barons were not typically
concerned with the health of their anglo saxon/british serfs / yoemen
other than providing the required tithes.

But taking you at what seems to be your intention. Speaking as a digital 
peasant I am not assured that my interests are protected
from anybody by being told I have no direct access to people I want to
communicate with but have to go through a third party. Any addressing
model that  terminates address space between me and someone I
communicate with also terminates my communications and security and by
so doing introduces a number of uncertainties potentially rather
arbitrary to what would otherwise be under my direct policy domain.

C


"Abraham Y. Chen"  writes:

> Hi, Christian:
>
> 0)    Allow me following your "towers of babel world" metaphor to tell
> a short story.
>
> 1)    In the ancient days, peasants labored under the shadow of the
> Tower, following the rules of and paid tax to the Lord living in the
> Tower. In return, they expected protection from the Lord against
> harms. (Sometime ago, I read an archaeological article reporting
> certain evidence that the Load somewhere in England during medieval
> time might have been expected to protect his peasants from any harm,
> including even paid his life for famine.)
>
> 2)    In the modern world, the peasants still live around the Tower
> following the rules, paying taxes and expecting protection from the
> Lord, now represented by the government agencies such as local police,
> FCC, FTC, DoD, DHS, etc.
>
> 3)    In the Internet era, the peasants roam everywhere around the
> cyberspace freely enjoying the Internet way. However, their wealth is
> now being siphoned out to the invisible Lords (the multi-national
> businesses with virtual presence in each and every Tower). However,
> little can be expected in return when perpetrators attack, because no
> Lord assumes the responsibility, nor any can be held responsible.
>
> 4)    EzIP proposes an overlay cyberspace with geographic flavor to
> restore the society infrastructure back to Pt. 2) above, while
> providing the daily services of Pt. 3). It essentially offers a
> parallel Internet for the peasants who can again expect protection
> from their local government who collects taxes, while without losing
> the benefits of the digital revolution.
>
> 5)    The two cyberspaces are expected to coexist and none-interfering
> to each other. Peasants have the freedom of choice by living in either
> or try both then decide.
>
> The above is just a quick rough thought, far from polished. It is
> intended to be a preliminary framework so that we can hang some meat
> on it for starting meaningful discussions.
>
> Regards,
>
>
> Abe (2022-04-01 14:17)
>
>
>
>
>
>
> On 2022-03-27 11:03, Christian de Larrinaga wrote:
>>
>>
>> On 27 March 2022 15:53:25 Brandon Butterworth 
>> wrote:
>>
>>> On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:
 EzIP proposes to deploy 240/4
 address based RANs, each tethering off the current Internet via
 one IPv4
 public address.
>>>
>>> So each RAN has no possibility of redundant connections? Nobody
>>> of scale would accept such a limitation. It also looks like an
>>> opportunity for telcos/governments to partition their part
>>> of the internet and impose whatever censorship they wish.
>>>
 As such, the collection of RANs forms an overlay network
 layer wrapping around the current Internet core. Consequently, only the
 SPRs in the RAN need to be able to transport 240/4 addressed packets.
>>>
>>> You previously described this as like connecting CG-NATs together via a
>>> VPN. I don't see why we'd want to add maintaining a global VPN to
>>> already difficult peering relationships. It could be used to exlude non
>>> EzIP club members.
>>>
 This is why we talk about enabling new (but based on existing design)
 routers to use 240/4 netblock for serving as SPRs, but not perturbing
 any routers in the current Internet.
>>>
>>> As it's a CG-NAT variant why are you delaying yourself by requiring
>>> new address space that will take a long time to become available? Why
>>> not use the already allocated space for CG-NAT? Sure it's only a /10
>>> but that's an already (probably too) large RAN.
>>>
>>> It also seems unfeasibly optimistic that if the work was done globally
>>> to make 240/4 useable that they'd want to dedicate it to the as yet
>>> undeployed EzIP. You might stand more chance if you gained some
>>> critical mass using the existing available 100.64/10 & rfc1918 space,
>>> and then those that find they need more in one RAN will make the case
>>> for 240/4 when it becomes necessary for them. Is 240/4 special to
>>> EzIP such that alternative numbers may not be used?
>>>
 I would like to share one intriguing graphics (see URL below) that
 is almost perfect for depicting the EzIP

Re: Let's Focus on Moving Forward Re: V6 still not supported