Puts the e-mail message stored in an .EML file onto waiting list for subsequent processing in bulk mode.

Parameters

tag

Any string the developer wants to assign to Tag property of SendMailJob object created by this method. The developer can leave it a null reference (Nothing in Visual Basic).

msgFilename

The filename of the .EML file containing the e-mail message to be sent.

preferXSenderXReceiver

Denotes if "X-Sender" and "X-Receiver" message headers have priority over any other method of specifying sender and recipients for this message.

senderEmail

The e-mail address of the sender. If it's a null reference (Nothing in Visual Basic), the e-mail address is taken from From property. Ignored if preferXSenderXReceiver is true and the message includes "X-Sender" header.

recipients

The list of the message recipients. If it's a null reference (Nothing in Visual Basic), the recipients list is combined from To, Cc, and Bcc lists. Ignored if preferXSenderXReceiver is true and the message includes at least one "X-Receiver" header.

Remarks

This method is useful if you want to implement some kind of background mail queue. E-mails themselves can be created using other tools or with SubmitToPickupFolder method. SubmitToPickupFolder method can create .EML files with "X-Sender" and "X-Receiver" headers so that it's possible to implement scenarios when an e-mail needs to be sent from/to addresses different from its From/To/CC/BCC.

Note   This overload is different from AddJob (it accepts MailMessage as a parameter) in the way it uses memory. The current overload (which takes just a filename of the e-mail message) does NOT internally call LoadMessage to get the message in memory from the file and put it onto the waiting queue as a job. Instead, it loads the message into memory only when the job actually gets processed. Thus, if you added 100 e-mails as MailMessage objects, all 100 will consume memory before they start to get sent. However, if you added 100 e-mails as files, the job list will contain just 100 filenames, not actual messages. The messages will be loaded and processed one-by-one and memory usage will be substantially lower. Of course, if you're using multi-threaded processing jobs, multiple messages will be processed simultaneously (and thus occupy more memory) but you'll still have significant memory usage benefit if number of threads is less than the number of messages in the queue.

The note above does not apply to mail merge over database jobs. In that case, each e-mail is generated on the fly when it gets sent (not when the mail merge job is created). E-mails generated with mail merge over database do not occupy more memory than required in order to send out a single e-mail (or several e-mails in case of multi-threading).

See Also

Smtp Class | MailBee.SmtpMail Namespace | Smtp.AddJob Overload List

---