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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp