Return the message ID

[lexbar]

Message id is essential for getting track of replies.

[Nyholm]

👎 The idea is good, but that number should be the number of sent emails

[Nyholm]

I've really been thinking about this the last couple of hours. We have some ways of tackling this:
A) Add the message id information on the sendPerformed event.
B) After messages has been sent we store an array with message ids as an instance variable on the transporter class.
C) Register a webhook for the delivered event and take the message id from there.

I believe that C is the preferred way. You may also add custom data to the message to make it easier to identify in the webhook later.

Another benefit with option C does not require any changes to this lib. This makes the mailgun transport very similar to the implementation of other transports.

@tehplague do you have any other thoughts on this?

[tehplague]

A moment ago I ran a test case to check the current behaviour. It seems as if Mailgun accepted the Swiftmailer-generated Message ID and uses it as its "official" message ID in all subsequent processes. This includes, e.g. its Backend log, where no other ID, even a Mailgun-generated one, is being shown instead of the one provided by Swiftmailer.

At least for my purposes a simple $msg->getId() should suffice, but I leave this up for discussion.
See swiftmailer/swiftmailer#335 (comment)

[Nyholm]

Should this be closed because of inactivity?

[tehplague]

+1 for closing due to inactivity. I still think that $msg->getId() works well enough.