in reply to Re^4: Email System Scalabilty
in thread Email System Scalabilty

If you have no control of the senders, I expect using a catch all email address will not work.

How will the "psuedo-email address" be manifest in the messages your system receives?

In addition to thinking about what your server will do, you also need to think about your outgoing messages and how other systems will deal with them. For example, what "From" address will recipients see? and What address will replies be sent to?

Replies are listed 'Best First'.
Re^6: Email System Scalabilty
by Anonymous Monk on Apr 20, 2009 at 20:00 UTC

    Look at it this way. Let's say we have a user named abc whom wants to send mail from his/her server at example.com to the email address he was given by his/her friend xyz whom resides on geomail.us.com.

    example.com initates the conversation with geomail.us.com and informs it that it has a message for it

    abc@example.com ---> xyz@geomail.us.com

    Now, geomail.us.com being a good little email server, checks to see if it has a user by that name. after alot of internal checking it realizes that there is no user by that name. Normally this email would bounce, right? In most cases yes. In this rare instance, geomail.us.com has a catch all email address defined, in this case 'incoming@geomail.us.com' So the server redirects the email to that account.

    xyz@geomail.us.com ---> incoming@geomail.us.com

    All's well and good, abc@example.com believes that the message has been delivered. So, far as it knows the mail has been recieved by xyz@geomail.us.com. The catch all has caught this email and redirected it to incoming@geomail.com

    Now comes the fun part? How do we get the mail caught by incoming@geomail.us.com to the actual recipient? Simple answer? We cheat.

    We introduce a cgi script called 'mail-fetch.cgi' into teh mix. This scripts sole purpose is to log onto pop server and collect all the messages caught by incoming@geomail.us.com

    During it's run, the script defines a hash key for each unique address in the list of recieved mail and sorts the individual emails into into their appropriate "mail boxes". It then checks those addresses against a database of "users" and pushes the appropriate emails to the appropriate users. If a user does not have an entry defined in the database, we generate a suitable error in that users name and push teh email back to the originating server.

    xyz@geomail.us.com ---> db ----> xyz
    pdq@geomail.us.com ---> db ----> no mbox ----> bounce

    Am I making sense now?

      Much clearer. It may work, but even if it does it may be problematic. I would be inclined to investigate alternate platforms that were free of the mailbox constraint before pursuing a common incoming mailbox much further.

      Some issues you might think about:

      Will the original envelope recipient be recorded in the catch all mailbox and available to mail-fetch.cgi?

      For example, sendmail can record the envelope recipient in the Received header, but not all MTAs record this information. For various reasons (e.g. BCC, mailing list expansion, etc.) the envelope recipient may not be recorded in the body headers.

      If you don't have access to the envelope recipient address, how will you determine which of your users should be able to see a message? I am doubtful that there is a general, secure and correct solution to this problem.

      What happens if an incoming email is addressed to several of your users? Will it be replicated into your catch all mailbox - once for each user? If not, what happens when one of the recipients deletes the message? How will your server know when all recipients have deleted the message?

      Consolidating messages to multiple users into a single mailbox will exacerbate the impact of capacity and performance limitations of the mailbox format.

      You may have concurrency issues accessing and updating the single mailbox, depending on its form. If it is a common mailbox file with on the order of 1000 busy users, this will almost certainly become an issue.