Mimekit / MailKit BSMTP Files - mailkit

Try to automate a process here - we have a system that generated batch SMTP files dumps them to a folder - a 3rd party .net component reads the file and then sends it along to our SMTP server. Problem is this component create and destroys a new smtp connection with every email. So painfully slow - I checked with the vendor and no plans to do it any other way ..ever.. So wanted to spin up my own simple service - the feeding application creates batch smtp files.. I try to load this via MimeKit and get an parsing error - which i get not really a normal MIME a client would use.. is there any option to get MimeKit or even MailKit to load and relay this mail?
Simplified format of the file.. all the data is muged up for clarity - I guess I could strip out the smtp command and set them in the code and just stream in the actual MIM portion - but seems there should be a simpler way
PORT 25
HELO mydomain.com
MAIL FROM: <asdlfjasdfasdfadsf#mydomain.com>
RCPT TO: <foobar#blah.com>
DATA
From: <foobar#foo.com>
To: foovar#blah.com
Subject: Test
Date: Wed, 04 Nov 2020 11:31:52 -0600
Message-ID: <2asdfadfadaf9-0#v116.mydomain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="--=036c8f0f_0fd5_48a2_85b7_b5310c3b811b"
----=036c8f0f_0fd5_48a2_85b7_b5310c3b811b
Content-Type: multipart/alternative;
boundary="--=6b227ff4_d132_4000_9af6_f92a291f8101"
----=6b227ff4_d132_4000_9af6_f92a291f8101
Content-Type: text/plain;charset="UTF-8"
Content-Transfer-Encoding: Quoted-Printable
some content here
----=6b227ff4_d132_4000_9af6_f92a291f8101
Content-Type: text/html;charset="UTF-8"
Content-Transfer-Encoding: Quoted-Printable
html content here
----=6b227ff4_d132_4000_9af6_f92a291f8101--
----=036c8f0f_0fd5_48a2_85b7_b5310c3b811b--
.
QUIT

I guess I could strip out the smtp command and set them in the code and just stream in the actual MIM portion
That's what you'll have to do. There's no other way to do it. Keep in mind that you'll also want to strip out the line that is just . and the QUIT line as well.
The file format you've got is essentially an "SMTP command script" which includes embedded MIME, but isn't MIME itself and so MimeKit/MailKit's parser cannot handle it.
There's no real need to keep the SMTP commands that you strip out because MailKit's SmtpClient doesn't allow you to send commands since it handles sending them itself.
MailKit auto-detects the addresses it needs to send from/to based on the Sender/From and To/Cc/Bcc headers, but I suppose that it might be worth parsing the MAILFROM: and RCPT TO: commands in order to get an explicit list.
Something like this:
var recipients = new List<MailboxAddress> ();
MailboxAddress sender = null;
if (line.StartsWith ("MAIL FROM:", StringComparison.OrdinalIgnoreCase)) {
var address = line.Substring ("MAIL FROM:".Length);
if (MailboxAddress.TryParse (address, out var mailbox))
sender = mailbox;
} else if (line.StartsWith ("RCPT TO:", StringComparison.OrdinalIgnoreCase)) {
var address = line.Substring ("RCPT TO:".Length);
if (MailboxAddress.TryParse (address, out var mailbox))
recipients.Add (mailbox);
}
The hardest part will be to process the batch smtp files efficiently. You could use a StreamReader to read line-by-line, processing input until you've read a DATA line (everything following that is part of the message right up until you encounter a line matching .), but the problem with that is then you'd need to continue using the StreamReader to read data and dump it into a MemoryStream or something that you could then parse using MimeMessage.Load() (PS: don't forget to rewind the stream before parsing it).
A better option if you have the skills to do it would be to implement a custom IMimeFilter and then use MimeMessage.Load() with a FilteredStream that filters the source stream through your custom filter.
For some sample filter implementations, take a look at https://github.com/jstedfast/MimeKit/tree/master/MimeKit/IO/Filters
The easiest ones to understand might be the Unix2Dos and Dos2Unix filters.
Another thing to keep in mind is that as you are filtering the "MIME" portion of the content in those batch files, you will need to unmunge lines that start with two dots (..) by removing the first dot (.).
The Pop3Stream code in MailKit has to do this process as well since POP3 munges MIME lines beginning with a . by prepending an extra ..
You can see that code here: https://github.com/jstedfast/MailKit/blob/master/MailKit/Net/Pop3/Pop3Stream.cs#L344
(Unfortunately, it is pretty complex logic because it deals with buffering as well).
Then, once you've stripped out all of the lines with SMTP commands and processed them with the above code snippet, you can send via MailKit's SmtpClient using the following logic:
using (var client = new SmtpClient ()) {
client.Connect (host, port, SecureSocketOptions.Auto);
client.Authenticate (username, password);
foreach (batchFile in batchFiles) {
using (var stream = File.OpenRead (batchFile)) {
var message = MyCustomParseMessage (stream, out MailbnoxAddress sender, out List<MailboxAddress> recipients);
client.Send (message, sender, recipients);
}
}
client.Disconnect (true);
}

Related

Multiple To and Cc headers in MIME message sent through LotusScript

I'm building a LotusScript agent looping through a set of documents then - based on a given condition - create mail messages with formatted html text. The recipients will be mostly Non-Notes users (Outlook etc) that's why I want to make sure that subject and message body are formatted correctly. At least one copy is sent to a Domino mail-in database, though.
The code basically creates a MimeEntity, sets "To", "CC" and "Subject" headers then puts a pre-configured message into the mail body and sends it off.
In regards to the body I experimented both with a simple MimeEntity formatted as "text/html" as well as with a multipart message (Content-Type = "multipart/alternative") with 2 child entities (1: "text/plain" without any formatting, 2: "text/html" i.e. html-formatted); in my final code I plan to go for the latter method.
What is really weird is that the recipients (using Outlook as well as other mail clients like Thunderbird) see 3 "To:" and 3 "Cc:" items instead of just one. Looking at the doc in the receiving Domino mail-in database there is only one instance of each item (i.e. SendTo and CopyTo).
Here's the message's source code (taken from Thunderbird) showing those 3 instances of each item:
Return-Path: <sendername#myorg.de>
Received: (removed info here)
Subject: =?UTF-8?B?RWluIGdlbcO8dGxpY2hlcyBzaW1wbGVzIFRlc3RtYWlsIGF1cyBTT1A=?=
MIME-Version: 1.0
Auto-Submitted: auto-generated
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
Message-ID: <OFBCA50979.C1582837-ONC125856E.00548385-C125856E.0054838A#MYORG.DE>
From: Lothar Mueller <sendername#myorg.de>
This the basic code creating these mails (the simple non-multipart version):
Set docMemo = db.Createdocument()
Call docMemo.Replaceitemvalue("Form", "Memo")
Set nMimeBody = docMemo.Createmimeentity()
'SendTo
Set nMimeHead = nMimeBody.Createheader("To")
Call nMimeHead.Setheaderval("user1#otherorg.de,user2#3rdorg.de")
'CopyTo
Set nMimeHead = nMimeBody.Createheader("CC")
Call nMimeHead.Setheaderval("my-mail-in-db")
'Subject
Set nMimeHead = nMimeBody.Createheader("Subject")
Call nMimeHead.Addvaltext("Subject with ä-ö-ü-ß", "UTF-8")
'html version only for simple non-multipart MIME
Call nStream.Writetext({<p style="font-weight:bold;">Some simple formatted HTML content</p>})
Call nMimeBody.Setcontentfromtext(nStream, {text/html; charset="UTF-8"}, ENC_NONE)
Call nStream.Close()
'finally send
Call docMemo.Send(False)
Now, I can work around this behavior by simply setting the recipients as plain old Notes items, like:
Call docMemo.SendTo = recipientArray
Call docMemo.CopyTo = copyArray
instead of setting those values as MIME headers. In this case there are no more multiple instances of "To" and "CC" items at the recipients' mail clients.
I know that I did this already some years ago in a different project, and back then I didn't have those problems.
Anyone having an idea what could be the cause for this? Could it be due to the Domino version in use (now it's 10.0.1 FP4, back then it was some 9.0.1 version)?
Guess I found the cause for this, at least partially:
As I mentioned in an update to my post this behavior only can be observed when the agent is running in the client as opposed to running on the server:
examining the resulting mail through Ytria's scanEZ I find that there's a difference in regards to the fields that are created:
the run-on-server version just creates the expected fields "To:" and "Cc:" which turn up as "SendTo" and "CopyTo" in the resulting Notes document
If the code is running in the client some more fields are created in the Notes document: in addition to the standard fields there are also "INetSendTo", INetCopyTo, "AltSendTo" and "AltCopyTo". I assume that those extra fields are then rendered by the router to become addition "To:" and "Cc:" header items.
Thanks again to #DaveDelay for bringing up that idea regarding the router and mail.box

Gmail API - plaintext word wrapping

When sending emails using the Gmail API, it places hard line breaks in the body at around 78 characters per line. A similar question about this can be found here.
How can I make this stop? I simply want to send plaintext emails through the API without line breaks. The current formatting looks terrible, especially on mobile clients (tested on Gmail and iOS Mail apps).
I've tried the following headers:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Am I missing anything?
EDIT: As per Mr.Rebot's suggestion, I've also tried this with no luck:
Content-Type: mixed/alternative
EDIT 2: Here's the exact format of the message I'm sending (attempted with and without the quoted-printable header:
From: Example Account <example1#example.com>
To: <example2#example.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: This is a test!
Date: Tue, 18 Oct 2016 10:46:57 -GMT-07:00
Here is a long test message that will probably cause some words to wrap in strange places.
I take this full message and Base64-encode it, then POST it to /gmail/v1/users/{my_account}/drafts/send?fields=id with the following JSON body:
{
"id": MSG_ID,
"message": {
"raw": BASE64_DATA
}
}
Are you running the content through a quoted printable encoder and sending the encoded content value along with the header or expecting the API to encode it for you?
Per wikipedia it seems like if you add soft line breaks with = less than 76 characters apart as the last character on arbitrary lines, they should get decoded out of the result restoring your original text.
UPDATE
Try sending with this content whose message has been quoted-printable encoded (base64 it):
From: Example Account <example1#example.com>
To: <example2#example.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: This is a test!
Date: Tue, 18 Oct 2016 10:46:57 -GMT-07:00
Here is a long test message that will probably cause some words to wrap in =
strange places.
I'm assuming you have a function similar to this:
1. def create_message(sender, to, cc, subject, message_body):
2. message = MIMEText(message_body, 'html')
3. message['to'] = to
4. message['from'] = sender
5. message['subject'] = subject
6. message['cc'] = cc
7. return {'raw': base64.urlsafe_b64encode(message.as_string())}
The one trick that finally worked for me, after all the attempts to modify the header values and payload dict (which is a member of the message object), was to set (line 2):
message = MIMEText(message_body, 'html') <-- add the 'html' as the second parameter of the MIMEText object constructor
The default code supplied by Google for their gmail API only tells you how to send plain text emails, but they hide how they're doing that.
ala...
message = MIMEText(message_body)
I had to look up the python class email.mime.text.MIMEText object.
That's where you'll see this definition of the constructor for the MIMEText object:
class email.mime.text.MIMEText(_text[, _subtype[, _charset]])
We want to explicitly pass it a value to the _subtype. In this case, we want to pass: 'html' as the _subtype.
Now, you won't have anymore unexpected word wrapping applied to your messages by Google, or the Python mime.text.MIMEText object
This exact issue made me crazy for a good couple of hours, and no solution I could find made any difference.
So if anyone else ends up frustrated here, I'd thought I'd just post my "solution".
Turn your text (what's going to be the body of the email) into simple HTML. I wrapped every paragraph in a simple <p>, and added line-breaks (<br>) where needed (e.g. my signature).
Then, per Andrew's answer, I attached the message body as MIMEText(message_text, _subtype="html"). The plain-text is still not correct AFAIK, but it works and I don't think there's a single actively used email-client out there that doesn't render HTML anymore.

sendmailR: Submit encoded message to local SMTP server

I need your help in order to send email message that includes text in Greek, from within R, using the function sendmail {sendmailR}.
I tried using the function iconv, like that but it didn't work
subject <- iconv("text in greek", to = "CP1253")
sendmail(from, to, subject, msg, control=list(smtpServer="blabla"))
The mail arrives immediately but the greek characters are unreadable. Any ideas?
EDIT
Another question that came up:
The second argument to accepts one recipient. What if want to send it to more than one? (I think 'll try sapply ing the sendmail function to a vector of recipients) - Ok, that worked. However, I'm not completely satisfied because each one of the recipients has no way to know who else has received the message.
Mail client won't be able to understand any encoding without Content-Type: charset=..., so you must add it:
msg<-iconv("text in greek", to = "utf8");
sendmail(from, to, subject, msg,
control=list(smtpServer="blabla"),
headers=list("Content-Type"="text/plain; charset=UTF-8; format=flowed")
);
that is for UTF8 (which I believe should be used), for CP1253:
msg<-iconv("text in greek", to = "CP1253");
sendmail(from, to, subject, msg,
control=list(smtpServer="blabla"),
headers=list("Content-Type"="text/plain; charset=CP1253; format=flowed")
);
multisend by hidden copies can also be done with header magick, still I think sapply loop is a better idea -- then the user will see that the mail was send directly to her/himself.

How do I extract the SMTP envelope and header with Perl?

What is SMTP Envelope and SMTP header and what is the relationship between those? How do I extract them with Perl?
An SMTP message contains a set of headers such as From, To, CC, Subject and a whole range of other stuff.
An SMTP Envelope is simply the name given to a small set of header prefixed to the standard SMTP message when the message is moved about by the Message Transport Agent (ie. the SMTP server). The most common envelope headers are X-Sender, X-Receiver and Received.
For example Microsofts SMTP Server will add the X-Sender and a series of X-Receiver headers to the top of a message when it drops the message into its Drop folder. There will be one X-Receiver for each post box that matches the domain the Drop folder is for.
Another example is SMTP servers add a Receive: header when it receives a message from another SMTP server. This header gives various details of the exchange. Hence most emails on the tinternet once arrived at the final destination will have a series of Receive headers indicating the SMTP server hops the message took to arrive. Usually servers remove the X-Sender, X-Receiver headers when the message is finally moved to a POP3 mailbox.
Accessing Headers
On the windows platform the only way I've found to access the envelope headers is to simply open and parse the eml file. Its a pretty simple format (name: value CR LF).
Again on the windows platform the main set of message headers and body parts can be accessed using the CDOSYS.dll COM based set of objects. How you would do this on other platforms I don't know. However the header format is quite straight forward as per the envelope headers, its accessing the body parts that would require more creative coding.
The envelope is the addressing information sent to the server during the initial conversation via the "MAIL FROM:" and "RCPT TO:" commands.
The SMTP header is the collection of header lines which are sent after the DATA command is issued.
How you find them is dependant on how/where you're getting the message from, and we'd need a lot more clues to attempt to answer that.
You can actually think of three different things here. There are the directives that were exchanged between the SMTP MTAs (during each hop the message took) ... the headers that were generated by the MUA and headers that were added (or modified) by MTAs along the route that a given message traversed.
The "envelope" refers to the information provided to the MTA (normally the most recent or final destination MTA). The sender includes a set of headers after the DATA directive in the SMTP connection (separated from the body of the message by a blank line ... but double check the RFC if that's specifically supposed to be a CR/LF pair). Note that the local MTA may add additonal headers and might even modify some headers before storing or forwarding the message.
(Normally it should only add Received-by: headers).
Some MTAs are configured to add X-Envelope-To: and/or X-Envelope-From: headers. Some of them will still filter the contents of these headers (for example to prevent leakage of blind copies). (Senario: the original MUA had a BCC: line directory that a number of people be copied on the message with their names all appearing to one another in the CC: headers; for each recipient domain (MX result) the MTA will only issue RCPT TO: for only the subset of addresses for which the host if the appropriate result (its own hub, smarthost, or any valid MX for the target) --- thus any subsets of recipients who share an MX with each other would see leakage in the X-Envelope-To: headers generated by MTAs that were sloppy about the handling of this detail).
Also not that an Envelope-From line would only contain a host/domain name as supplied by the HELO FROM: or EHLO FROM: directives in the SMTP exchange. It cannot be used as a return address, for replies for example.
For Perl email related stuff have a look at the Perl Email Project.

Using the Microsoft SMTP Server's Dropfolder

I have set up Microsoft SMTP server so it will store all incoming email in a dropfolder.
I want to process, using c#, incoming mail based on the sender, recipient, and subject line. If possible, I also want to create a plain text preview of the email.
So, there are two parts to this problem.
I'm guessing a FileSystemWatcher
would be adequate for providing
notification of incoming mail.
How to parse the headers and body text from the .eml file; is there an existing library or any good documentation on the format?
Thanks for any help.
Yes - thats true
I used this: http://www.lumisoft.ee/lswww/ENG/Products/Mail_Server/mail_index_eng.aspx?type=info
It's a Mailserver written in C# with an API you can use without using the Mailserver
EDIT: Found a code snippet:
LumiSoft.Net.Mime.Mime m = LumiSoft.Net.Mime.Mime.Parse(mailfile);
Console.WriteLine("Read message from: " + m.MainEntity.From);
Console.WriteLine("To: " + m.MainEntity.To[0]);