On Fri 23/Aug/2013 23:00:01 +0200 Lindsay Haisley wrote: > On Fri, 2013-08-23 at 20:00 +0200, Alessandro Vesely wrote: >>> Unfortunately, I hadn't updated MYSQL_SELECT_CLAUSE which >>> had been copied from a previous courier installation on another server >>> which didn't look at my auth flag. The result was that one of my >>> customers got her computer infected with a key-logger and her IMAP >>> credentials were used to pwn my SMTP server and send out huge quantities >>> of spam! My server got blacklisted! >> >> Do you mean you wouldn't have conceded the relay auth flag to that user >> of yours? Based on what, if you don't mind my asking? You may be able >> to estimate who is more likely to catch a key-logger, but there's no way >> to tell for sure... > > As a rule, I don't provide SMTP services to any FMP customers by > default. Since FMP is an IPP, not an ISP, I encourage users to use the > SMTP services provided by their ISPs. Clients with special needs, such > as those with field reps who do a lot of moving around, can subscribe to > SMTP service from FMP's Courier server for a small additional fee which > gives them a single central SMTP server and auth which they can use > anywhere they go.
Authenticated SMTP should be an integral part of providing a mailbox, IMHO. See also http://en.wikipedia.org/wiki/Mailbox_provider Since it is fairly common to use different ISPs according to location, hardware, and convenience in general, I'd encourage users to buy FMP's additional service rather than using the ISP of the day. > Individual user mailboxes aren't enabled for SMTP. [...] > Granted, this might make it more difficult to isolate a rogue desktop > box in an organization where the SMTP login is shared, Especially if they also share the same NAT. >> * per user limit on messages --the numeric equivalent of your flag-- >> possibly allowing users to set their limit for some limited amount of >> time. > > Should it become necessary or advisable, I like the idea of some kind of > per-user limit as a backstop. It shouldn't be difficult to program at > all. If smtp.example.com gets more than X hits in a 24 hour period to > send mail, the auth_smtp flag gets set to a value which disallows SMTP > use and sends me and the account owner an email stating what happened. Yup, I currently have: (SELECT SUM(rcpt_count)\ FROM message_out WHERE user = $(user_ref) AND\ mtime > UNIX_TIMESTAMP(NOW() - INTERVAL 1 DAY)) > 10000 So it would be enough to just change that query. I'll have to prepare a web form for managing the new field, though. > When the 24 hour period has passed, auth_smtp is turned back on. I'd have to recode for the latter, as it currently requires manual intervention. If we are talking stolen passwords, creating a new password and a couple of phone calls are also likely to be part of the recovering, no? ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
