Any IP you put in the white list will not be subject to the dictionary attack settings. Any IP that isn't in the white list will be subject to the dictionary attack settings.
By white listing your gateway server you are not exposing your self to anymore risk than you currently have -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Travis Rabe Sent: Thursday, November 17, 2005 2:24 PM To: [email protected] Subject: RE: [IMail Forum] IMail Feature Requests -> message volume limits OK, so I white list my gateway machine, Then doesn't this feature become useless and open my server up to DOS attacks? Travis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Barber Sent: Thursday, November 17, 2005 10:32 AM To: [email protected] Subject: RE: [IMail Forum] IMail Feature Requests -> message volume limits There is a IP white list for the DOS attack feature -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Travis Rabe Sent: Thursday, November 17, 2005 12:48 PM To: [email protected] Cc: [email protected] Subject: RE: [IMail Forum] IMail Feature Requests -> message volume limits Question: If I have a relay/gateway server installed and this occurs for me. Does the DOS feature stop accepting mail from my gateway? How does Imail know that the gateway server isn't the one sending the mail?? This sounds like a big problem that you may have overlooked. Travis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Gillis Sent: Thursday, November 17, 2005 9:23 AM To: Matt; [email protected] Cc: [email protected] Subject: RE: [IMail Forum] IMail Feature Requests -> message volume limits Hi Matt, Excellent feedback. The upcoming DOS feature in IMail 2006 auto blacklists a user who sends x undeliverables in y minutes (inbound traffic) - of course this is for inbound traffic. Sounds like the analog for outbound would be very helpful and could come in 2 flavors. 1. email quantity (e.g. 10 outbound emails in 60 minutes) by server, domain, user 2. bandwidth quantity (20MB in 60 minutes) by server, domain, user How does the above map back to what you had in mind? bye for now, kg -----Original Message----- From: Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 10:03 AM To: [email protected] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [IMail Forum] IMail Feature Requests -> message volume limits Matt [EMAIL PROTECTED] 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 > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
