D
David W. Hodgins
It does prevent the spam zombies from working. In order to
send via the ISPs smtp server, the sender must login with
their userid/password.
Regards, Dave Hodgins
It does prevent the spam zombies from working. In order to
send via the ISPs smtp server, the sender must login with
their userid/password.
Regards, Dave Hodgins
V
Virus Guy
David W. Hodgins said:
Well, not in my case.
In my e-mail settings (Netscape communicator 4.79) I have my outgoing
e-mail server set to my ISP's cannonical name (smtp1.sympatico.ca).
In the "outgoing server user name" I have some garbage text. There is
no password field for the out-going e-mail settings.
Basically, once you've "logged into" the ISP's network (PPPoe, done by
your computer or better - your router), then user names and passwords
don't matter when it comes to sending e-mail through the ISP's SMTP
server. I guess that could be up to the ISP to decide to look for
valid user-names (but like I said above I don't see a password setting
in my version of Communicator for out-going settings).
There is an additional setting (Use Secure Socket Layer (SSL) or TLS
for outgoing messages) which can be set to "Never, If Possible, or
Always" (mine is set to never).
As far as I can tell, an ISP can do 1 of 4 things when port-25 data
packets are passing through it's network:
a) if an e-mail is being sent by a user and the user's software's
outgoing SMTP setting is set to the ISP's SMTP server, then all is
well and this is a normal (and preferred by the ISP) way to do things.
b) if the target or destination is outside it's network, then the ISP
can drop the packet (ie prevent them from leaving it's network and
getting to the internet at large).
c) if the target or destination is outside it's network, then it can
allow the packet to go to it's destination unmolested (this is how
most spam is sent).
d) if the target or destination is outside it's network, then the ISP
can have it's own SMTP server intercept the packet and essentially
re-package the e-mail and then the SMTP server does the "sending" of
the e-mail to the destination. This is transparent to the user who
sent the e-mail, and requires no behavior on the user's part to make
sure their e-mail client software is configured properly to point to
the ISP's SMTP server.
I don't know if item (d) is even possible, or is being done by any
ISP's. But if it is, then I don't see how the ISP's equipment would
be able to distinguish customers trying to send e-mail via an
alternate SMTP server (outside the ISP's network) vs spam that is also
being sent directly outside the ISP's network.
It makes no sense for an ISP to intercept spam being sent from within
it's own customer network and re-send it though it's own SMTP server,
especially since doing so would pretty quickly get that server into
the various black-lists. Unless the ISP's SMTP server is also
analyzing the e-mail, looking for spoofed header information and using
rules to identify spam in the body of the messages, and is pretty
confident that it can detect spam and throw it away.
L
Lew/+Silat
In
Sorry but the facts dont support your assertions. The costs of mal insurance
are not because of law suits. And the taking away our right to sue will not
lower the rates.. It hasnt...
Art said:
Sorry but the facts dont support your assertions. The costs of mal insurance
are not because of law suits. And the taking away our right to sue will not
lower the rates.. It hasnt...
L
Lew/+Silat
Art here is a link for you. from the Industry. Even the industry knows the
truth.
http://www.insurancejournal.com/news/national/2003/06/02/29436.htm?print=1
About who really is suing:
U.S. Businesses File Four Times More Lawsuits Than Private Citizens
truth.
http://www.insurancejournal.com/news/national/2003/06/02/29436.htm?print=1
About who really is suing:
U.S. Businesses File Four Times More Lawsuits Than Private Citizens
J
Jack
Virus said:
You mean, I take it, a user *of that ISP*. A customer, in other words.
The ISP's customers might well find this suggested behaviour annoying,
to say the least. Perhaps you meant to add that in case b), the message
is *not* sent via the ISP's smarthost, but direct to the recipient's MX
server.
That is how most *email* is sent - unless I'm right in assuming that
cases b) and c) both involve sending direct-to-MX.
I've not heard of such a scheme; I think it would be illegal in western
countries for an ISP to intercept outbound email traffic without telling
you about this policy.
Server-side anti-spam software can be linked in to the SMTP server to
catch outgoing spam, as well as incoming spam. A message would have to
be identified as spam using methods other than DNSBLs; Bayes, and
techniques such as searching for giveaways (too many caps in one line,
too many exclamation marks, FREE, and a bunch of other clues that
generally get extracted from the message-body).
The filtration of outbound spam is effectively done *by* the ISPs SMTP
server.
Read up on SpamAssassin. It's a mailserver plug-in that can be
configured to do exactly that.
V
Virus Guy
Jack said:
Yes.
For example, if my ISP is called "Acme Internet", and if Acme operates
an SMTP server with the name "SMTP.ACME.COM", which if I perform a
reverse DNS on it results in an IP address that belongs to, and is
part of, ACME's assigned network.
Most home users are not sophisticated enough to have e-mail accounts
on other networks. They simply sign up with a locally-available (but
usually large) ISP, recieve a modem and a CD in the mail, let the
software install itself, and are given a web-based e-mail client to
use to access their e-mail (which isin't even using pop). For people
that signed up a few years ago (before web-mail became popular) they
had their system configured to use their ISP's SMTP server (both
incoming and outgoing).
In our example, if Acme Internet has a contract for Yahoo or Hotmail
(or other third party) to provide e-mail service for their customers,
then Acme can simply allow port-25 between their customers and the
third party e-mail provider (and ONLY that provider).
When someone more sophisticated (or who had an e-mail account on
another network prior to subscribing to Acme's network) then there
seem to be plenty of examples where outbound port-25 blocking is
lifted on a subscriber-by-subscriber basis (ie if I want to keep using
my old out-bound SMTP setting then I call Acme and they somehow are
able to know which port-25 packets are mine and let them go out of
their network and onto the internet).
Just remember that it's really pointless to insist that you keep using
an old (or alternate) out-going SMTP server because it really doesn't
matter how your e-mail gets it's destination. For example, again if
my ISP is Acme Internet, but I have an e-mail account with Fubar.net,
then I can set my outbound SMTP server to SMTP.ACME.COM, but my
incoming server is set to SMTP.FUBAR.NET (and in my e-mail settings my
"reply-to" e-mail address can be anything I want, but specifically I
would have it as (e-mail address removed). When I send e-mail to someone,
it looks like it's coming from Fubar.net, and when they reply, that's
where it goes, and when I retrieve e-mail, it'll be coming from Fubar.
Which is what my explanation (above) indicates (if by smarthost you
mean SMTP server).
ISP's were initially reluctant to block port-25 packets from leaving
their networks (from other than their own SMTP servers). With
millions of cusomters, they were dreading the support nightmare of
dealing with people who indeed were using outbound SMTP settings that
were outside the ISP's network, some of those people probably had
legacy settings or were set up by friends/family and would be unable
to follow instructions to change their outbound settings to the ISP's
own server. E-mail trouble is more than enough reason for some people
to switch ISP's.
For people that still use POP mail, I'd say that most legit e-mail is
sent from the customer to the customer's ISP's SMTP server and then
from their to it's external destination.
It's the direct-to-mx spam that is blocked by preventing port-25
packets to go directly from a subscriber's computer to somewhere on
the internet. But such blocking (it seems) also prevents legit e-mail
from going from a subscriber's computer to a third-party SMTP server.
Remember that if it's legit e-mail then most likely when you send it
it's going TO your ISP's outbound SMTP server anyways (where it is at
least checked for viruses I bet).
And your incoming e-mail is also scanned by your ISP (to determine if
it's spam, or if it contains mal-ware) so again I don't think there's
anything "illegal" about a scheme where e-mail not intended to pass
through your ISP's SMTP servers are nonetheless forced to do so - and
scanned for malware and spam content at the same time.
But again it's the direct-to-mx spam (being sent by an infected
computer) that we're talking about. Such e-mail ->WILL NOT<- pass
through the (sending) ISP's SMTP server (because the mal-ware on the
sending computer includes a mini-SMTP server engine). The only way an
ISP can stop that shit from leaving their network is to block port-25
packets from ALL computers within their network EXCEPT their own SMTP
servers.
Not if it's direct-to-mx (which is how practically all spam is being
sent, and is how most spam HAS EVER been sent over the past, say, 5
years).
Unless you operate your own domain and your own SMTP server as part of
a corporate network, you will never know the volume of direct-to-mx
spam that comes from infected computers on residential ISP networks.
We wouldn't HAVE a spam problem on the internet if it wasn't for
infected PC's on residential cable and DSL networks that act like
their own little SMTP servers.
J
James Egan
My ISP (BT) has also introduced smtp authentication in the last couple
of months. Seems like a growing trend.
As a user of Eudora Light, it took a temporary switch to Eudora Pro to
get the required smtp "personality" information to be used in cases
where the smtp user and password differs from the pop3 user and
password, but it's okay to revert back to light after the personality
has been created. The information can still be used.
Jim.
A
Art
Seems part of the problem is ripoffs by insurers who don't pass
savings on to the physicians. More greed at work
Be interestingto see actual cost comparisons between the States in order to
understand better why physicians are migrating to greener
pastures. There must be a large disparity to account for the
exodus. And any discussion of percentage increases versus
tort reform doesn't mean much without knowing far more
about actual insurance costs in various States. Some States
may have large percentage increases and low actual costs
to the physician. And vice versa.
Art
http://home.epix.net/~artnpeg
V
Virus Guy
Most (if not all) of the zombie-sent spam sent during the past 5 or so
years was sent direct from the infected computer (without going
through the SMTP server of the ISP that the zombie is connected to).
Having the ISP's SMTP server ask for user name and password is useless
when the zombie does it's own "serving" of the spam directly to the
recipient's server.
It won't help them if they haven't implimented port-25 blocking first.
I *believe* I've read about a new trend (new = past 6 months, maybe
year) where the zombie will figure out what the (outgoing) SMTP server
is of the computer that it infects and will send the spam through it.
If the server does indeed look for authentication (and if the mal-ware
on the zombie doesn't know it) then the spam can't be sent.
Of course, the user name and password are generally kept in the
registry (because who want's to type that info every time they check
for new mail or send mail) so the mal-ware will simply look for that
info on the infected computer and use it.
Which, as I said above, any sufficiently sophisticated virus will be
able to locate and use if it infects your computer and want to send
spam.
My ISP apparently doesn't do any checking of user ID or password when
sending e-mail (and as I stated before, my e-mail client (Netscape
communicator 4.79) has no place where I can even enter a password in
the outgoing SMTP server configuration.
years was sent direct from the infected computer (without going
through the SMTP server of the ISP that the zombie is connected to).
Having the ISP's SMTP server ask for user name and password is useless
when the zombie does it's own "serving" of the spam directly to the
recipient's server.
It won't help them if they haven't implimented port-25 blocking first.
I *believe* I've read about a new trend (new = past 6 months, maybe
year) where the zombie will figure out what the (outgoing) SMTP server
is of the computer that it infects and will send the spam through it.
If the server does indeed look for authentication (and if the mal-ware
on the zombie doesn't know it) then the spam can't be sent.
Of course, the user name and password are generally kept in the
registry (because who want's to type that info every time they check
for new mail or send mail) so the mal-ware will simply look for that
info on the infected computer and use it.
Which, as I said above, any sufficiently sophisticated virus will be
able to locate and use if it infects your computer and want to send
spam.
My ISP apparently doesn't do any checking of user ID or password when
sending e-mail (and as I stated before, my e-mail client (Netscape
communicator 4.79) has no place where I can even enter a password in
the outgoing SMTP server configuration.
J
Jack
Virus said:
Yes, "somehow" - this is done by reference to the source IP-address of
the connection.
This is not true.
For example: I used to receive internet services from the cable-company
NTL. Now NTL provides internet services as a supplementary source of
revenue; their main business is providing TV content. Their service is
relatively inexpensive, and very cheap. They seem to have a single
mailserver for both inbound and outbound email, for the entire country.
Inevitably this server occasionally fails (and when it fails, it tends
to stay failed for quite a while - it became so slow during the SoBig
attack that although it was in fact running, no mail could get in or
out, because you couldn't connect to it).
A professional, paid-for mail-service would not have allowed this to happen.
A smarthost is an SMTP Server that will selectively relay for other SMTP
servers.
POP is a protocol for *collecting* mail from your ISP. It has nothing to
do with how outbound mail gets *submitted*.
This is a problem only if you run a mailserver (or if you prefer to
avoid your ISP's mailserver, for whatever reason).
"Most likely" is an unhelpful piece of terminology when discussing one
of the oldest protocols on the internet. Anyway, my ISP doesn't (TTBOMK)
scan outbound mail for viruses. They provide raw mail services to their
customers.
Meanwhile, *my* outbound mail goes through my own mailserver, and if I
was forced to send it from there through my ISPs servers, I would switch
providers in a heartbeat.
Nope. My incoming mail is scanned by me.
I used to use my ISP's MX as my secondary mailserver - i.e. they
forwarded everything addressed to my domain to my mailserver. But they
*didn't* scan it; the spammers used the secondary to send me spam, thus
avoiding my blocklist arrangements. I duly stopped using my ISP's MX as
a secondary.
My ISP is Demon; the older Demon users are a cranky bunch, and tend not
to trust anybody to filter either their inbound or outbound mail for
them. Demon actually introduced inbound spam-filtering (optional) about
a year ago - but only if you let them receive and store your mail for you.
Only if I am told about it. Otherwise I suspect that private
communications are being covertly intercepted and selectively blocked.
Zzzz. We were talking about the case where the ISP willy-nilly forces
port-25 traffic to go through their server.
Niet. They can use a router to forward all outbound port-25 connections
to their mailserver. NTL used to do this with port-80 connections,
forcing all web-traffic through their crappy Inktomi proxies, which kept
breaking down. You had to point your browser at an alternative proxy of
your own choosing to escape the trap.
Thanks for drawing my attention to this fact, which must have evaded me.
But see above.
(or in any other capacity)
I don't share this view. Spammers have demonstrated considerable
ingenuity and resilience in evading the systems people set up to avoid
processing and receiving spam. Direct-to-MX spam via huge networks of
zombied home-PCs has been going on for about three years, not five.
Prior to that, they were using proxies that were open for other reasons
than the presence of zombie software. And before that, they were using
open relays.
As each chennel got closed down, the spammers found new ways to
diseminate their messages in double-quick time. The possibility of the
elimination of zombie spam has probably already been accounted for by
the spammers; I would be very surprised if they hadn't re-invested some
of their considerable profits in researching alternative strategies.
J
James Egan
(actually it was David who wrote this bit)
We already established that all stuff not going through the local
mailservers was being blocked on the ISP's outbound routers. No need
to keep repeating it.
I don't doubt the spammer will have plenty of new tricks to use, but
with authenticated smtp and associated blocking in place, some of
their current ploys will fail. The war goes on.
Doesn't have to be plain text though.
Then it will need to be high up on their "to do" list for a later
release otherwise users will move on.
Jim.
J
James Egan
My ISP is BT. As a completely separate transaction I registered a
domain with easyspace.com which came with a free mailbox and also the
option of using their alternative smtp server on port 2525 in case
there were problems with the normal ISP's port 25 being blocked. Via
BT neither 25 nor 2525 would work so it appears they were inspecting
packets for smtp rather than just blocking or diverting port 25.
They have a fair amount of "previous" on saying one thing and doing
another. I don't suppose other isp's are any different.
http://news.zdnet.co.uk/internet/0,39020369,2096778,00.htm
Jim.
D
David W. Hodgins
From http://cns.esf.edu/POP_auth.htm#Netscape_
|Netscape 4.79/7.0/7.1 and various Mozilla versions.
|No settings need to be changed in the email portion of Netscape or Mozilla
|to enable authentication. Users will be prompted to enter their password
|the first time they attempt to send email each session, or each time the
|program is run (not each time email is sent).
With dialup, or dsl, you are logging on to a specific userid when you
connect, so they've apparently chosen not to use smtp authentication.
This means that any zombies or viruses can send via their smtp servers,
but not direct, if port 25 outbound is blocked.
Regards, Dave Hodgins
J
Jack
Virus said:
The simplest authentication mechanism, from the POV of an implementing
ISP, is POP-before-SMTP. You authenticate to the POP server before
sending using SMTP, and the POP server confirms your authenticity to the
SMTP server. So the credentials you would enter would be POP credentials.
J
Juergen Nieveler
Jack said:
Many ISPs do something even simpler than that: They allow all machines
inside their own IP space to relay. No need to check anything and waste
processor cycles, if it's from the ISP network relay it, otherwise
don't.
Of course the downside of this is that you can use your ISPs mailserver
only when dialing in to that ISP...
Juergen Nieveler
J
Jack
Juergen said:
Yes, I know. But that's not called "authentication".
J
James Egan
It's quite possible that the user is using a remote (not the isp's)
pop server while wanting to use the local smtp server, so the email
client needs to be able to handle the case where smtp and pop
credentials differ.
Jim.
J
Juergen Nieveler
Jack said:
Technically it is, the IP is your authentication in that case ;-)
Juergen Nieveler
D
David H. Lipman
From: "David H. Lipman" <[email protected]>
| Thanx for the info Scott.
| Do tou know if Trend Micro detects it ?
| If not, I have a liason at Trend I can submit it to.
After submitting a sample to Trend Micro....
"The file you have submitted is now being detected as PE_TENGA.A using our latest
OPR .
Pattern Version: 2.733.00
Release Type: Regular Release
Notes:
July 17, 2005, 14:11:32 (GMT -08:00)"
And a follow-up message stated...
"The file infector you have just submitted is the first of its kind. Thanks for
the submission."
It was also submitted to Sophos...
"Hi David
please accept my apologies for the delay in getting back to you. The
file that you sent to us for analysis was a virus, W32/Tenga-A,
further details of which can be found on our web site at
http://www.sophos.com/virusinfo/analyses/w32tengaa.html
and an IDE file that will allow Sophos to detect this is available on
the Databank and from
http://www.sophos.com/downloads/ide/ "
| Thanx for the info Scott.
| Do tou know if Trend Micro detects it ?
| If not, I have a liason at Trend I can submit it to.
After submitting a sample to Trend Micro....
"The file you have submitted is now being detected as PE_TENGA.A using our latest
OPR .
Pattern Version: 2.733.00
Release Type: Regular Release
Notes:
July 17, 2005, 14:11:32 (GMT -08:00)"
And a follow-up message stated...
"The file infector you have just submitted is the first of its kind. Thanks for
the submission."
It was also submitted to Sophos...
"Hi David
please accept my apologies for the delay in getting back to you. The
file that you sent to us for analysis was a virus, W32/Tenga-A,
further details of which can be found on our web site at
http://www.sophos.com/virusinfo/analyses/w32tengaa.html
and an IDE file that will allow Sophos to detect this is available on
the Databank and from
http://www.sophos.com/downloads/ide/ "
J
Jack
Juergen said:
No, "technically" it isn't.
http://en.wikipedia.org/wiki/Authentication
The IP is the "identity" of the NIC that your packets are claiming to
originate from. Simply asserting some identity doesn't amount to
authentication.
The fact that they arrived at the ISP's host on some network interface
that is (normally?) only accessible to its customers might amount to a
type of access control, but that isn't authentication either.
Sorry.