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

[Ned Freed <[e-mail]>]

> 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 [e-mail] 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