john.charles.aldrich has asked for the wisdom of the Perl Monks concerning the following question:

I'm currently developing a web based email system for eventual commercial usage. I have the basic goals for the system sketched out ( features, size limits, etc ). The problem(s) I am running into is as follow:

1) I have a fixed limit of physical mbox's available as dictated by my service provider ( media|temple ) and the only apparent solution is to use a catch all email address

2) security of using a single address to recieve mail ( ie. a catch-all account and the feasibility of implementing this as a long term solution with special consideration given to the max number of users that the server can support before purchasing additional servers is required

3) the moral/ethical concerns surrounding content-filtering based on community input (ie. spam/not spam on a per user basis ) and then setting up rules where content is being filtered at a single point in the process by group consensus ( greater than 50% ) and the per user choice to filter/not filter content based on community suggestion

4) including geolocation services and automatic spam reporting back to the originating server.



Any insight that the community could provide on this would be greatly appreciated. Thanks for your time

Replies are listed 'Best First'.
Re: Email System Scalabilty
by Corion (Patriarch) on Apr 17, 2009 at 16:30 UTC
    1. Buy/host your own server or talk to your service provider as using catch-all addresses will like not work anyway. You need control over the mailboxes.
    2. I'm not sure what you're aiming at, but if you want to let different users see different mails, give them separate mailboxes.
    3. This does not work. One man's spam is another's important newsletter. I suggest you look at what MailChannel, MessageLabs, POBox and the other mail filter providers do.
    4. GeoIP by MaxMind is also available with commercial support. Reporting spam back to the server is likely futile unless you block early in the SMTP phase, and from your vague description it sounds like you want to implement your solution much later.
[reply]
Re: Email System Scalabilty
by ig (Vicar) on Apr 17, 2009 at 19:49 UTC

    It's not clear to me what "a fixed limit of physical mbox's" means. Rather than storing messages in "physical mbox's", I would be inclined to store them in a database (other than a flat-file database). Maybe doing so would avoid the constraint.

[reply]
      my host only allows me to assign 1000 email addresses for my server. This is a hard limit that I have no way around unless I upgrade to a higher level plan. I have a solution that consists of having these three things:

      1) a mysql database containing a list of my users

      2) a single catch-all email address

      3) a mail processing script that checks this address via crontab entry at a specified interval



      NONE of the users in the mysql database have a actual email address on the system. Rather what they have is a "psuedo-email address". What is essentially happening here is that all mail addressed to anyone on the system is going into one account, that being the catch-all email address ( with headers set appropriately by the sending side of the transaction ) and then the mail processing script looks at the To: header in the transaction and compares that to the mysql database of users and then routes it to the appropriate mysql database for that users messages.

      Following me now?
[reply]

        That's clearer. I take it that your service provider has an MTA that imposes the limit as it relays messages to your server, or perhaps its an honour system.

        How will you ensure the senders all set headers appropriately? Do you have control of the senders?

[reply]

Back to Seekers of Perl Wisdom