[170265] in North American Network Operators' Group
Re: why IPv6 isn't ready for prime time, SMTP edition
daemon@ATHENA.MIT.EDU (Laszlo Hanyecz)
Tue Mar 25 19:07:52 2014
From: Laszlo Hanyecz <laszlo@heliacal.net>
In-Reply-To: <20140325223858.GA25217@gsp.org>
Date: Tue, 25 Mar 2014 23:07:16 +0000
To: Rich Kulawiec <rsk@gsp.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
The OP doesn't have control over the reverse DNS on the AT&T 6rd. Spam =
crusades aside, it can be seen as just another case of 'putting people =
in their place', reinforcing that your end user connection is lesser and =
doesn't entitle to you to participate in the internet with the big boys. =
How does one dare run a 'server' without being a member of a RIR?
One would hope that with IPv6 this would change, but the attitude of =
looking down on end subscribers has been around forever. As seen in the =
other thread being discussed here, people are already looking for ways =
to block end users from participating. =20
-Laszlo
On Mar 25, 2014, at 10:38 PM, Rich Kulawiec <rsk@gsp.org> wrote:
> On Tue, Mar 25, 2014 at 02:57:15PM -0600, Brielle Bruns wrote:
>> Nothing wrong with my mail server setup, except the lack of RDNS.
>> Lacking reverse should be one of many things to consider with
>> rejecting e-mails, but should not be the only condition.
>=20
> Lack of rDNS means either (a) there is something temporarily wrong =
with
> rDNS/DNS or (b) it's a spam source or (c) someone doesn't know how to =
set
> up rDNS/DNS for a mail server. Over the past decade, (b) has been the
> answer to about five or six 9's (depending on how I crunch the =
numbers),
> so deferring on that alone is not only sensible, but quite clearly a
> best practice. If it turns out that it looks like (b) but is actually
> (a), then as long as the DNS issue clears up before SMTP retries stop,
> mail is merely delayed, not rejected. And although *sometimes* it's
> (c), why would I want to accept mail from a server run by people who
> don't grasp basic email server operation best practices? (Doubly so
> since long experience strongly suggests people that botch this will =
very
> likely botch other things as well, some of which can result in =
negative
> outcomes *for me* if I accomodate them.)
>=20
> Of all the things that we need to do in order to make our mail servers
> play nice with the rest of the world, DNS/rDNS (and HELO) are among
> the simplest and easiest.
>=20
> ---rsk
>=20
> p.s. I also reject on mismatched and generic rDNS. Real mail servers =
have
> real names, so if [generic] you insist on making yours look like a =
bot,
> I'll believe you and treat it like one.
>=20
