On 10/2/2010 1:24 PM, Eric Shubert wrote:
Tonix (Antonio Nati) wrote:
Il 01/10/2010 21:04, Eric Shubert ha scritto:
Tonix (Antonio Nati) wrote:
There are too many sides to examine.
I have a pretty clear picture of what I have in mind. Perhaps I
haven't communicated it well, or am not considering something.
Can you expound a bit?
I'm speaking about different business behaviors, for which something
genial for one customer could be a damage for others.
That is indeed always a concern. By allowing the default to be the
present behavior, and by allowing different settings per domain and
per user, I believe that detrimental side effects can be avoided.
I had customers with stolen password, and my attention was caught by
messages in queue, coming from authenticated relaying, and different
IP used from same sender for those messages.
99% of my customers works from office, so they use a fixed IP, and
sometimes work from home, sometimes they travel. But it is extremely
rare they send e-mail from three different IP in the same day, so it
may worth to "suspend" an account when such condition exists.
Not in my world. ;) My customers (and myself) can be fairly mobile at
times, submitting email from several locations per day.
In addition, there are dynamic IPs to consider. While some (even most)
dynamic addresses only change occasionally (daily to monthly), I have
one customer whose DSL provider is presently changing addresses
several times per day. While that may only be 1% of the general
population, it can and does happen unpredictably.
These aspects lead me to believe that a mechanism which presumes a
consistent (or even semi-consistent) IP address would not work well in
practice.
At the same time, I feel necessary to put a "filter" at acceptance
phase (like maximum numer of messages/recipinets for day) , because
they work with e-mail, and I cannot consider throttling or delaying
their messages due to huge queues... If I receive a message I must
deliver it in the shortest timeframe, otherwise it is better not to
accept it.
I appreciate your concerns, but I believe that throttling delivery on
a per-user basis will actually improve delivery overall. A throttle
would prevent a single user from hogging the sending resources to the
detriment of other users' messages. IOW, by limiting the rate at which
each user's messages are sent, the messages which are sent would
belong to a greater number of users. For instance, if joe sends a
message to 40 people, and his allowance is one per 30 seconds, his
messages would sent over a 20 minute period. This, as opposed to the
present situation, where joe's 40 messages would be sent all at once,
causing everyone else's messages to wait for all of joe's messages to
be delivered before qmail-remote resources become available.
I'n mu wishlist about qmail, I'd love to have a multi-queue
mechanism, where one queue would be used for users within thesholds,
and another queue for mailing lists and users outside thesholds. In
this way normal users would be never have penalties, while exceeding
users would be routed to "low priority queue".
I don't think multiple queues would be required. A throttling
mechanism as I've described would accomplish the same thing. Depending
on how the administrator chooses to configure the settings, some users
can be throttled, and others not. Or per domain.
But I'd love to extend this to other needs, as well. Stolen passwords
mean unauthorized access to pop and IMAP, so I need a wider approach
to that.
True. However, at present time the strongest incentive to steal
passwords appears to be for use of smtp for spamming. What I think
we're trying to address here is reducing (or eliminating) the impact
on the server when a password is compromised. Throttling qmail-remote
will minimize that impact, and perhaps keep the host's IP address from
being blacklisted as well.
Natalio's script fills a void regarding detection. I like that. Taken
one step further, it should be fairly easy to modify the script to
show message counts per user, which would help greatly in pinpointing
the offending account. What do you think, Natalio?
Actually POP do not make any kind of control over abuses,a nd most
IMAP applications do no let to approach it easily (example, for a
webmail using IMAP, IMAP application cannot check the "real" source
IP, as it know only the webmail IP).
Right. I'm not as concerned with POP and IMAP though, as this doesn't
appear to effect the server, and the incentive for exploit doesn't
appear to be as great. The effect of a compromised password on
POP/IMAP is a consequence to the user more so than the server. Thus,
it can left to be the responsibility of the user.
Of course, that's just my opinion.
Just to expand a bit on my situation.
Further investigation showed that the compromised account belonging to
a host on our network with a public IP was compromised with a trojan on
the machine. This trojan I suppose was running a small server watching
email traffic and sniffing passwords.
Once compromised I do believe the master server where the trojan came
from executed the attack. I did not see but only one IP using the
account for this purpose. Not Say that the master(hacker) could wake
more bots to be used in the attack.
A little more control over the queue would be nice. For now I have
implemented nagios to watch the concurrency level and warn me when it
goes above a certain level.
--Dave
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
