SMTP Relays...

From: David V. Corbin <dvcorbin_at_optonline.net>
Date: Thu Sep 2 20:54:36 2004

>>> Patrick/VCM SysOp Wrote:::
>>>
>>> Think about it: if you were to get on <unnamed-ISP's> site
>>> right now and sign-up for a dial-up account (assuming no
>>> outbound filtering), how much email do you think you'd be
>>> able to push through that connection before they noticed
>>> and turned you off?

What is to stop someone from doing that and using the ISP's own SMTP
server?!?!?!?

>>>
>>> And if what you say about optonline.net is true, then I'll
>>> also give them an "atta boy" for doing it (but not the way
>>> they handled it). That's a very familiar domain in my
>>> world as an identified spam source. I'll probably get a
>>> benefit I can measure, at least until the bad guys find
>>> another ISP who hasn't done it yet.

If this is true, then the MAIL did NOT originate from optonline.net at
all!!!!
It originated from other servers! Yes, optonline subscribers may have been
generating the mail requests (deliberately or unknowingly).

>>> Well, if I had a dollar for every time we got blamed for
>>> another ISP's activities (or that of the client
>>> themselves), I wouldn't be writing this from my desk at
>>> work. I feel your pain, but it's part of the job.

I know, but I don't have to LIKE it....although after 25+ years on the job I
have to question why I do it if I don't like it....

>>> > I am not looking to change any opinions. I simply ask
>>> > where there is a valid technical benefit of blocking an
>>> > outboundt connection based solely on the port number.
>>> > If a specific IP is "doing bad things" on a
>>> > port, then block that port, Heck even block the whole IP!
>>>
>>> That's even less effective!
>>>

[Example Snipped]
>>>
>>> The use of dynamic addressing also means that the source
>>> can move faster than you can block it. In fact, the real,
>>> identifiable source is the destination port, not the source
>>> IP address, and hence the obvious choice.

Blocking the DESTINATION IP is what I was referring to, NOT the (yes Optimum
uses dynamic IP) IP of the source.

>>> I don't think a large ISP would choose to do this
>>> arbitrarily, and more, I don't think a large number of the
>>> largest of them would all do it if they weren't convinced
>>> that the benefit was worth the inconvenience they are
>>> creating to their customers. I lurk on NANOG and learn a
>>> lot, and it's clear to me that these guys talk and think
>>> through things extensively before they start making
>>> systemic changes like that. The business side may forget
>>> to tell you, but that's a different problem.

A good business reason does become the final answer in a commercial society.
Unfortunately my experience is that even when the "business" types come up
with a decent solution, it does not mean that they even considered other
technical solutions which *could* have been just as efficient from a
business standpoint.

A current client of mine has been asking my to develop an extremely complex
piece of software to meet a business need. They have performed TONS of
research and came up with an approach that is POSSIBLE and will be workable,
but is a real bear to develop. Just today, I had a 3 hour conversation with
the "top-guns" at the client company. During this conversation I questioned
why they rules out using a rather obscure capability of the techonology. The
general consus was that they had NEVER considered it or even known about it.
This is NOT a slam on them, rather it points out the need for analysis that
includes BOTH business and technical experts. One alone can NOT do the job.

>>> And if the inconvenience of the unauthenticated protocol
>>> being "hobbled" forces people to move the authenticated protocols, I'm
even
>>> more in favor of it, because it's where we need to be.
>>> Helping a client get a stable, secure email connection is
>>> time well spent in my opinion, for reasons that go beyond
>>> the issue of spam.

This I will completely agree with! I even take *some* of the responsibility
for
Not setting everything up with authenticated protocols. Some of the systems
have been in place for quite a while [remember when HTTPS et. al. meant SLOW
because of the low horsepower machines!]
Received on Thu Sep 02 2004 - 20:54:36 BST