RE: [Declude.JunkMail] OT: another SOBERing though
Yessir.
Limiting the number of logons over an interval would be
good. So would limiting the number of messages or recipients over an
interval, as Matt correctly pointed out.
Deriving passwords by brute force attempts has always been
out there, but an automated fashion for collecting the usernames and passwords
is new. I assumed the same thing that Sandy pointed out, which is that
SOBER is going after the low-hanging fruit, and presumably reads the mail server
name and port while it's collecting the username and password. I would
also assume that SOBER turns the mail server name into a FQDN given the
predilection for ISPs to call their mail hosts "mail" or "smtp" or "pop" and
provide the DNS search suffixin the DHCP lease.
What I do find surprising is how few email packages aimed
at ISPs support the security features we've been talking about here to detect
the bad guys in house. Declude Hijack is a notable
exception.
Corporations are in the same fix, as both are left with
"roll your own" solutions based on log file analysis.
What that means in the real world is that they govern by
exception; they don't have a security team at all, or they follow up on
incidents that are reported to them by an external body, e.g. "My users aren't
getting your mail anymore because your mail server is listed in SpamCop, CBL and
SORBS".
The spammers and malware writers will continue to find ways
to use the resources of other people. Once you've got a sensibly
configured relay, secure mailer scripts on your website, users with reasonably
secure passwords, SPF records, users using SMTP AUTH, you've taken the easy
stuff away from the bad guys.
But you still have to expect that they'll abuse something
else, so you still need to put in limits where you can, and monitor your logs
for abuse.
If you're interested, check out this paper from July 2004
entitled "Stopping Spam by Extrusion Detection" from:
http://www.cl.cam.ac.uk/~rnc1/
And if you have any ideas or updated information, please
share.
Andrew 8)
p.s. Sorry for theshot yesterday Matt, but when I see
fish in a barrel, I just can't help myself.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darin
CoxSent: Thursday, November 17, 2005 5:42 AMTo:
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] OT:
another SOBERing though
Another excellent point... limiting logon
attempts.
This reminds me of a discussion a while back that
also talked about limiting POP3 connections from a single users to every x
minutes to reduce load.
Darin.
- Original Message -
From: Markus Gufler
To: Declude.JunkMail@declude.com
Sent: Thursday, November 17, 2005 2:34 AM
Subject: RE: [Declude.JunkMail] OT: another SOBERing
though
As I can understand a feature like "max. logon try's
between x minutes" on the server would not prevent such hacking attempts
because they try to hack the login on a infected client.
Question: How will this work? Are passwords still so easy
to read as 10 years ago in Win95 or will the malware listen the IP-traffic and
read out the clear-text SMTP-Auth or POP3-Password?
Next Question: Does havesomeone here some or
numerous cases where a client behind your Declude-Wall has become a infected
sender? In my case here we have thousands of connecting clients but nearly
none of them are "in house" So I can't say it's not the case, but with my
current knowledge I know only a hand full of cases where a connecting client
was infected. Most of them because they are connecting also to another
unprotected Mailbox.
Markus
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darin
CoxSent: Thursday, November 17, 2005 2:25 AMTo:
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] OT:
another SOBERing though
So the upshot of this is we need to
1. Figure out a way to enforce strong passwords
for mail users
and
2. Monitor traffic for individual user accounts
on an intra-day basis, perhaps even have a means of detecting sharp
increases in traffic from a particular account and alerting an admin to
investigate. We do review a daily report the following morning of
traffic by domain,but don't have anything in place to monitor by
account, or to alert on an intra-day basis.
Something to look into...
Darin.
- Original Message -
From: Matt
To: Declude.JunkMail@declude.com
Sent: Wednesday, November 16, 2005 6:18 PM
Subject: Re: [Declude.JunkMail] OT: another SOBERing
though
Hmm, who would have thunk?
Subject: Re: [Declude.JunkMail] SPF SuccessDate 12/24/2004
9:24 AMhttp://www.mail-archive.com/declude.junkmail@declude.com/msg22584.
RE: [Declude.JunkMail] OT: another SOBERing though
You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8)
Re: [Declude.JunkMail] OT: another SOBERing though
hijack will work, but it will be much better if it works based on the authenticated user instead of ip also we need to be able to set different limits/categories for different users declude, are listening? - Original Message - From: Markus Gufler To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 6:36 PM Subject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Thursday, November 17, 2005 6:41 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8)
RE: [Declude.JunkMail] OT: another SOBERing though
Yes we are listening David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Thursday, November 17, 2005 1:55 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT: another SOBERing though hijack will work, but it will be much better if it works based on the authenticated user instead of ip also we need to be able to set different limits/categories for different users declude, are listening? - Original Message - From: Markus Gufler mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 6:36 PM Subject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, November 17, 2005 6:41 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8) --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] OT: another SOBERing though
I was just thinking the same thing, that strictly going by file name would not be best. Well at least it would be ressource friendly. Some thoughts: Count attached file names but 1)ignore extensions like gif, jpg, pdf, ... or alternatively look only for known risky extensions like zip, exe, com... 2)ignore files that are below x and above y of file size 3)ignore messages comming from certain sources (this whitelist can be adapted after finding a false positive) As I can immagine this tool should work in the background and block messages only durring a new outbreak. (if it will work like we want) So it can/should also send a mail alert to the admin so that he immediately can keep an eye on whats going on there. Markus --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] OT: another SOBERing though
It certainly does feel like deja vu all over again! Remember back in the old days when spammers meant bad guys who bought valid AOL accounts and then threw them away after a spam run? To turn the topic to the other side, blocking incoming spam, if AUTH based spamming becomes common,RBL usage willdrop off in importance, and we'll need to emphasize content scanning, andtracking inbound mail volumes from a givenvalid account from a given valid ISP. It's nice to see that David Barker is listening, as he may see that robust MIME decoding is in Declude's future: - at the minimum to assist the filter text files in the Pro version - at the minimum to avoid the false positives and wasted CPU in scanning binary attachments for spam text - to add features common to all current antispam solutions, e.g. SURBL - to make the various layers of decoding available to external tests to make them better and avoid duplication of efforts - probably a dozen other things that aren't on the tip of my tongue Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus GuflerSent: Thursday, November 17, 2005 10:37 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Thursday, November 17, 2005 6:41 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8)
RE: [Declude.JunkMail] OT: another SOBERing though
We are all listening Barry From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Thursday, November 17, 2005 2:14 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though It certainly does feel like deja vu all over again! Remember back in the old days when spammers meant bad guys who bought valid AOL accounts and then threw them away after a spam run? To turn the topic to the other side, blocking incoming spam, if AUTH based spamming becomes common,RBL usage willdrop off in importance, and we'll need to emphasize content scanning, andtracking inbound mail volumes from a givenvalid account from a given valid ISP. It's nice to see that David Barker is listening, as he may see that robust MIME decoding is in Declude's future: - at the minimum to assist the filter text files in the Pro version - at the minimum to avoid the false positives and wasted CPU in scanning binary attachments for spam text - to add features common to all current antispam solutions, e.g. SURBL - to make the various layers of decoding available to external tests to make them better and avoid duplication of efforts - probably a dozen other things that aren't on the tip of my tongue Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus GuflerSent: Thursday, November 17, 2005 10:37 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Thursday, November 17, 2005 6:41 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8)
RE: [Declude.JunkMail] OT: another SOBERing though
Barry, There are a number of issues with Hijack that need to be addressed. If you can't find the exchange between Scott and myself a couple of years ago, I'll be happy to reconstruct it and send it on again. The major issue was the bypassing of JunkMail processing of email which was automatically released from Hold1. There were others pertaining to all data being memory resident only, thereby precluding any other utilization of the ip addresses that were identified, and having to stop Deccon as the only way to clear an address. This, of course, also set you back to losing everything in memory and having to do a manual cleanup of Hold 1 and Hold2. George -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 17, 2005 2:51 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though We are all listening Barry From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, November 17, 2005 2:14 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though It certainly does feel like deja vu all over again! Remember back in the old days when spammers meant bad guys who bought valid AOL accounts and then threw them away after a spam run? To turn the topic to the other side, blocking incoming spam, if AUTH based spamming becomes common, RBL usage will drop off in importance, and we'll need to emphasize content scanning, and tracking inbound mail volumes from a given valid account from a given valid ISP. It's nice to see that David Barker is listening, as he may see that robust MIME decoding is in Declude's future: - at the minimum to assist the filter text files in the Pro version - at the minimum to avoid the false positives and wasted CPU in scanning binary attachments for spam text - to add features common to all current antispam solutions, e.g. SURBL - to make the various layers of decoding available to external tests to make them better and avoid duplication of efforts - probably a dozen other things that aren't on the tip of my tongue Andrew 8) From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Markus Gufler Sent: Thursday, November 17, 2005 10:37 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, November 17, 2005 6:41 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8) --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] OT: another SOBERing though
George, Let's talk offline. I'll call you later. Barry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of george Sent: Thursday, November 17, 2005 3:45 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though Barry, There are a number of issues with Hijack that need to be addressed. If you can't find the exchange between Scott and myself a couple of years ago, I'll be happy to reconstruct it and send it on again. The major issue was the bypassing of JunkMail processing of email which was automatically released from Hold1. There were others pertaining to all data being memory resident only, thereby precluding any other utilization of the ip addresses that were identified, and having to stop Deccon as the only way to clear an address. This, of course, also set you back to losing everything in memory and having to do a manual cleanup of Hold 1 and Hold2. George -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 17, 2005 2:51 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though We are all listening Barry From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, November 17, 2005 2:14 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though It certainly does feel like deja vu all over again! Remember back in the old days when spammers meant bad guys who bought valid AOL accounts and then threw them away after a spam run? To turn the topic to the other side, blocking incoming spam, if AUTH based spamming becomes common, RBL usage will drop off in importance, and we'll need to emphasize content scanning, and tracking inbound mail volumes from a given valid account from a given valid ISP. It's nice to see that David Barker is listening, as he may see that robust MIME decoding is in Declude's future: - at the minimum to assist the filter text files in the Pro version - at the minimum to avoid the false positives and wasted CPU in scanning binary attachments for spam text - to add features common to all current antispam solutions, e.g. SURBL - to make the various layers of decoding available to external tests to make them better and avoid duplication of efforts - probably a dozen other things that aren't on the tip of my tongue Andrew 8) From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Markus Gufler Sent: Thursday, November 17, 2005 10:37 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, November 17, 2005 6:41 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8) --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: another SOBERing though
not sure how using port 587 will solve this cant the spammers/virus writers eventualy use this port why would that be a long term solution ? - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 7:24 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though I think one of the issues here is that Hijack was designed to solve a problem that existed due to omission on the part of IMail, but being a separate app, it might not be the most optimal method, though for now it definitely is.Most servers on the Internet have no policies in place to restrict the volume of E-mail through authenticated accounts. This is a gaping hole and it is now being exploited. The best way to effectively stop such things is to integrate that functionality into the servers themselves, and all servers need such settings defaulted to being enabled in order to protect the Internet from the garbage that hacked accounts can spew.Clearly people aren't taking this seriously enough, including the often exploited likes of HotMail/Microsoft and Yahoo. I figure that eventually everyone will begin to take this seriously, but only after things have become much worse. Keep in mind that most of us were operating as open relays up until about 2000, and most of us had no alternative. E-mail systems with their very loose or completely lacking policy enforcement in combination with being the most often attacked system on the Internet with the most financial gain should be a primary focus as far as security goes.What really gets me is that in the last couple of years, there was a huge focus on SPF, Caller-ID and Domain Keys, but very little focus on propagating port 587/AUTH-only support on mail servers, and seemingly no focus in getting E-mail clients to auto-negotiate such settings. Now we are seeing another completely predictable situation in which spammers and virus writers are automating the hacking of E-mail accounts, and there are virtually no protections in place. IMO, it's a shame that the biggest players were pushing for what I consider to be almost valueless functionality while the big names behind them were also the ones that were being exploited the most and still are. These are also the same fools that paid-off the Congress so that they 'can'-Spam.MattSerge wrote: hijack will work, but it will be much better if it works based on the authenticated user instead of ip also we need to be able to set different limits/categories for different users declude, are listening? - Original Message - From: Markus Gufler To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 6:36 PM Subject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, AndrewSent: Thursday, November 17, 2005 6:41 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing app here: http://www.nirsoft.net/utils/pspv.html Andrew 8)
RE: [Declude.JunkMail] OT: another SOBERing though
Serge, that's a misleading line of reasoning. Here's the thing: Auth on port 587 is the right best practice for ISPs (and some corporations) so that they can properly secure their MTA against misuse by 3rd parties, including worms on their client subnets. It cuts off large swaths of current flaws: the ISP won't have any open relays, won't have whitelisted client subnets, thereby allowing the ISP to firewall outbound port 25 from their personal clients. Auth on 587 also allows the client to wander all over the Internet with their laptop and still send mail with their own mailfrom name from the expected ISP's MTA. As you've surmised, this doesn't help if the bad guys have auth that they've stolen from one of your clients. However, this becomes the same case as if the bad guy is one one of your clients, and the answers are the same; the ISP needs traffic logging and alerts, e.g. the mail volume restrictions over time that were discussed earlier today. Is that clearer? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SergeSent: Thursday, November 17, 2005 3:12 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] OT: another SOBERing though not sure how using port 587 will solve this cant the spammers/virus writers eventualy use this port why would that be a long term solution ? - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 7:24 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though I think one of the issues here is that Hijack was designed to solve a problem that existed due to omission on the part of IMail, but being a separate app, it might not be the most optimal method, though for now it definitely is.Most servers on the Internet have no policies in place to restrict the volume of E-mail through authenticated accounts. This is a gaping hole and it is now being exploited. The best way to effectively stop such things is to integrate that functionality into the servers themselves, and all servers need such settings defaulted to being enabled in order to protect the Internet from the garbage that hacked accounts can spew.Clearly people aren't taking this seriously enough, including the often exploited likes of HotMail/Microsoft and Yahoo. I figure that eventually everyone will begin to take this seriously, but only after things have become much worse. Keep in mind that most of us were operating as open relays up until about 2000, and most of us had no alternative. E-mail systems with their very loose or completely lacking policy enforcement in combination with being the most often attacked system on the Internet with the most financial gain should be a primary focus as far as security goes.What really gets me is that in the last couple of years, there was a huge focus on SPF, Caller-ID and Domain Keys, but very little focus on propagating port 587/AUTH-only support on mail servers, and seemingly no focus in getting E-mail clients to auto-negotiate such settings. Now we are seeing another completely predictable situation in which spammers and virus writers are automating the hacking of E-mail accounts, and there are virtually no protections in place. IMO, it's a shame that the biggest players were pushing for what I consider to be almost valueless functionality while the big names behind them were also the ones that were being exploited the most and still are. These are also the same fools that paid-off the Congress so that they 'can'-Spam.MattSerge wrote: hijack will work, but it will be much better if it works based on the authenticated user instead of ip also we need to be able to set different limits/categories for different users declude, are listening? - Original Message - From: Markus Gufler To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 6:36 PM Subject: RE: [Declude.JunkMail] OT: another SOBERing though Wow! It's like 1995 - 2005 had never been. :-| ok, I must say I never worked with Declude Hijack. It's not simply this what we need now? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, AndrewSent: Thursday, November 17, 2005 6:41 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: another SOBERing though You can read about or get your own version of the password stealing
Re: [Declude.JunkMail] OT: another SOBERing though
Andrew I understand the need for 587 auth We are an ISP, and we have been blocking outbound port 25 for years Moving to port 587 auth only will be a major undertaking, until all mail clients become auto-negotiating It was already a long undertaking toforce all our clients to smtp auth on port 25 Anyway I was only reffering to the subject of this thread; the threats of a new type of viruses and i think we agree on this issue, port 587 is not a solution - Original Message - From: Colbeck, Andrew To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 11:31 PM Subject: RE: [Declude.JunkMail] OT: another SOBERing though Serge, that's a misleading line of reasoning. Here's the thing: Auth on port 587 is the right best practice for ISPs (and some corporations) so that they can properly secure their MTA against misuse by 3rd parties, including worms on their client subnets. It cuts off large swaths of current flaws: the ISP won't have any open relays, won't have whitelisted client subnets, thereby allowing the ISP to firewall outbound port 25 from their personal clients. Auth on 587 also allows the client to wander all over the Internet with their laptop and still send mail with their own mailfrom name from the expected ISP's MTA. As you've surmised, this doesn't help if the bad guys have auth that they've stolen from one of your clients. However, this becomes the same case as if the bad guy is one one of your clients, and the answers are the same; the ISP needs traffic logging and alerts, e.g. the mail volume restrictions over time that were discussed earlier today. Is that clearer? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SergeSent: Thursday, November 17, 2005 3:12 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] OT: another SOBERing though not sure how using port 587 will solve this cant the spammers/virus writers eventualy use this port why would that be a long term solution ? - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 7:24 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though I think one of the issues here is that Hijack was designed to solve a problem that existed due to omission on the part of IMail, but being a separate app, it might not be the most optimal method, though for now it definitely is.Most servers on the Internet have no policies in place to restrict the volume of E-mail through authenticated accounts. This is a gaping hole and it is now being exploited. The best way to effectively stop such things is to integrate that functionality into the servers themselves, and all servers need such settings defaulted to being enabled in order to protect the Internet from the garbage that hacked accounts can spew.Clearly people aren't taking this seriously enough, including the often exploited likes of HotMail/Microsoft and Yahoo. I figure that eventually everyone will begin to take this seriously, but only after things have become much worse. Keep in mind that most of us were operating as open relays up until about 2000, and most of us had no alternative. E-mail systems with their very loose or completely lacking policy enforcement in combination with being the most often attacked system on the Internet with the most financial gain should be a primary focus as far as security goes.What really gets me is that in the last couple of years, there was a huge focus on SPF, Caller-ID and Domain Keys, but very little focus on propagating port 587/AUTH-only support on mail servers, and seemingly no focus in getting E-mail clients to auto-negotiate such settings. Now we are seeing another completely predictable situation in which spammers and virus writers are automating the hacking of E-mail accounts, and there are virtually no protections in place. IMO, it's a shame that the biggest players were pushing for what I consider to be almost valueless functionality while the big names behind them were also the ones that were being exploited the most and still are. These are also the same fools that paid-off the Congress so that they 'can'-Spam.MattSerge wrote: hijack will work, but it will be much better if it works based on the authenticated user instead of ip also we need to be able to set different limits/categories for different users declude, are listening
Re: [Declude.JunkMail] OT: another SOBERing though
Serge, The references to port 587 were mainly topics from past posts and not directly what is being addressed here. It is related though by the fact that raising the bar on spammers by blocking port 25 encourages them to seek new ways to exploit their bots and progressing to AUTH hacking is the obvious next step and we are definitely seeing that now in increasing numbers, and I expect for it to become much more common over time. Before many ISP's blocked port 25, and before most spam blocking was worth a dime, spammers didn't need to worry much about going the extra step of hacking real E-mail accounts, but were only underachievers due to the necessity of the situation. It should go without saying that people that can control 1.5 million or more bots in a single network can be quite crafty, and much more crafty than they are being now if they really felt that it was necessary. Because of these things, now is the time, if not already being too late, to push hard at getting every server out there to implement some form of account hijacking protection that is on by default. Unfortunately I know of no such servers at this moment that either have such protection or have it turned on by default, though I don't doubt for a second that such protection exists for some servers. Declude's Hijack is a fine tool for an administrator wishing to protect their own server from being exploited, but it doesn't do much for the greater good, and we all face much bigger issues from spammers and virus writers that compromise others' servers. Matt Serge wrote: Andrew I understand the need for 587 auth We are an ISP, and we have been blocking outbound port 25 for years Moving to port 587 auth only will be a major undertaking, until all mail clients become auto-negotiating It was already a long undertaking toforce all our clients to smtp auth on port 25 Anyway I was only reffering to the subject of this thread; the threats of a new type of viruses and i think we agree on this issue, port 587 is not a solution - Original Message - From: Colbeck, Andrew To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 11:31 PM Subject: RE: [Declude.JunkMail] OT: another SOBERing though Serge, that's a misleading line of reasoning. Here's the thing: Auth on port 587 is the right best practice for ISPs (and some corporations) so that they can properly secure their MTA against misuse by 3rd parties, including worms on their client subnets. It cuts off large swaths of current flaws: the ISP won't have any open relays, won't have whitelisted client subnets, thereby allowing the ISP to firewall outbound port 25 from their personal clients. Auth on 587 also allows the client to wander all over the Internet with their laptop and still send mail with their own mailfrom name from the expected ISP's MTA. As you've surmised, this doesn't help if the bad guys have auth that they've stolen from one of your clients. However, this becomes the same case as if the bad guy is one one of your clients, and the answers are the same; the ISP needs traffic logging and alerts, e.g. the mail volume restrictions over time that were discussed earlier today. Is that clearer? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Serge Sent: Thursday, November 17, 2005 3:12 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT: another SOBERing though not sure how using port 587 will solve this cant the spammers/virus writers eventualy use this port why would that be a long term solution ? - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Thursday, November 17, 2005 7:24 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though I think one of the issues here is that Hijack was designed to solve a problem that existed due to omission on the part of IMail, but being a separate app, it might not be the most optimal method, though for now it definitely is. Most servers on the Internet have no policies in place to restrict the volume of E-mail through authenticated accounts. This is a gaping hole and it is now being exploited. The best way to effectively stop such things is to integrate that functionality into the servers themselves, and all servers need such settings defaulted to being enabled in order to protect the Internet from the garbage that hacked accounts can spew. Clearly people aren't taking this seriously enough, including the often exploited likes of HotMail/Microsoft and Yahoo. I figure that eventually everyone will begin to take this seriously, but only after things have become much worse. Keep
[Declude.JunkMail] OT: another SOBERing though
So, we've seen the recent SOBER variants used their own SMTP engine to propagate as well as a predefined list of usernames and passwords at ISPs to send themselves. We've also seen that keeping viruses and spam out of our mailboxes is easier when we can identify the sender as a zombie, and that it is harder when the junk is coming from a valid ISP and/or user at an ISP. http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558 Well, Kaspersky is reporting that the latest SOBER is also stealing (at least) Outlook usernames and passwords from infectees. Therefore, we can reasonably expect more junk coming from AUTH'ed senders. Andrew. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: another SOBERing though
Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF Success Date 12/24/2004 9:24 AM http://www.mail-archive.com/declude.junkmail@declude.com/msg22584.html IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned. Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented. Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc Date 6/30/2004 12:33 PM http://www.mail-archive.com/declude.junkmail@declude.com/msg19684.html What I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track. While this is certainly a bit of me patting myself on my back, it is also a reminder to all that the worst is yet to come and for the most part people are totally unprepared for this sort of thing. So what's next? Maybe Geocities spam sent through hacked Yahoo accounts??? Oh wait, that's already happening. Matt Colbeck, Andrew wrote: So, we've seen the recent SOBER variants used their own SMTP engine to propagate as well as a predefined list of usernames and passwords at ISPs to send themselves. We've also seen that keeping viruses and spam out of our mailboxes is easier when we can identify the sender as a zombie, and that it is harder when the junk is coming from a valid ISP and/or user at an ISP. http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558 Well, Kaspersky is reporting that the latest SOBER is also stealing (at least) Outlook usernames and passwords from infectees. Therefore, we can reasonably expect more junk coming from AUTH'ed senders. Andrew. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: another SOBERing though
Well Matt when I read the link I was figuring you were fessing up to how far off you were [are] on SPF - it was only until I read the end that I understood to what you were referring. :) -Nick Matt wrote: Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF Success Date 12/24/2004 9:24 AM http://www.mail-archive.com/declude.junkmail@declude.com/msg22584.html IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned. Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented. Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc Date 6/30/2004 12:33 PM http://www.mail-archive.com/declude.junkmail@declude.com/msg19684.html What I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track. While this is certainly a bit of me patting myself on my back, it is also a reminder to all that the worst is yet to come and for the most part people are totally unprepared for this sort of thing. So what's next? Maybe Geocities spam sent through hacked Yahoo accounts??? Oh wait, that's already happening. Matt Colbeck, Andrew wrote: So, we've seen the recent SOBER variants used their own SMTP engine to propagate as well as a predefined list of usernames and passwords at ISPs to send themselves. We've also seen that keeping viruses and spam out of our mailboxes is easier when we can identify the sender as a zombie, and that it is harder when the junk is coming from a valid ISP and/or user at an ISP. http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558 Well, Kaspersky is reporting that the latest SOBER is also stealing (at least) Outlook usernames and passwords from infectees. Therefore, we can reasonably expect more junk coming from AUTH'ed senders. Andrew. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] OT: another SOBERing though
Nick, I thought at first that was the shortest message Matt ever wrote... then I realized it was because he had the luxury of quoting himself! Andrew ;) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick HayerSent: Wednesday, November 16, 2005 3:31 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] OT: another SOBERing though Well Matt when I read the link I was figuring you were fessing up to how far off you were [are] on SPF - it was only until I read the end that I understood to what you were referring. :)-NickMatt wrote: Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF SuccessDate 12/24/2004 9:24 AMhttp://www.mail-archive.com/declude.junkmail@declude.com/msg22584.htmlIMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned.Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented.Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etcDate 6/30/2004 12:33 PMhttp://www.mail-archive.com/declude.junkmail@declude.com/msg19684.htmlWhat I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track.While this is certainly a bit of me patting myself on my back, it is also a reminder to all that the worst is yet to come and for the most part people are totally unprepared for this sort of thing. So what's next? Maybe Geocities spam sent through hacked Yahoo accounts??? Oh wait, that's already happening.MattColbeck, Andrew wrote: So, we've seen the recent SOBER variants used their own SMTP engine to propagate as well as a predefined list of usernames and passwords at ISPs to send themselves. We've also seen that keeping viruses and spam out of our mailboxes is easier when we can identify the sender as a zombie, and that it is harder when the junk is coming from a valid ISP and/or user at an ISP. http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558 Well, Kaspersky is reporting that the latest SOBER is also stealing (at least) Outlook usernames and passwords from infectees. Therefore, we can reasonably expect more junk coming from AUTH'ed senders. Andrew. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: another SOBERing though
too funny. I was just chuckling so much as I was leaving I had to come back and tell you so. :) -Nick Colbeck, Andrew wrote: Nick, I thought at first that was the shortest message Matt ever wrote... then I realized it was because he had the luxury of quoting himself! Andrew ;) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Wednesday, November 16, 2005 3:31 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT: another SOBERing though Well Matt when I read the link I was figuring you were fessing up to how far off you were [are] on SPF - it was only until I read the end that I understood to what you were referring. :) -Nick Matt wrote: Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF Success Date 12/24/2004 9:24 AM http://www.mail-archive.com/declude.junkmail@declude.com/msg22584.html IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned. Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented. Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc Date 6/30/2004 12:33 PM http://www.mail-archive.com/declude.junkmail@declude.com/msg19684.html What I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track. While this is certainly a bit of me patting myself on my back, it is also a reminder to all that the worst is yet to come and for the most part people are totally unprepared for this sort of thing. So what's next? Maybe Geocities spam sent through hacked Yahoo accounts??? Oh wait, that's already happening. Matt Colbeck, Andrew wrote: So, we've seen the recent SOBER variants used their own SMTP engine to propagate as well as a predefined list of usernames and passwords at ISPs to send themselves. We've also seen that keeping viruses and spam out of our mailboxes is easier when we can identify the sender as a zombie, and that it is harder when the junk is coming from a valid ISP and/or user at an ISP. http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558 Well, Kaspersky is reporting that the latest SOBER is also stealing (at least) Outlook usernames and passwords from infectees. Therefore, we can reasonably expect more junk coming from AUTH'ed senders. Andrew. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] OT: another SOBERing though
Threw me for a curve too. I was wondering if Matt was sick until I went back and reread his post. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Wednesday, November 16, 2005 3:36 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] OT: another SOBERing though Nick, I thought at first that was the shortest message Matt ever wrote... then I realized it was because he had the luxury of quoting himself! Andrew ;) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Wednesday, November 16, 2005 3:31 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT: another SOBERing though Well Matt when I read the link I was figuring you were fessing up to how far off you were [are] on SPF - it was only until I read the end that I understood to what you were referring. :) -Nick Matt wrote: Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF Success Date 12/24/2004 9:24 AM http://www.mail-archive.com/declude.junkmail@declude.com/msg22584.html IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned. Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented. Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc Date 6/30/2004 12:33 PM http://www.mail-archive.com/declude.junkmail@declude.com/msg19684.html What I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track. While this is certainly a bit of me patting myself on my back, it is also a reminder to all that the worst is yet to come and for the most part people are totally unprepared for this sort of thing. So what's next? Maybe Geocities spam sent through hacked Yahoo accounts??? Oh wait, that's already happening. Matt Colbeck, Andrew wrote: So, we've seen the recent SOBER variants used their own SMTP engine topropagate as well as a predefined list of usernames and passwords atISPs to send themselves.We've also seen that keeping viruses and spam out of our mailboxes iseasier when we can identify the sender as a zombie, and that it isharder when the junk is coming from a valid ISP and/or user at an ISP.http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558Well, Kaspersky is reporting that the latest SOBER is also stealing (atleast) Outlook usernames and passwords from infectees.Therefore, we can reasonably expect more junk coming from AUTH'edsenders.Andrew.---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype unsubscribe Declude.JunkMail. The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: another SOBERing though
Darin, I would pretty much skip over #1 except for some obvious things like not allowing the username to be the password, and having a minimum length of 4 or more characters. I think that hackers of this type can get the passwords pretty much no matter how hard they are to unencode in brute force fashion (which is what strong passwords are designed for). Companies like IMail need to also stop using default passwords because they represent a significant vulnerability. As far as #2 goes, this is definitely what needs to be done. Just like port 587 support is now becoming common among mail servers, abuse detection (volume monitoring) will also likely become common within the next two to three years. For the time being though, even services like Yahoo and Hotmail which are commonly abused, lack sufficient mechanisms to detect hacked and abused accounts. Once you limit the number of messages that a single account can sent to less than 1,000 a day, they are next to useless for a spammer due to the volume that they require. Even if you aren't worried about your AUTH being hacked there is plenty of reason for concern among ISP's since it is not that uncommon for a customer to just assume that they can bulk mail from your server. Matt Darin Cox wrote: So the upshot of this is we need to 1. Figure out a way to enforce strong passwords for mail users and 2. Monitor traffic for individual user accounts on an intra-day basis, perhaps even have a means of detecting sharp increases in traffic from a particular account and alerting an admin to investigate. We do review a daily report the following morning of traffic by domain,but don't have anything in place to monitor by account, or to alert on an intra-day basis. Something to look into... Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, November 16, 2005 6:18 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF Success Date 12/24/2004 9:24 AM http://www.mail-archive.com/declude.junkmail@declude.com/msg22584.html IMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned. Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented. Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc Date 6/30/2004 12:33 PM http://www.mail-archive.com/declude.junkmail@declude.com/msg19684.html What I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track. While this is certainly a bit of me patting myself on my back, it is also a reminder to all that the worst is yet to come and for the most part
Re: [Declude.JunkMail] OT: another SOBERing though
Yep... except I don't believe IMail comes default with a way to enforce any password requirements, though _javascript_ validation could be added pretty easily to webmail. If 1000 accounts are used to send 1000 messages each, the spammer still getsa million out, though, for that matter, if they sent 10 through 100,000 hacked accounts would we evernotice? Maybe we wouldn't even care from an outgoing perspective, justin dealing with the spam on the receiving end. But you're right, defined limits with monitoring and notifications. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, November 16, 2005 8:52 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though Darin,I would pretty much skip over #1 except for some obvious things like not allowing the username to be the password, and having a minimum length of 4 or more characters. I think that hackers of this type can get the passwords pretty much no matter how hard they are to unencode in brute force fashion (which is what strong passwords are designed for). Companies like IMail need to also stop using default passwords because they represent a significant vulnerability.As far as #2 goes, this is definitely what needs to be done. Just like port 587 support is now becoming common among mail servers, abuse detection (volume monitoring) will also likely become common within the next two to three years. For the time being though, even services like Yahoo and Hotmail which are commonly abused, lack sufficient mechanisms to detect hacked and abused accounts. Once you limit the number of messages that a single account can sent to less than 1,000 a day, they are next to useless for a spammer due to the volume that they require. Even if you aren't worried about your AUTH being hacked there is plenty of reason for concern among ISP's since it is not that uncommon for a customer to just assume that they can bulk mail from your server.MattDarin Cox wrote: So the upshot of this is we need to 1. Figure out a way to enforce strong passwords for mail users and 2. Monitor traffic for individual user accounts on an intra-day basis, perhaps even have a means of detecting sharp increases in traffic from a particular account and alerting an admin to investigate. We do review a daily report the following morning of traffic by domain,but don't have anything in place to monitor by account, or to alert on an intra-day basis. Something to look into... Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, November 16, 2005 6:18 PM Subject: Re: [Declude.JunkMail] OT: another SOBERing though Hmm, who would have thunk? Subject: Re: [Declude.JunkMail] SPF SuccessDate 12/24/2004 9:24 AMhttp://www.mail-archive.com/declude.junkmail@declude.com/msg22584.htmlIMO, the best way to stop forging is to stop zombie spammers. The way to do this is FIRST implement port 587 as AUTH-only, and then widely block port 25. This means that mail clients would exclusively use AUTH on private networks and connect to their mail server on port 587 where only AUTHed connections would be allowed. Then only servers would share non-AUTH E-mail on port 25. The only reason why blocking port 25 is not very common currently is because it is severely limiting to customers and would cause support issues for the ISP. If you first did the migration to port 587 AUTH-only connections, which would take several years to accomplish in good order, ISP's could move forward with port 25 blocking and cause many fewer issues as far as support and their clients were concerned.Basically what I am saying is that forging isn't the issue, it's spam zombies, and to go after it as a forging issue is to miss the point. The big caveat here is that spammers will turn to hacking AUTH in much larger numbers, and E-mail server software should also widely implement a 'hijack' detection mechanism in order to help stem the abuse. I have already noted much more hacking going on, first with Earthlink's properties, and now with Prodigy as well. I have little faith that these things will happen in the proper order or with the expedience necessary unfortunately, especially because of what I consider to be a distraction focused on forging coming from the likes of SPF, Microsoft and Yahoo. I feel that the big players are missing the point, and they are the ones that heavily influence E-mail client and server software which is where the changes first need to be implemented.Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etcDate 6/30/2004 12:33 PMhttp://www.mail-archive.com/declude.junkmail@declude.com/msg19684.htmlWhat I do think would work much better in the near
