4a) maybe generalize #4 to include various other RFC issues (matching
PTR and A records is an RFC requirement, after all), such as the things
tracked at RFC-Ignorant
Less feasible, too many players.
How about: domain registrars are required to block any domain they
have registered that does not have working (i.e. read-by-a-human)
postmaster@ and abuse@ aliases?
Being that I am a domain registrar (small but still) how will I know if
they have a working postmaster or abuse alias? And even if they did a
quick filter setup at the server level will have those mails /dev/null'd
in no time. This isn't a feasible idea for one reason and one reason
only, Network Solutions. They'll find some way to re-route that domain
to their own use.
5) Require ISP's to channel their customer's email through their own
mail servers (which will have some impact upon SPF tracking as well)
and not allow any non-business customers, nor any dynamic customers
(business or commercial), to directly connect to other mail servers.
Totalitarian regimes will *love* that one. ISPs will hate it.
Hate to break the news to you but many ISPs are already not allowing
their users to connect via port 25 outside their networks. Comcast has
done it, as have a few others already. I run into this a lot because I'm
also a hosting company and offer SMTP Auth but many customers have
issues because they can't connect to port 25 on my mail server. I also
totally agree with this practice, if they are going to be on the hook
for something their users did then they need to keep a watchful eye on
their customers.
ISPs don't hate this considering that many ISPs now do hosting, it's a
way for them to get their customers to bring the hosting over to them also.
