[Top] [All Lists]

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

2019-12-06 08:31:36

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.

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.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>