[Top] [All Lists]

Re: draft-duan-smtp-receiver-driven-00.txt

2005-05-11 11:02:49

--On Wednesday, 11 May, 2005 10:43 -0700 David hagel
<david(_dot_)hagel(_at_)gmail(_dot_)com> wrote:

On 5/10/05, John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:

Unless you abandon mail relaying, and perhaps even if you do,
domain names and IP addresses are as easily spoofed as full
email addresses.  The spammers figured both out many years

you're mistaken. udp spoofing is easy BUT smtp uses tcp.
its almost impossible to spoof tcp sessions now.
spoofer needs to correctly guess the randomly generated
sequence/ack numbers. even if you magically do this, you gotta
control ALL intermediate routers or else smtp server's
responses will be misdirected. meaning you cannot create a
normal tcp session.
it's a common misconception that "ip spoofing"
can be used to hide your ip address while surfing the net,
chatting on-line, sending e-mail, and so forth.
this is not true unless you're on the same subnet as victim
where you can sniff their tcp seq. #'s.
if whay you say is true, all DNSBLs would stop working dude.

(The reply below was previously sent privately because Mr Hagel
and/or his MUA seem to be unable to send an individual message
that reflects the mailing lists to which it was copied.)


I am, "dude" or not, somewhat familiar with how SMTP works.
There are rumors that I actually also understand something about
TCP and about the DNS, but those rumors are less well

However, the comment I made is not dependent on TCP, merely on
the ability of a spammer who is operating an SMTP-sender to fake
the Received headers in a message prior to those representing
the SMTP-receiver over which you have presumed control and/or
trust.  There are various tricks for detecting such spoofing.
Some of them can be quite effective against spammers who are
either dumb or too lazy to be careful and intelligent about
construction of those trace fields... both of which disabilities
tend to disappear if their incentives were strong enough.

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.

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.