It is quite weird question for the first look, but in case if you work for company or organization where are very strict rules to communicate with outer world, then it is not so funny.
For example, it's very usual when bank or enterprise company doesn't allow to access to its inner resources from outside, so that neither tunnel nor VPN are possible, and the only way to push information into inner area is Email messages. But even Email messages in such companies have several restrictions - e.g. "prohibited" or "dangerous" media content.
But it looks completely doable to setup some kind of email bridge, when both sides - e.g. worker's laptop at home and his desktop computer in office - will exchange data, syncing dedicated folders by sending email messages to each other. Such bridge may deal with messages that are completely eligible according to company's policies.
I created such a bridge and published it in Github: https://github.com/domax/email-bridge
In short words how it works:
When application runs, first of all it scans your EWS inbox
for transport email, matching subject to specific pattern and, if such emails
found, extracts files from their attachments. Then it waits for new messages
and does the same for all new matched emails. All transport emails are removed
automatically.
Just after email Inbox was scanned, application scans its "outbox" folder. If
there are files which names are matched to specific regexp pattern, these files
are gathered as attachments into new email message, and this email message is
sent away with specific subject. Then application waits for new files in
"outbox" folder and does the same for all new files there.
Only files (not sub-folders) are synchronized between computers. That's by design limitation, b/c application's "inbox" and "outbox" folders purpose is to temporarily keep VCS (Git) patches or bundles that in fact is plain file list, so that any kind of file hierarchy support is business of VCS.
Related
I am working on a project. I have many databases in which email contacts are maintained. Each database is location on a different server and each of them is used by different personnels to send emails. I want to unify these contacts, keep them sync and available to all the personnel who broadcast mails.
My solution: This is a distributed solution. Maintain continuously updated XML file on each server. When a broadcast mail is composed, fetch all files, merge them etc.
My question: How can I integrate this solution with an email client. Which opensource client is suitable for this? I want the phonebook to be updated when compose button is clicked.
I am open to other suggestions. May be some opensource solution that works out of the box for me.
A client is moving from their old hosting to mine. They have a few email accounts on the old hosting and I want to move all the emails on the old hosting to mine. How can I do this? If I download them with POP can I then upload them to the new hosting?
The answer depends on the mail server that you are using. Yes, you can download all the mail messages with POP3, but the upload to your mail server will depend on the type of mail server. I am not aware of any mail servers that provide a tool to import mail messages.
Most mail servers store the email message in a file, and you can certainly drop the files in the folder where they are stored, but that does not mean that it will be visible, you will have to deal with how the mail server index those files.
I suggest looking at the specifications for your mail server.
If you access both accounts with IMAP (most hosts support this now) instead of POP, you can literally drag and drop the messages between folders/inboxes for the two email accounts.
Also, depending on the type of hosting they're moving from/to, you may be able to use a feature of your new server's control panel to do the importing...unless you're doing it manually on a vanilla VPS or dedicated. There are still options, but you'd need to confirm here how your new server is setup and what the old server looks like.
If you're only talking about a couple of accounts with a few folders each, you may just want to consider IMAP as your path of least resistance. The transfer will primarily depend on your own Internet connection, as most hosting companies have connections faster than yours.
Lastly, if both servers share a similar format for the mailbox, you might want to just rsync the email over to the new server (assuming you have root access on both servers) to the proper email directory. Depending on the email box format, you may be able to simply run a server command to "convert" the mailbox to the format your server is expecting.
When using IMAP clients to access your email, the Inbox and any other user-created folders are synchronized as a reasonable person (my grandmother) might expect - you add/change/delete content on one device and the change is synchronized to the server and to the other devices.
However, IMAP appears to treat the drafts, junk and trash folders (I'm not meaning to specify the literal names of the folders as specific mail implementations like Gmail or Outlook might name them - so by "junk" it might be the "spam" folder and "trash" might be "Deleted items" and so on, depending on the client) differently. In particular, the drafts folder appears to be client-specific (no sync) and I've seen similar oddities with the junk and trash folders.
What is it about the IMAP protocol that results in this?
It depends on the client.
It could be that the client is storing messages in those folders locally. In particular, in order to support a "Sent Mail" on the server, you would need to send the message twice: once to the SMTP server for actual delivery and then again to the IMAP server to store it in the "Sent Mail" folder. That's why many clients will save Sent Mail locally, rather than on the server.
I assume the same is true of "Deleted Items" or any of those other folders.
I suspect the designers of the IMAP protocol were trying to optimize performance on these "frequently-churned" folders by requiring clients to specifically demand "sync everything" before sync does happen. Whether the resulting irregularity is a good idea, as you imply, is rather moot. (Of course, I'm no mind-reader so I'm just guessing at the designers' motives, since I can't find an explanation of them in the official docs).
I have gradually abandonned my offline emailer and switched to an online one, but I still use it to regularly collect my received emails and archive them. Is there something that would also allow me to collect the mails originaly sent online (other than systematically cc'ing them to myself), or (even better) to 'synchronise' the sent folders of the 2 emailers?
If your online provider supports IMAP, that would be the way to go.
I'm about to add IMAP email integration to one of our web applications (ASP.NET / SQL Server). I'm already using a commercial library which exposes the most important IMAP functionality: get folder list, get message headers, get mime message etc.)
Getting email data "live" from the IMAP server works very well. But here comes the difficult task: I have to keep the email/folders caching SQL database synchronized to the IMAP server (I have to show data applying different criteria).
Our database schema essentially contains a "Folders" and an "Emails" table. The "Emails" table contains primarily header information like "FromAddress", "FromName", "IsRead", "IsAnswered", "IsForwarded", "HasAttachments" etc. (without the email content or attachments).
I have to consider two major scenarios:
Getting all messages the first time (or after a user re-organized the folders)
Getting new/recent messages
What would be a good synchronization strategy for keeping the mail server and database server up-to-date, considering that performance is a major design criterion (I can't just query/compare thousands of messages every time I connect, in order to find out if the user moved or deleted some old emails).
Thanks!
From your library's feature list:
Better UniqueId Support: We've added
even more options for requesting a
message's unique id. You can now
return the UniqueId in a message's
DataTable for return trips to the IMAP
server.
And:
Retrieve only New Messages
Search Flagged Messages
Mark/Unmark Messages as Read
It looks to me as though your library has all the support you need to keep your SQL server synchronized. You can programmatically mark messages as read, and the library supports retrieval of only new messages. That takes care of your second item.
Your strategy will depend partly on how your solution works. If I read your question correclty, your users manage their email on the IMAP server, and your SQL Server is "subscribed" to the IMAP server, from a syncronization perspective.
If this is correct, then synchronization is effectively a background task. My approach would be to synchronize using an event model on a user-by-user basis. If possible, "notify" the synchronization program when there is activity (new/deleted emails) for a user. Add a synchronization "job" to a background process that batches synch jobs together. A notification model will ensure that the synch program only works on users that need a synch.
Small new/deleted email synch jobs go to one "processor" and larger jobs like total resynch and folder reorganization go to another. Really big resynch jobs may have to be split up in order to keep overall throughput high. The "small job" and "big job" processors could be two different services, or possibly two different threads depending on performance and design considerations.