ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

2020-09-27 12:56:42
John,

(as with Keith earlier comment, this is not intended to be a
rant, but might come out sounding that way)

A pretty even-handed description of the situation IMO.

This is a self-fulfilling prophecy which gets back to Keith's
comment about resources.  In order to run an SMTP client or
server with any of the three ISPs I've dealt with recently, and
do so without violating the contracts they impose, I first have
to obtain a business account which is not much different from a
residential account other than costing three or four times as
much.

Around here the service isn't much more expensive, but getting it at
a residental location is difficult at best, impossible at worst.

Of course there's always the option of deplying in someone's cloud, but that
has issues of its own. For one thing, you're far more likely to get nailed by a
noisy neighbor in the cloud. (One of my neighbors is having exactly this issue
right now.)

Because the anti-spam powers that be don't think I should
be running either an SMTP server or a client on dynamic
addresses (even if I have dynamic DNS set up properly and
appropriate MX arrangements), I have to then obtain one or more
static addresses from said ISP and the costs of those are not
going down [1].

Add to that the number of providers who actually offer static IPs is
dropping, and the geographies where the remaining ones are
able to provide the service are also decreasing.

And, since the idea of delegating
reverse-mapping ranges on bit boundaries failed, once one has
those static addresses, one than has to convince the ISP to
provide the correct reverse mapping.  That, too, has costs -
either in terms of money or in efforts to negotiate.  There may
be ISPs out there who, upon supplying a static address  or
address range inquire how one would like the reverse mapping
records to read, or even insist on getting that information, but
I haven't encountered one yet.

Around here we have:

(1) HugeISP - I managed to get them to set my reverse names when my service
    was installed. As for updates, their elaborate web site, where
    my name appears as "null CUSTOMER", is so difficult to navigate it's
    impossible to be sure, but there doesn't seem to be a way to do it.
    But there is good news: They do let you give your modem a nickname.
    (I chose "Joe Egg".) So I guess a service ticket is necessary. Past
    experience with those has been mixed.

(2) MediumISP - Back when I used their service they had a really convenient
    web page that let you set them. 24 hour max turnaround. Sweet. The bad news
    is they are one of the ISPs who no longer offer static IPs in this
    area. 
    
(3) TinyISP - You call "the guy" and he takes care of it when he has a
    moment. Usually takes a day or two.

(4) FiberISP - Send mail to hostmaster(_at_)fiberisp(_dot_)net saying what you 
want
    changed. They stopped their buildout two blocks down the road because
    of a lawsuit, so no direct experience, but reportedly the possible
    responses include (a) Done and dusted, (b) You need to pay $$$ for that,
    and (c) Huh?

So, if the goal, however unintentionally, is to further reduce
the number of independent (and legitimate) SMTP clients and
servers, and force those without extensive resources to shift
over to large and dominant email providers, perhaps we are on
track.

The other thing that's worth noting is the frequency of forced IP address
changes. I've had this happen four times in the past 20 years, and each time
getting the PTRs set up has been the worst part of the process. And yes, it has
resulted in lost mail, so please don't try and tell me these checks never
impact legitimate senders.

It would be nice if mail still worked the way it did 30 years
ago, but that was most definitely then, and this is now.

And, from the standpoint of those large providers, the fight
against spam and other sorts of evil behavior would be ever so
much easier if they had only a handful of other providers to
work with s.t. anything not coming from one of them was suspect.
Of course, the way DMARC was developed and deployed might be
believed to reflect exactly that attitude.

Such a cynic ;-)

    john

                                Ned

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>