SMTP stone age: Add a straight no-auth, no-TLS-required SMTP server accepting port 25 accessible from AA IPs

Some IOT devices, an example being one of my WAPs, need access to mail submission facilities and need to access SMTP servers yet can't speak TLS and possibly can't even cope with SMTP-auth. We should keep port 25 going for customers with this kind of kit, for email submission coming from AA-provided IPs.

It's not necessary that port 25 be kept going on smtp.aa.net.uk if AA wants to really dissuade customers from using non-TLS mail submission routinely, could make an alternative mail submission agent server. It would just mean that there would be some breakage until customers update some affected boxes.

A lot of such primitive kit doesn't grok alternative port numbers either, so keep to port 25 on this server, plus any other ports needed.

Also a related suggestion. Suggest having the capability to add extra username plus password pairs into clueless for use in SMTP-AUTH only, by IOT devices for example. It's not a good idea to have to store a real mailbox user’s credentials into such a box just so it can access SMTP-auth, because there might not be any convenient email address to use as a username and also there is the danger of breakage when the real human user changes that password. It's wasteful to have to create an extra mailbox just to get another username-password pair for an iot box to use - is that the only workaround?

I have such kit which now doesn't work, for some reason. It can't speak TLS SMTP when doing mail submission, although it can speak SMTP-auth. And I of course have the nuisance random tin box’s username-password problem too which is a bit of a nuisance. I should try and set up mail submission credentials for AA systems that all such boxes can use, with passwords that don't change.

Not requiring TLS helps system administrators also by facilitating the use of CNAMEs (is this true?) designed to hide the actual smtp server that a tin box has to use and so protect the config from changes in the long term; examples are changes of ISP or a difference of requirements between one site and another, or one situation and another.