On Sat, 2013-08-24 at 17:06 +0200, Alessandro Vesely wrote: > On Fri 23/Aug/2013 23:00:01 +0200 Lindsay Haisley wrote: > > 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
FMP is an Internet Presence Provider, not an ISP. All of FMP's customers are business customers. They want a way to handle email over their business domain names, but they have to already have an ISP account in order to take advantage of an FMP account. The ISP provides SMTP services, which they're encouraged to use. No one has any problems with this arrangement. > 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. This service is readily available for those who need it. Most, however, collect their email from a single location, or a NATted collection of boxes, and have no problem using their ISP's SMTP server. Many ISPs as well have gone over to authenticated SMTP so they're not restricting use of their SMTP servers to connected customers. The biggest problem is motels and such which restrict port 25. The real road-warriors need a service such as FMP's authenticated SMTP. > > 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. This hasn't been a problem. > >> * 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. Thanks! > > 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? yes. -- Lindsay Haisley | "UNIX is user-friendly, it just FMP Computer Services | chooses its friends." 512-259-1190 | -- Andreas Bogk http://www.fmp.com | ------------------------------------------------------------------------------ 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
