"Bill McInnis" reported:
I sent this to the ASRG list as well so I apologize if you got it twice.
Last weekend a phishing attack took place against US Bank. The phisher
spoofed and connected with the appropriate IP for US Bank,
18.104.22.168. How would SPF or Sender ID have managed to catch that
I believe that sending a single spoofed packet (containing all the data the MUA
needs to send to complete the SMTP dialog) is relatively easy, but conducting an
extended TCP session from a spoofed host address requires the hacking of
in-network routing (which would imply a seriously-escalated threat).
Was the MTA which received the message designed to _ensure_ that a valid TCP
session was in place?
A good test of session validity is to ensure that response packets are getting
back to the source. When using SMTP I believe a common technique used is for
the receiving MTA to flush the input buffer before sending each SMTP response,
so that the protocol is used to impose 'flow control', which, _requires_ there
to be a valid, multi-packet TCP session.
I would be very cautious about suggesting that SPF is ineffective unless I had
established that the MTA involved was not vulnerable to this basic kind of
deception at the transport level.