ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Draft: SMTP Extension for Longer Email Address

2019-12-06 03:27:31

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