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.
