I've sent an email with two recipients and I've received back two separate certificates. What should I do to get a single certificate when sending an email to multiple recipients?
In order to register your emails, you need to make sure that your emails are delivered to us, not to the recipients. You have two different choices to do so: you can send your emails directly to us by configuring us as your account's outgoing mail server, or you can instruct your mail server (or email provider) to forward specific emails to us by adding the .eevid.com wildcard to the recipient address.
It is important to understand how mail servers deliver emails. Say you are sending an email to john@example.com. When your mail server gets your email, it will try to resolve the destination mail server for the example.com domain name. If successful, it will deliver your email through a standard SMTP transmission.
Let's say now that you are sending an email to john@example.com, copying mary@example.com. In this case, your mail server will likely deliver both emails through a single SMTP transmission to example.com's mail server, informing that there are two separate recipients (RCP) for your email. Some mail servers will still resolve the destination mail server twice and deliver your email on two separate SMTP transmissions, but most will not.
Finally, let's say you send an email to john@example.com and mary@example.com, copying peter@example.org. In such case, your mail server will at least perform two separate SMTP connections for delivering your email to all three recipients: one connection to example.com's mail server to deliver your email to John and Mary, and a separate connection to example.org's mail server to deliver Peter's copy.
Please notice that unless you have carbon-copied any of the recipients, they will all see who did also get your email.
How does your mail server deal with the wildcard
Say you decide to register the email sent to John, Mary and Peter, by using the wildcard method. Hence, instead of using their regular email addresses, you type these as john@example.com.eevid.com, mary@example.com.eevid.com and peter@example.org.eevid.com.
On the above case, common sense may make you think that your mail server will likely deliver your email through a single SMTP connection to eevid.com's mail server, but it will not. From your mail server perspective, example.com.eevid.com and example.org.eevid.com are totally two different domain names and, accordingly, Peter's copy will be delivered to us through a separate connection from John's and Mary's.
Furthermore, eEvid will actually get two separate email registration requests: one for John's and Mary's email and a separate one for Peter's, which will generate two different eEvid.Certs.
If you are to register emails intended for several recipients from different domain names, use us as your account's outgoing email server, don't use the wildcard
Let's go back to the example.com and example.org case. This time, however, instead of adding the .eevid.com wildcard to each recipient address, let's see how the whole thing results when you configure our servers as your account's outgoing email server.
When doing so, using the wildcard is pointless. Your email is transmitted from your device's email client directly to us anyway, not through your mail server, as a single email delivered through a single SMTP transmission. No need for using the wildcard.
Once we get your email, no matter how many recipients your email is intended to, we will attempt to deliver it to each of them and finally issue a single eEvid.Cert containing the delivery result for each recipient.
Feel free to keep using the wildcard if you whish. Just bear in mind that you will probably waste your available eEvid.Certs unnecessarily.
If you use the wildcard way, make sure you apply it to all recipients
The wildcard has only one purpose: to make sure that your mail server delivers the emails to be registered to us, not to the intended recipients.
See, when we receive an email to be registered, first thing we do is check whether the .eevid.com wildcard is present on the recipients addresses. When found, we will remove it before attempting delivery.
Removing the wildcard is technically mandatory to successfully deliver your emails to the intended recipients: otherwise, if we were to keep the wildcard, our mail servers would enter an endless loop sending and delivering each email from and to themselves over and over again.
Now, say you want to register a new email sent to John. You compose the email, you attach a few files and, finally, you type in his address appending the wildcard: john@example.com.eevid.com. Right when you are about to click the Send button, you recall you wanted to have Mary on copy: you type in her address, but in the rush you forget to append the wildcard to her address. Big mistake.
Your mail server will get an email with two intended recipients: john@example.com.eevid.com and mary@example.com. Accordingly, the mail server will start an SMTP transmission with example.com.eevid.com mail server (that's us) to deliver John's copy, and a separate transmission with example.com to deliver Mary's.
Although the email header will contain reference to both recipients, you mail server will have not instructed us to deliver Mary's copy. Therefore, once we get your email we will limit our job to removing the wildcard from John's address and deliver the copy we were instructed to deal with: that's John's.
On its side, the mail server at example.com will receive Mary's copy and thus deliver it to her inbox folder. That mail server, however, knows nothing about eevid.com and wildcards and, of course, will not remove any piece of information from any other recipient's address found on the email header. And here is where the problem comes, as it will be obvious to Mary that John's address looks weird: what the heck is that .eevid.com thing at the end of John's address?
Bottom line
If you don't want to waste eEvid.Certs when emailing to two or more recipients, don't use the wildcard; instead, configure eEvidence as your SMTP outgoing mail server.
If you still want to use the wildcard when emailing to two or more recipients, make sure you append the wildcard to them all, including the ones in carbon copy.