ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Proposal: SMTP Early Pipelining

2018-09-03 10:20:15
On 09/02/2018 04:38 PM, Ned Freed wrote:
FWIW, the IP address is the wrong key to use, since IP address can and do
change and/or get reassigned willy-nilly in some environments. The server 
host
name would be a better choice.

The name, on its own, has its own potential for problems in complex
environments.  Even a DNS-roundrobin to a mismatched set of servers.
On the plus side, a client might see fewer names than IPs.

Operators don't have to advertise the extension in such environments.
We could add guidance for cases where it won't work well.


But the problem here is that there's no means of invalidating the cache in 
the
event of a server capability change. This can lead to clients failing to use
extensions that are available, including security-related extensions, or
attempting to use extensions that are available. There are also extensions 
like
SIZE who values cannot be usefully cached.

This was the issue prompting the invalidate-cache-on-SMTP-error
requirement.

That's nowhere near sufficient, as it fails to address the issue of
extensions not being used when the need to be.

I don't think that capability upgrades at a server are a big issue.

I strongly disgagree.

So long as the client does a time-based invalidate it will eventually
pick up the change, and in the meantime it is no worse off than an
unaware (of the new extension) client.

Sure, no harm in not using STARTTLS when it becomes available. Or other
security-related extensions, at least one of which (REQUIRETLS) is about to
exit the standards process.

No harm at all.

What this implies is that in order to be sure that things are OK, when the
synchronization point is reached prior to finalizing the transaction (and 
such
a point has to be included) the client must check and make sure the EHLO
response it got and the response it had cached are, modulo things like the
argument to the SIZE extension, the same in regards to the extensions the
client supports. If they aren't the client must then check and make sure 
none
of the changes mattered, and if they did, RSET and restart the transaction.
(The client also has the choice of playing it safe and restarting
unconditionally when the responses don't match.)

[Similar suggestion from John Klensin]

The downside is that we have to do the EHLO response parsing, previously
avoidable, but that is not a big point.  Overall I'm happy to add
this in as a MUST.

We might ask how often downgrades are expected.  I'd think "hardly
ever", outside the pathological environments considered above.

Downgrades are not the major issue here.

I'm afraid this part is a complete nonstarter. Spam engines do this 
routinely
and thus it's regularly used as a means of spam detection.

I fully agree that you don't want to advertise this globally.
Probably you already don't advertise PIPELINING globally for the
same reasons.  You may still make it available selectively.

Do you really trust people to get this right?

                                Ned

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