I think just about everything has been said beyond contacting the operators of
the
online testing tools and requesting that they update their tool or to take it
down.
A broken tool is worse that no tool. The is too much out-of-date stuff on the
Internet. We should all be doing our little bits
I remember. And I have the HE.net Guru Badge to prove it :)
And don’t forget the World IPv6 Launch in 2012.
IPv6. The protocol of the future, and always will be :)
-mel via cell
> On Feb 26, 2021, at 3:49 PM, Jay Hennigan wrote:
>
> On 2/13/21 18:24, Mark Foster wrote:
>
>> So the
In article
you write:
>1. Is there anyone actively using this Null MX? If so, may I please see
>that actual record line (in BIND zone file format) just to satisfy myself
>that I wrote mine correctly?
Yes.
services.net. 3600IN MX 0 .
>2. Which one makes more sense from the
On 2/13/21 18:24, Mark Foster wrote:
So the business case will be the 'killer app' or perhaps 'killer service'
that's IPv6-only and that'll provide a business reason.
But chicken and egg.. who wants to run a service that's IPv6-only and miss out
on such a big userbase?
Am I the only one
In article you write:
>Hmm right... Somehow I tought that having that special Null MX
>will silently discard message... I dont know why...
>
>So, RFC 7505 is pretty much even pointless in my opinion.
>You have to do more.. to pretty much achieve the same..
>Its just easier to not having MX on
On 2/26/21 12:10 PM, b...@uu3.net wrote:
Hmm right... Somehow I tought that having that special Null MX will
silently discard message... I dont know why...
It's Friday. I'm presuming that many of us have had a long week and are
ready for the weekend. ;-)
So, RFC 7505 is pretty much even
Dear all,
I put the “Null MX” Record (RFC 7505) into one of my domains yesterday,
then those online mail diagnostic tools out there start getting me worried:
It looks like most of those tools do not recognize the Null MX as a special
case; they just complain that they cannot find the mail
MTAs don’t care what online analysis tools tell you and setting a null MX for a
domain that you don’t receive mail for will work just fine, for the reasons
explained in the rfc
Having no MX means the smtp connection will fall back to the A record for your
domain if one exists
--srs
Well, I bet my legacy system will bounce it for example...
Postfix 3.0: RFC 7505 ("Null MX" No Service Resource Record), Earlier
Postfix versions will bounce mail because of a "Malformed DNS server reply".
I cant speak about Sendmail, qmail, Exim.. when they started supporting it.
So, In my
OARC 35 will be an online meeting on May 6th & 7th starting at 01:00 UTC. The
Programme Committee is seeking contributions from the community.
All DNS-related subjects and suggestions for discussion topics are welcome. For
inspiration, we provide a non-exhaustive list of ideas:
- Stories of
Peace
On Fri, Feb 26, 2021, 3:06 PM Rod Beck
wrote:
> My understanding is that there are three London Interxion data centers (I
> thought Equinix was the Borg and had assimilated pretty everything at this
> point).
>
> Trying to get the address where the facility where the London Metal
>
Hi Folks,
My understanding is that there are three London Interxion data centers (I
thought Equinix was the Borg and had assimilated pretty everything at this
point).
Trying to get the address where the facility where the London Metal Exchange
houses its trading engine. No, financial
On Fri Feb 26, 2021 at 12:05:14PM +, Rod Beck wrote:
> My understanding is that there are three London Interxion data centers (I
> thought Equinix was the Borg and had assimilated pretty everything at this
> point).
The competition authoritites stopped them, part of the Telecity
set of DCs
On 2/26/21 2:10 PM, b...@uu3.net wrote:
> Hmm right... Somehow I tought that having that special Null MX
> will silently discard message... I dont know why...
>
> So, RFC 7505 is pretty much even pointless in my opinion.
> You have to do more.. to pretty much achieve the same..
> Its just easier
On 2/26/21 11:46 AM, b...@uu3.net wrote:
Well, I bet my legacy system will bounce it for example...
What specifically is the bounce?
I thought the purpose of the Null MX was to do two things:
1) Provide as an MX that can't be connected to.
2) Serve as a signal to things that know how to
On Fri, 2021-02-26 at 12:03 -0700, Grant Taylor via NANOG wrote:
> On 2/26/21 11:46 AM, b...@uu3.net wrote:
> > Well, I bet my legacy system will bounce it for example...
>
> What specifically is the bounce?
> I thought the purpose of the Null MX was to do two things:
> 1) Provide as an MX that
Peace,
On Fri, Feb 26, 2021, 10:05 PM Matthew Petach wrote:
> Aren't they (LME) in Savvis, though?
>>
> That was certainly true in 2003, at least
>
Maybe it's still true today.
tax.select.prd.lmexgw.com.
*A*213.86.73.66
inetnum: 213.86.73.0 - 213.86.73.255
netname: NET-GB-LME
descr: LME
On Fri, Feb 26, 2021 at 4:56 AM Töma Gavrichenkov wrote:
> Peace
>
> On Fri, Feb 26, 2021, 3:06 PM Rod Beck
> wrote:
>
>> My understanding is that there are three London Interxion data centers (I
>> thought Equinix was the Borg and had assimilated pretty everything at this
>> point).
>>
>>
Hmm right... Somehow I tought that having that special Null MX
will silently discard message... I dont know why...
So, RFC 7505 is pretty much even pointless in my opinion.
You have to do more.. to pretty much achieve the same..
Its just easier to not having MX on subdomains that does not serve
OK. In your experience, which legacy system is going to misinterpret this
record?
The current RFC is from 2014-15 but the original idea from Mark Delany (then at
Yahoo now at Apple) has been kicking around from 2006 or so. I remember
contributing some text to the original draft RFC but can’t
Thats cute, but remember that there are gazylion of legacy systems
on Internet as well. They might have no clue what do do with it..
Also remember that MTA is supposed to accept email to [ip] too.
On my opinion, its best to just have no MX record at all.
While MTA can fallback and try to do
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
Daily listings are sent to
22 matches
Mail list logo
