John,
That situation is precisely why I started my comment with
"unless you abandon mail relaying". If you insist on direct
connections between the initial sender (or an MTA that will take
responsibility for the sender and which you trust to do so) and
the receiver/ delivery SMTP server, then you are quite right and
the spoofing issue depends on control of intermediate routers
(and/or much more sophisticated tricks). But, as long as
intermediate SMTP relays (not routers, but at the SMTP level)
continue to be permitted, TCP is just not the issue because
there is no end to end connection.
This (open relay) is one part that puzzled me from time to time. Correct
me if I am wrong. In the early days, the Internet is not stable and we may
have difficults sometime to deliver a message from the source MTA directly
to the destination MTA. Under this kind of circumstance, I may appreciate
open relays. However, as the Internet is getting so (reasonably) reliable.
I think some assumption should be changed. I do not know how often we
still encounter network problems when we (sender) try to deliver a message
to a receiver. I assume it is rare. And even if this happens, I do not see
it is a big problem for the original SMTA to hold the message and retry
later.
In a nutshell, I believe all open relays should be disabled or otherwise
blocked.
(I do not want to go into a fight:-), so I make it clear that we are
talking about open relay, not MTA clusters, not the cases where a company
have multiple MTAs, and one (or more) are used for external-internal
interface, while others are used internals and depending on the interface
MTA to do the relay. It can be seen that these situations can be addressed
adequately.)
-Zhenhai
The workings of most blacklists have nothing to do with this
because they depend on either most-recent-hop or on assumptions
about [dis]trusted SMTP servers at intermediate points rather
than, as this does, properties of the initiating sender system.
And, of course, if they worked better, you presumably would not
need the draft in question.
john