On 9/2/2018 10:18 AM, John C Klensin wrote:
Hector,
It seems to me that nothing prevents a server from doing many of
those things now,
+1 and they may for the most part.
...
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)?
I see your points and I agree.
Overall, my thinking is in the area of "automated but temporary trust"
to help reduce session overhead redundancy. However, it is well noted
these optimization considerations are lessen with today's hardware and
performance -- just repeat it. Let's not fall victim to complexity
and potential timing and syncing exploits.
So, again, I would like to see an I-D that includes an analysis
of sequencing, advantages, and costs.
+1
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp