I asked a similar question about CNAME records about 2 years ago, and
the consensus was that a relaying MTA must not change the recipients
address while the receiver MTA may treat the address any way it pleases.
When does this case even arise? If I relay on a message to an address involving
some random IP literal, that's pretty much the definition of an open relay. So
that's going to be blocked, and if it isn't, you have a problem that
transcends address rewriting issues.
In fact about the only relay case left that crosses between ADMDs is
secondary MXes, and that doesn't apply to IP address literals by definition.
And as for what happens inside of an ADMD, I'm afraid I really don't give a
damn what the standards say should or should not be done to addresses involving
IP addresses within my own infrastructure. I'll forward with rewriting, bounce,
discard, or do whatever I like with them as I choose. And my choices will
almost certainly be driven by security considerations more than anything.
Yes. On the other hand, on today's internet, if you get mail sent to
an address literal other than 127.0.0.1, the chances of it being something
you want to deliver are so low that I wouldn't worry about it, and I'd
just reject or discard it.
PS: I was going to say that I might make an exception for status messages
from IoT devices, but anything with enough software to do SUBMIT has enough
software to configure a DNS name.
Indeed. If an IoT device wants to send a status message, you have to be able to
configure an address as part of that. So even if you don't have a DNS stub
resolver, you simply have "IP address of SUBMIT server" instead of "name of
SUBMIT server" parameter. In neither case does it avoid the need to have an
"address to send to" parameter.
ietf-smtp mailing list