I'm 100% with Matt and even if I haven't seen IMail2006 jet the announced dictionary attack prevention sounds very good and maybe it's an excellent base to limit outgoing traffic too.
--- Gufler Markus ---------- Original Message ---------------------------------- From: Matt <[EMAIL PROTECTED]> Reply-To: [email protected] Date: Thu, 17 Nov 2005 10:02:53 -0500 >Kevin, > >While most probably won't find this to be critical at this moment, there >is a growing danger and therefore need for a mechanism to deal with >people hacking AUTH as well as limiting one's own customers from >bulk-mailing through their server. In a nutshell, IMail needs a >mechanism to limit volume of E-mail by user according to a time period. > >The need is two-fold. First, most ISP's and hosting providers around >here have experienced customers that feel that it is appropriate to send >bulk E-mail through their servers. I have seen people attempt to send >over a thousand messages at one time using functionality built into >Microsoft Office. I have also seen people drown my bandwidth by sending >huge attachments to a smaller group of people, for instance a 20 MB >attachment to 20 people results in 400 MB of bandwidth consumption over >a very short period of time, though that condition is much more rare. >It makes sense that one would be not only able to track such usage as >has been proposed, but also set up rules to proactively block such usage >by way of local users (authenticated or allowed by IP). These limits >should be configurable at a server, domain and user level just like >message size limits, with the lowest level overriding the others. > >The second part of the need related to hackers and spammers. Just in >case people haven't noted what has been going on recently, both viruses >as well as spammers have been stealing passwords and using them to send >their garbage through AUTH'ed connections. Recent Sober viruses have >been doing this, and is now also installing a password cracking program >onto infected clients in order to obtain their passwords as are stored >in E-mail clients. There has also been a rash of phishing for Yahoo >passwords through Yahoo IM and then using those accounts to send spam >through Yahoo's own servers, and linked to Geocities redirection pages. >In the past Earthlink and their properties have fallen victim to this >and exploited for spam. I could definitely see viruses morphing >techniques in the near future so that they propagate by way of AUTH'ed >connections through one's own mail server. Although it is too early to >tell whether or not this will become commonplace or even default >behavior, it is definitely happening in increasing numbers and the >behavior makes sense as the next step. The best prevention for this >would be to provide a limit for the number of messages that a single >account can send over a given period of time. > >It would also be highly recommended that such limits were placed on by >default for the same reasons why one configures their server to not be >an open relay. Having most mail servers out there operating with no >such default limits encourages them being targeted by such exploitation, >but by putting a large default value, for instance 5,000/day on all >accounts, it would greatly reduce the damage caused by a single hack, >and discourage the targeting of such systems as spammers desire much >higher volumes. We as administrators will also appreciate having that >much less spam coming in from hacked accounts on legitimate servers. > >Something related to the second point, but much more easily fixed would >be for IMail to ditch the use of default passwords. This is a huge >security risk for anyone running IMail currently. Other servers have >been exploited by targeting such default passwords, and I am amazed that >this hasn't yet happened to IMail. A password should be required to be >entered of a minimum length and administrators should be able to force >the use of letters, numbers and/or punctuation. > >I think that the first part is something that is marketable, and the >other pieces are just simply necessary for security under present >conditions. > >Thanks, > >Matt > > > > > > > > > >Kevin Gillis wrote: > >>Hi All, >> >>excellent recommendations. >> >>we're seeing several "per domain" feature requests with both of these (IM & >>Calendaring) being near the top - along with as and av. are you looking for >>per virtual domain capabilities? >> >>anyone else with feature requests, feel free to send directly to me as well >>as, of course, to the forum. we are finalizing and prioritizing items for >>upcoming releases. here are a few that several folks have mentioned, in no >>particular order: >> >>1. ability to change order that black/white list is processed (many want >>white first) >>2. ability to disable a domain (and all it's users) without deleting >>3. ability to rename host and change IP address from within IMail >>4. Attachment Manager (option to, but not mandatory, to strip off >>attachment(s) and replace with a link to the file(s) that have been scanned >>for av/as and put on location inside firewall) >>5. ListServ Management (sign-up confirmations, bounce handling, automatic >>unsubscriptions) >>6. Notifications for full mailboxes (auto email admin or secondary account >>of the mailbox that is full) >>7. Password Rules (min/max chars, special chars required or not, auto >>expiring passwords) >>8. Archiving (e.g. domains, users, lists, mailboxes) >>9. A more high-availability/redundant friendly architecture (e.g. remove >>dependency on registry) >>10. Performance reporting (e.g. graphical reports on top 10 senders, >>receivers in emails/bytes, who's sending the most attachments, who's getting >>the most spam/viruses, real time view of how are clients connecting (pop, >>imap/web), etc.). >> >>feel free to send back comments/feedback. >> >>bye for now, >> >>kg >> >> >> >> >--- >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. > --- 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.
