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.
--
-Eric 'shubes'
---------------------------------------------------------------------------------
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]
