Thanks for the feedback.
It 'appears' that the problem you are trying to solve is a 'routing'
issue, rather than an 'email address' issue.
Yes, you are right.
Imagine a cloud filtering device, should it accept non-email addresses
<sic> in the MAIL FROM, if it has to then deliver to other mail servers
which it does not know if they will accept such?
And what to do in the case of the remote server refusing the message?
The cloud filtering device (CFD) now has an obligation to notify the
sender that it could not complete the delivery, and while it might have
'routing' instructions, it can't be seen as an email address. And of
course, now the CFD needs to know if the MX record associated with that
domain can handle 'non-email' strings at it's MTA..
What would it do if it found that the original sending MTA could not
accept long routing instructions.. what does it do?
Isn't such issues also applicable to other SMTP extensions? e.g. Message
| TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION |
| TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH |
| OF THESE OBJECTS SHOULD BE USED.
I personally appose such an 'ideal' in these contexts.. while many might
be open to a 'longer' user part or domain being legal, no limits would
be disastrous IMHO ..
I think you were looking at my old version. My version 1
focuses only on the SMTP extension.
The part you mentioned originally coming from RFC 821.
But yes, I agree with you on this. This is one of the reasons why my
proposal have an upper cap. (900 octets)
Hope the comments are welcome..
Yes, your comments are always welcome.
ietf-smtp mailing list