I have a requirement where I need to download mails from mailbox, I have below queries
Is there any option to download bulk mails using ImapClient
How many concurrent connections I can open to a mailbox using ImapClient
MailKit's ImapFolder class has some GetStreams() and GetStreamsAsync() APIs that you might find useful. Obviously, these APIs present the downloaded messages as System.IO.Stream instead of MimeMessage, but if you are bulk downloading messages, you probably don't intend to use them as MimeMessages anyway (you probably just want to dump them into files).
Each ImapClient only supports a single connection. That said, if you want multiple concurrent connections, there's nothing stopping you from instantiating multiple ImapClients and connecting them to the same IMAP server and credentials.
Related
How can one write a code in azure postgresql server which can send email.
As Azure postgresql sever is a fully managed by azure and no option is there for installing extensions apart from limited already available extensions.
You usually shouldn't send emails from the database. If the email sending becomes slow, you can get cascading locks. And if it fails, then what should you do? You can store the email to be sent in a table, then have a process written in you favorite language access the table to do the sending. Or you can set up LISTEN/NOTIFY to do the same thing. Or you could combine them, if you want the transactionality of a separate table but don't want the polling of checking on it periodically.
Another option of course is not to use hosting solutions which prevent you from doing what you want.
I've implemented email blasting system with C#.net application using System.Net.Mail.
Previously, this system was implemented with VB Script using CDO.Message.
After I deployed my new system and run it for blasting(sending emails), I got the exception(Error in processing Number of messages exceeds maximum per connection) in production SMTP Server.
I know that this error is because of the SMTP server setting, but my client argues that the previous VB script can work with this SMTP Server setting.
That's why I want to know the difference between CDO.Message and System.Net.Mail, for instance, is there control of connection sessions, etc.
Please kindly advise me. Thanks.
'CDO' is a COM implementation for sending mail whereas 'System.Net.Mail' is a managed way to send mail using SMTP (which is typically a relay to another mail server). You are likely to find limitations in sending a larger number of concurrent emails with both as a server can only handle so many. Concurrent requests - similar to a highway only being able to handle a finite number of cars at any one time.
Is it possible to check POP3 mailbox for new e-mails via Powershell? And if possible, how can this be achieved?
This link provides some information but doesn't suit me. I know about NetCmdlets but would prefer not to use commercial tools. Also I do not want to start outlook.application. In fact, my goal is to avoid starting outlook, as long as it possible (for performance reasons)
As far as I know, there is no native POP3 class in the .NET FRAMEWORK. So you can write one using sockets or you can use an exe client. You can try GetMail for Windows.
What about creating a TCP connection using TCPClient, and next, create a NetworkStream object, connected to the TCPClient object, to read data from the server?
You'll need System.Net.Sockets and System.Net.IO.
Anyway I would search for a C# answer and then try to get it to powershell.
I am writing a POP3 mail client. I want to leave the messages on the server, but I don't want to have to redownload all messages every time I reconnect.
If I download all the messages today, and reconnect tomorrow does the protocol support the ability to only download the messages from the last 24 hours or from a certain sequential ID? Or will I have to redownload all of the messages again?
I am aware of the Unique IDentification Listing feature, but according to http://www.faqs.org/rfcs/rfc1939.html it's not supported in the original specification. Do most mail servers support this feature?
Yes, my client supports IMAP too, but this question is specifically for the POP servers.
Have you considered using IMAP?
I've done it.
You'll have to reread all the headers but you can decide which messages to download.
I don't recall anything in the header that will give you a foolproof timestamp, however. I don't believe your solution is possible without keeping a record of what you have already seen.
(In my case I didn't care--I was simply looking for messages with certain identifying features in the header--those messages were downloaded, processed and killed, everything else was untouched.)
I also wonder if you're misunderstanding the protocol. Just because you download a message doesn't mean it's removed from the server. It's only removed from the server if you give an explicit command to kill the message. (And when a message contains so many attachments that the system time-outs before you properly log off and thus your kill command is discarded you'll be driven up the wall!) (It was an oversight in the design. The original logic was attach one file over 100k, or as many as possible whose total was under 100k. Another task barfed and generated thousands of files of around 100 bytes each. While it was a perfectly legit, albeit extreme, e-mail nothing was able to kill it!)
Thus if I were writing a mail client I would simply download anything I didn't already have locally. If it's supposed to remain on the server, fine, just don't give the kill command.
The way I have seen that handled in the past is on a client-by-client basis. For example, if I use Scribe to get e-mail on one machine without deleting, then move to another machine, all e-mails are downloaded again despite the fact that I've seen them before. Internally, I imagine the client has a table that stores whether or not an e-mail has been downloaded previously.
There's nothing in the protocol that I'm aware of that would allow for that.
Sort-of. You can download individual messages, but you can't store state on the remote server.
See the RETR command at http://www.faqs.org/rfcs/rfc1939.html.
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.