ietf-smtp
[Top] [All Lists]

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

2019-12-06 14:01:46

Hi, Congrats! :)


Thanks :)

===============

The Abstract is good. Please consider adding a summary clause,
sentence indicating first a) the "problem" and b) how this proposed
extension can resolve it.   For example, the document indicate VERP
and SRS support can be a problematic.   This problem statement should
be in the abstract. It will help catch people who may have a known
issue with the extended protocols and this proposal may offer a
possible solution.  I normally don't read submissions unless the
abstract catches my interest.


Will correct it in the next version.

===============

Good, but this is about VERP and SRS. You explained how VERP/SRS
violated SMTP limits.  So is it really not an SMTP problem?
Have you explored other proposed solutions to the VERP or SRS problem?
   Is there a better solution for what VERP/SRS is trying to address?


I found two drafts. The first one you already aware of.

VERP  [July 1999]:
https://tools.ietf.org/html/draft-varshavchik-verp-smtpext-01

This proposal seems like trying to solve the bandwidth wastage problem by
making the receiver generate VERP addresses.  [Personal note: I like this
idea]

Quoting a part from that proposal

Unfortunately, VERPs require much more bandwidth and network
   resources than DSNs because VERPs cannot be used to send one copy of
   a mailing list message addressed to all the recipients in the same E-
   mail domain.


SRS [June 2003]:
https://web.archive.org/web/20170708142134/http://www.openspf.org/svn/project/specs/drafts/draft-mengwong-sender-rewrite-01.txt

I couldn't find this proposal in IETF. I had to use waybackmachine to view
it.

This proposal recommends the deprecation of the 64 character maximum
   for localparts defined in RFC2821 section 5.


So this SRS proposal had the same 64 character limitation problem 15 years
back.

===============

Personal implementation note: I never believed in solutions that
modified or altered the SMTP REQUIRED persistency of the Return Path.
  I never supported  SRS which addresses the SPF Multi-hop MTA IP
transition problem.  VERP has a good reason to exist because it deals
with bulk mail and the common bulk distribution need to recognized
specific bounce transactions, i.e. a subscriber does not exist.  I
don't feel the same with SRS and never used it, and never needed it
since 2003.


On the contrary, I support SRS.  SRS solves two problems for the
intermediaries.

1) Surviving SPF failures
2) Bounce handling just like VERP

We need solutions for intermediaries too.
We have ARC <https://tools.ietf.org/html/rfc8617> an experimental RFC that
helps intermediaries. But it's for RFC 5322.
As far as I know, the closest solution similar to ARC we have for RFC 5321
is SRS.

e.g. SRS1=HHH=example.com==HHH=TT=example.org=alice(_at_)example(_dot_)net

===============

Finally, as a proposed solution, I wonder how compliant EAML clients
will adjust to varying mail servers with different EAML values.  For
example,  given different servers limits that a client can potentially
see:
server-A  has EAML 512
server-B  has EAML
If the client is sending an address with 325 characters, server-A will
accept the input, but server-B will reject it.


I hope you are talking about the multiple hops here, where hop A accepts
512 characters but hop B accepts only 254 characters.
This is a problem with SMTP extension model. They even clarified this part
in section 2.2.3 of RFC 5321.

2.2.3.  Special Issues with Extensions

   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).

===============

So where is the exact limit?
Putting VERP and SRS aside and just considering SMTP, can it be clarified?


If you need an exact limit, I would always go with 900 since that's the
value of Gmail. They probably came to that number from their experience.

===============

There is a technical conflict just with "user@domain" address size
possibly exceeding the path 256 limit.   So we probably want to make
sure we cover the Extension Independent issue to clarify the actual
INPUT limits.


Ok

===============

Having a EAML keyword extension is good, just like we have a SIZE
extension, but the client needs to support it.  I wonder how a
compliant EAML client can be designed so that messages can be a)
single source (one message), and b) be deliverable to different
servers with different EAML limits.  What does the client do if one
system, server-B, rejects it?  Bounce it to the author showing which
servers were successful and which one failed?


If you are referring to multiple hops, then yes bounce to the author.
Alternatively, we can add words like "intermediaries MUST always use value
254"

===============

To me, the VERP specification should be updated. In fact, from what I
can see, there is no RFC for it.  It is an expired individual DRAFT
1999 submission.
I think we would be better off updating VERP making an an official
RFC, probably as Standards Track item.


Even if we update VERP specification, it still needs to address the
local-part 64 character limitation issue in order to work properly.

So either we have to update RFC 5321 at least to remove the local-part 64
character limitation OR we need to introduce a new extension like EAML. If
we go with the extension, then we always gonna have problems when multiple
hops involved since that's a problem with SMTP extension model.

Thanks


On Fri, Dec 6, 2019 at 8:01 PM Hector Santos <hsantos(_at_)isdg(_dot_)net> 
wrote:



On 12/4/2019 6:40 PM, 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.

https://tools.ietf.org/html/draft-viruthagiri-email-address-length-01

Hi, Congrats! :)

A quick review.

- Abstract

The Abstract is good. Please consider adding a summary clause,
sentence indicating first a) the "problem" and b) how this proposed
extension can resolve it.   For example, the document indicate VERP
and SRS support can be a problematic.   This problem statement should
be in the abstract. It will help catch people who may have a known
issue with the extended protocols and this proposal may offer a
possible solution.  I normally don't read submissions unless the
abstract catches my interest.

- Background

Good, but this is about VERP and SRS. You explained how VERP/SRS
violated SMTP limits.  So is it really not an SMTP problem?

Have you explored other proposed solutions to the VERP or SRS problem?
   Is there a better solution for what VERP/SRS is trying to address?

Personal implementation note: I never believed in solutions that
modified or altered the SMTP REQUIRED persistency of the Return Path.
  I never supported  SRS which addresses the SPF Multi-hop MTA IP
transition problem.  VERP has a good reason to exist because it deals
with bulk mail and the common bulk distribution need to recognized
specific bounce transactions, i.e. a subscriber does not exist.  I
don't feel the same with SRS and never used it, and never needed it
since 2003.

Finally, as a proposed solution, I wonder how compliant EAML clients
will adjust to varying mail servers with different EAML values.  For
example,  given different servers limits that a client can potentially
see:

server-A  has EAML 512
server-B  has EAML

If the client is sending an address with 325 characters, server-A will
accept the input, but server-B will reject it.

I am not sure if this level of strictness at the TRANSPORT level is
desirable.  We don't even know how the interface points will handle
it.  The key goal is targeting the message for delivery, and the
secondary goal, and equally important, is to make sure a bounce is
possible.

So where is the exact limit?

Putting VERP and SRS aside and just considering SMTP, can it be clarified?

Going back to the documented limits, the RFC821 limit was 129:

user 64
domain 64
path 256

The path limit supported the actual limit of 129 - length(user+"@"+
domain)

RFC2821/5321 updates it to 320:

user 64
domain 255

There is a technical conflict just with "user@domain" address size
possibly exceeding the path 256 limit.   So we probably want to make
sure we cover the Extension Independent issue to clarify the actual
INPUT limits.

When you backtrack, mail storage is created with 998 text line limits.
So a mail sender has to start with the extraction the Network
Transport address fields.

If it sees sizes that potentially exceeds SMTP limits, then it needs
to probably work out a mapping solution.  VERP is not it if still
exceeds the SMTP limit.

Finally, I agree SMTP documentation should be updated for
clarification regarding limits, its not just addresses, but also
Message Sizes in an era of multi-media.

Imo, this is more of a VERP problem or SPF problem when SRS is
considered with SPF.  I don't see this as an SMTP issue.

Having a EAML keyword extension is good, just like we have a SIZE
extension, but the client needs to support it.  I wonder how a
compliant EAML client can be designed so that messages can be a)
single source (one message), and b) be deliverable to different
servers with different EAML limits.  What does the client do if one
system, server-B, rejects it?  Bounce it to the author showing which
servers were successful and which one failed?

To me, the VERP specification should be updated. In fact, from what I
can see, there is no RFC for it.  It is an expired individual DRAFT
1999 submission.

I think we would be better off updating VERP making an an official
RFC, probably as Standards Track item.

--
HLS




-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>