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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp