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

For the record, want to applaud you for tackling the DRAFT, just theeffort alone should be applauded, but no matter what discussions occur,it is a handy consolidated document of all the related topics..


...

However..

If it is specific to MAIL FROM: then maybe consider that it isn't an'email address' length problem. If it is, then it needs to beconsidered in a wider scope.

If it isn't then it should be considered a change to MAIL FROM handling,where it can accept more than an email address.. eg a 'routing'instruction, (which historically has became thought of as an 'emailaddress', and in some implementations the 'only' acceptable routinginstruction) .. simply because most implementations would not accept amessage from a "sender" or route that you could not route delivery back to.

It 'appears' that the problem you are trying to solve is a 'routing'issue, rather than an 'email address' issue. VERP and others are notreally email addresses, even though they are used in an email notation.

What you REALLY have to be saying is that the sender accepts longroutable information in it's sender information at it's MX..

But again, I might have questions.. I see a few bumping roads given theamount of MAIL FROM validation out there.. IF the MAIL FROM is notvalid, IMHO it means rejections.. in connection.. so not sure where thevalue is, but assuming you have have one.. once it passes the MTAacceptance layer, you expect it to be treated as an 'email address'..(or in rare cases a literal bounce/double bounce <>)

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 serverswhich 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 thesender that it could not complete the delivery, and while it might have'routing' instructions, it can't be seen as an email address. And ofcourse, now the CFD needs to know if the MX record associated with thatdomain can handle 'non-email' strings at it's MTA..

What would it do if it found that the original sending MTA could notaccept long routing instructions.. what does it do?

Personally, I think you might find that another approach to the problemmight be in order.. eg notifying a regular length email address aspresently permitted, that a message with this long string could not bedelivered.. we have that already in several forms..

I think more discussion in the DRAFT on the problem it is attempting tosolve is in order..


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 mightbe open to a 'longer' user part or domain being legal, no limits wouldbe disastrous IMHO ..


MAIL FROM: 
<me(_at_)longencylopiadesignedtoeffectivelyddosaserver(_dot_)(_dot_)xxxx>

Using MAIL FROM as a routing instruction.. fine.. it fundamentallyalways was.. even though IMHO it SHOULD be the actual sender's address,not a routing instruction..

But trying to use the MAIL FROM to embed other information is probablythe wrong direction, and if the purpose of this is strictly to allow theembedding of more data in the string, it probably will get less support,both in draft form, and in implementations..

If you need to communicate more information that just routing (or emailaddress) then maybe another method is more suitable.


Hope the comments are welcome..


On 2019-12-04 3:54 p.m., Viruthagiri Thirumavalavan wrote:

The draft focuses on the MAIL FROM email address length for betterbounce handling. Not the RCPT TO length.

On Thu, Dec 5, 2019 at 5:18 AM Kurt Andersen (IETF)<kurta+ietf(_at_)drkurt(_dot_)com <mailto:kurta%2Bietf(_at_)drkurt(_dot_)com>> wrote:


    And JMAP too...

    On Wed, Dec 4, 2019, 15:45 Michael Peddemors 
<michael(_at_)linuxmagic(_dot_)com
    <mailto:michael(_at_)linuxmagic(_dot_)com>> wrote:

        This might again be a question for the extra group to consider,
        but if
        looking at something like email length, that would apply to both
        IMAP
        and SMTP in a typical situation.

        How should things that apply across multiple protocols be
        addressed in
        general, I know that is one of the things mentioned when trying
        to get
        CLIENTID into the working group..

        On 2019-12-04 3:40 p.m., Viruthagiri Thirumavalavan wrote:
         > Hey all,
         >
         > This is my first internet draft I'm sharing here. So I hope
        you all will
         > bear with me on this.
         >
         > I didn't share my initial draft
         >
        <https://tools.ietf.org/html/draft-viruthagiri-email-address-length-00>

         > here. But, Dr. Klensin had given me feedback for that draft
        off-list.
         > Turns out I was listing outdated references in the
        normative references
         > section among other things.
         >
         > I have version 1
         >
        <https://tools.ietf.org/html/draft-viruthagiri-email-address-length-01>

         > now. It focuses only on the SMTP extension.
         >
         > Here is the abstract.
         >
         > ============
         >
         >
        https://tools.ietf..org/html/draft-viruthagiri-email-address-length-01

         >
        <https://tools.ietf.org/html/draft-viruthagiri-email-address-length-01>
         >
         > Abstract
         >
         >     This memo defines an SMTP extension with keyword "EAML"
        whereby an
         >     SMTP server can declare that it is capable of handling
        longer email
         >     addresses without any local-part or domain-part
        restriction set by
         >     RFC 5321.
         >
         >     EAML stands for "Email Address Maximum Length".
         >
         > ============
         >
         > This is how it works.
         >
         >                    S: 220 smtp.example.com
        <http://smtp.example.com> <http://smtp.example.com>
         > ESMTP Ready
         >                    C: EHLO bob.example.org
        <http://bob.example.org> <http://bob.example.org>
         >                    S: 250-smtp.example.com
        <http://250-smtp.example.com> <http://250-smtp..example.com
        <http://example.com>>
         >                    S: 250-EXPN
         > *S: 250-EAML 500*
         >                    S: 250-PIPELINING
         >                    S: 250 HELP
         >
         > The parameter omitted EAML keyword says:
         >
         >                    [*] No local-part limitation.
         >                    [*] No domain-part limitation.
         >                    [*] 254 maximum characters
         >
         > ============
         >
         > Any kind of feedback will be really helpful.
         >
         > Thanks
         > --
         > Best Regards,
         >
         > Viruthagiri Thirumavalavan
         > Dombox, Inc.
         >
         > _______________________________________________
         > ietf-smtp mailing list
         > ietf-smtp(_at_)ietf(_dot_)org <mailto:ietf-smtp(_at_)ietf(_dot_)org>
         > https://www.ietf.org/mailman/listinfo/ietf-smtp
         >

--"Catch the Magic of Linux..."

        ------------------------------------------------------------------------
        Michael Peddemors, President/CEO LinuxMagic Inc.
        Visit us at http://www.linuxmagic.com @linuxmagic
        A Wizard IT Company - For More Info http://www.wizard.ca
        "LinuxMagic" a Registered TradeMark of Wizard Tower
        TechnoServices Ltd.
        ------------------------------------------------------------------------
        604-682-0300 Beautiful British Columbia, Canada

        This email and any electronic data contained are confidential
        and intended
        solely for the use of the individual or entity to which they are
        addressed.
        Please note that any views or opinions presented in this email
        are solely
        those of the author and are not intended to represent those of
        the company.

        _______________________________________________
        ietf-smtp mailing list
        ietf-smtp(_at_)ietf(_dot_)org <mailto:ietf-smtp(_at_)ietf(_dot_)org>
        https://www.ietf.org/mailman/listinfo/ietf-smtp

    _______________________________________________
    ietf-smtp mailing list
    ietf-smtp(_at_)ietf(_dot_)org <mailto:ietf-smtp(_at_)ietf(_dot_)org>
    https://www.ietf.org/mailman/listinfo/ietf-smtp



--
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.




--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp