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

[Keith Moore <[e-mail]>]

Thanks for providing a list, though I wonder if this is the same as the 
list that John referred to.

I do suspect that the list could use some updating.   For example:

On 10/4/20 1:52 PM, Richard Clayton wrote:
> For the next few years however:
>
> *  Use a static IPv4 address for your email system

IMO this should change to support the reality that IPv4 addresses are 
getting scarcer by the day, especially in some parts of the world.  
(Especially given the inertia that likely exists with such rules, 
changing the rules now may be necessary to ensure smooth operation in a 
year or two)

e.g.

- Provide inbound SMTP service at one or more public IPv6 addresses.

- Also, if possible, provide inbound SMTP service at one or more public 
IPv4 addresses.

- Provide at least outbound SMTP relay using public IPv6.

- If possible, relay outbound SMTP mail using a public address of the 
same type as the destination address, rather than through a NAT46 or NAT64.

> *  Do not share this IPv4 address with user machines
Do not share addresses of client or server (inbound or outbound) SMTP 
with user machines.
> *  Do not host your email system ‘in the cloud’
I'm not sure what this actually means or why it's still a bad idea.   
Cloud hosting makes a lot of sense for various reasons.
> *  Make sure that your IP address is not listed in the PBL

I suspect that this is something that sites will have less and less 
control over in the future, at least in IPv4 space, especially given the 
"marketplace" in IPv4 prefixes and the need to have different sites' 
addresses in different IPv4 subnets (also has to do with limitations of 
DNS in-addr.arpa delegation).

> *  Provide an MX record
>
> *  Provide meaningful and consistent reverse DNS
>
> *  Your system should say HELO (or EHLO) with its hostname

Could use better definition of "its hostname".   Suspect you mean EHLO 
name should match PTR lookup of client's source IP address.

IMO that might be a bit limiting - I would really like to see TLS with 
client certs used for relay in the future if the details can be worked 
out, and in that case EHLO name should probably match client cert name.

> *  Keep your software completely up-to-date
up-to-date != minimal bugs.
> *  Use a submit port with effective authentication or strict
>     IP access controls
Could be reworded, I think.   Ideally a site would not relay any 
unauthenticated mail, no matter how it got into the site's mail system.
>
> *  Limit outgoing email volumes
>
> *  Accept reports of problems with your systems
Is there a more recent standard for doing so than postmaster@?
>
> *  Review the mail system logs on a regular basis
>
> *  Ensure your system is highly reliable
>
> *  Don’t create backscatter
>
> *  Maintain a good reputation

Anyway, looks like a good start, though I wonder what "well established 
anti-abuse metrics" others might have in mind.

I'd support an effort to update and formalize these.

Keith