Isn't such issues also applicable to other SMTP extensions? e.g. Message
size declaration
While reading the rfc5321bis draft, I noticed this section which is the
same as 5321.
2.2.3. Special Issues with Extensions
Extensions that change fairly basic properties of SMTP operation are
permitted. The text in other sections of this document must be
understood in that context. In particular, extensions can change the
minimum limits specified in Section 4.5.3, can change the ASCII
character set requirement as mentioned above, or can introduce some
optional modes of message handling.
In particular, if an extension implies that the delivery path
normally supports special features of that extension, and an
intermediate SMTP system finds a next hop that does not support the
required extension, it MAY choose, based on the specific extension
and circumstances, to requeue the message and try later and/or try an
alternate MX host. If this strategy is employed, the timeout to fall
back to an unextended format (if one is available) SHOULD be less
than the normal timeout for bouncing as undeliverable (e.g., if
normal timeout is three days, the requeue timeout before attempting
to transmit the mail without the extension might be one day).
On Thu, Dec 5, 2019 at 3:39 PM Viruthagiri Thirumavalavan
<giri(_at_)dombox(_dot_)org>
wrote:
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
size declaration
And BTW..
| 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
<https://tools.ietf.org/html/draft-viruthagiri-email-address-length-01>
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.
Thanks
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp