Reputation: 3960
I'll let users register their [email protected] ,,, they enter their members area where they can :
1- send emails ( easy to do)
2- receive emails ..
for receiving emails , I'll use a catch all email account , read the email and figure to whom it's sent (username), and then I save it on the database with userid of the username who has registerd !
Do I miss something here ... is it really this simple (if I don't have an email server) ?
EDIT : What I mean is : I'm going to make a portable script , when users register and make their accounts . Want to send their emails, I will use PHP to send emails .. that is easy .. About the receiving part : I will use a catch all email account .. and forward the message (save it on the DB under his userID) to the owner .. so , for example : if I own domain.com ,, If I got someuser@domain.com message, i save it for someuser who registered this email previously to read it later
Upvotes: 0
Views: 296
Reputation: 360752
Sounds like one hell out of a lot of work on the receiving part. What if the email consists of:
To: [email protected]
Subject: Part at Fred's!
BYOB
see you there.
just how are you going to tell which of your users knows a Fred and where also knows where Fred's place is?
If you want to set up email hosting for users, look into setting up virtual accounts, which can be done relatively easily with Postfix, MySQL, and Dovecot. It would save you the hassle of having to read all your user's emails (unless you really wanted to).
Upvotes: 0
Reputation: 27900
The step of "read the email and figure to whom it's sent" may not be as easy as you think, because the "To:" line of the message does not necessarily indicate the actual delivery address. To see why, consider the case of a message sent to a mailing list: the header will just say "To: [email protected]".
The actual address(es) to which the message is sent are conveyed in the "SMTP envelope", which is external to the message header, and is used by the SMTP server to route/deliver the message. It's difficult (well, impossible in the general case) to look at a message that's already been delivered to a catch-all mailbox and reliably determine what user should have received it.
So, that means you need to implement an SMTP server to make this work (or tie in with an existing SMTP server). The other comments about reinventing the wheel are right on the money.
Upvotes: 1
Reputation: 8788
One word: Spam.
You're missing the fact that you are entirely re-inventing the wheel. OK, so you've got a mail system written... what happens when you start getting gobs of spam? Are you going to re-invent that wheel to0? What about email attachments? What about when a user unregisters? Is your new service going to send out RFC-compliant SMTP error messages also?
Like Josh said, using an existing (proven) package is the better choice.
Upvotes: 1
Reputation: 69252
What's going to receive the emails? You basically described a SMTP server at a very high level. Why not just use an existing SMTP server that Windows/Linux already come with?
Upvotes: 1