ietf-smtp
[Top] [All Lists]

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

2018-09-02 09:18:23


--On Sunday, September 2, 2018 09:35 -0400 Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:

+1 for an I-D and group discussion on it with additional
considerations.

This appears to be a client-side optimization.  Adding a
server-side optimization component to this to reduce
server-side Authentication/Authorization/Verification hooks,
shims and callouts, might add worth to the consideration.  Off
hand, for example:
 
     Server advertising PIPE_CONNECT MAY include optimization
     for using server-side cached authentication,
authorization,
     verification session information estasblished by augmented
     protocols such SPF and other high overhead session-level
     filters. 

Hector,

It seems to me that nothing prevents a server from doing many of
those things now, with no extension advertisement or client
authorization needed.  Whether they would be a good idea or not
is another matter: all the server knows at initial connection
time is a client IP address and, at least within some limits,
the bad bad guys know how to spoof those if they are
sufficiently motivated and it provides almost no information if
a message is relayed through a very large provider with fairly
weak authentication of some of its web users and MUA clients.

Server-side cached PIPE_CONNECT data SHOULD have
an
     expiration time and cached data MUST only be applicable to
     subsequent connections from the same IP address and client
     session data, e.e. EHLO/HELO, MAIL FROM, RCPT TO.

I am trying to figure out how that would usefully work beyond
just remembering whether a client pipelines garbage and whether
even that would be useful as a separate operation.  

Let me illustrate by working through a mini-example.   In the
normal (non-pipelined) flow of an SMTP session, suppose a
session is opened and then the server concluded that the MAIL
command fails (e.g., the sender information fails SPF or DKIM
checks).  Does your server remember that failure from one
session to the next?  If so, what does it do with it?  Remember
that particular backward-pointing address as invalid?   Decide
to not accept anything from that domain, or connections from
that IP address again (and how does one manage the cache in that
case)?  

The issue of whether that would be a good idea aside (I
obviously have my doubts), how would it change if the EHLO and
MAIL commands were pipelines?  If RCPT were part of the
pipeline, it would obviously be discarded and an error reply
sent, but, in the non-pipelined case, the rejection would be
sent after MAIL (similarly for EHLO and MAIL), so that doesn't
even save a turnaround unless you would use the cached
information to decline the initial connection-opening request on
an IP address basis.  But doing that doesn't interact with
pipelining at all and, worse, given the ability to spoof an IP
address in a situation that does not require TCP-level
connection establishments, be an invitation to the sort of DoS
attack in which the attacker says "please shoot yourself in the
foot" and the server complies.

So, again, I would like to see an I-D that includes an analysis
of sequencing, advantages, and costs.

As with Phil's observation, it may be useful to remember that
nothing prevents a server from giving a specific client that it
an authenticate and authorize to its satisfaction special
treatment.

Perhaps it is also time for everyone to remember the admonition
that, if memory serves, was Marshall Rose's key contribution to
RFC 1425, the third full paragraph of Section 3 ("It must be
emphasized..."): any extension adds complexity and, while I
(speaking personally and not attributing this to Marshall or
anyone else) would far prefer to have extensions that are going
to be deployed comprehensibly and publicly documented, low-value
extensions add complexity to the protocol and demands on server,
and often client, implementations and are therefore usually best
avoided.

 best,
     john

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