I think option 1 (in combination with Mark's commants) is the best for your current scenario if you ask me.
And about the discusion you try to start :-).
SMTP is not something you can use to be sure something is delivered. The only sure thing you can give is that the message is delivred to the next hop point. This can be filtered out of the server logs.
And then there is something like Return Receipts but again this is triggered from the remote side (user / e-mail client) so again this is not something you can use to prove that a user has goten the email. If you get the Return receipt back it is a proof that your client/customer has received the email and read it. But again the client/customers who do not insist of sendeing back the Return Reciepts its no prove for them if they got the mail or read it or not.
To have functionality like that SMTP is not the right choice.
Hi Jake,
I think option 1 (in combination with Mark's commants) is the best for your current scenario if you ask me.
And about the discusion you try to start :-).
SMTP is not something you can use to be sure something is delivered. The only sure thing you can give is that the message is delivred to the next hop point. This can be filtered out of the server logs.
And then there is something like Return Receipts but again this is triggered from the remote side (user / e-mail client) so again this is not something you can use to prove that a user has goten the email. If you get the Return receipt back it is a proof that your client/customer has received the email and read it. But again the client/customers who do not insist of sendeing back the Return Reciepts its no prove for them if they got the mail or read it or not.
To have functionality like that SMTP is not the right choice.