1

I came across the following thread Sending Email with return-path not functioning on how to set the From and Return-Path. I am using Mailkit, and this is what I tried:

var mailMessage = new MimeMessage();
mailMessage.From.Add(new MailboxAddress("firstname lastname", "another@email.com"));
mailMessage.Sender = new MailboxAddress("firstname lastname", "another@email.com");
mailMessage.To.Add(new MailboxAddress("firstname lastname", "receiver@gmail.com"));
mailMessage.Subject = "Hello there!";
mailMessage.Body = new TextPart("plain")
{
    Text = "test email!"
};

using (var smtpClient = new SmtpClient())
{
    smtpClient.Connect("smtp.gmail.com", 587);
    smtpClient.Authenticate("sender@gmail.com", "password");
    smtpClient.Send(mailMessage);
    smtpClient.Disconnect(true);
}

But it is not working. I am using Blazor server side. The Return-path does not change Return-Path: sender@gmail.com. Any ideas on how to set it, I am open also for other .net frameworks.

Thank you for your help

EDIT: Big thanks to @jstedfast for his engagement and taking the time to help.

What I am trying to achieve is to detect non-delivery receipts—or bounce messages. A solution for that (what I found) is to override the "Return-Path". According to the Simple Mail Transfer Protocol Page 51 RF A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. SMTP servers making final delivery MAY remove Return-path headers before adding their own.

I tried adding to the header (and inserting at position 0), all that did is added a third "Return-Path" but did not override the original 2, which caused to work as intended.

Another solution that I found, but I don't know to implement it :

  • The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent.*

Variable envelope return path (VERP) is used to enable automatic detection and removal of undeliverable e-mail addresses. It works by using a different return path (also called "envelope sender") for each recipient of a message.

Community
  • 1
  • 1

1 Answers1

2

Now that I better understand your question (due to follow-up comments made to this answer), it sounds like you are trying to replace(?) an existing Return-Path: header in a MimeMessage and then sending it again to see if the SMTP server notices the Return-Path: header and decides not to pass it along?

If so, then in order to insert a Return-Path: header to the top of the header block, you need to do this:

mailMessage.Headers.Insert (0, "Return-Path", "value");

If you want to replace an existing Return-Path: header, you can use the Replace() method, but be warned that if the Return-Path: header doesn't already exist, it will be added to the end of the header block, not the beginning of it.

Now that you know how to set (or replace) a Return-Path: header, the rest of your questions deals with page 51 of rfc2821. I'm not sure if your expectation is that MailKit's SmtpClient.Send() method should reject the message based on the existence of a Return-Path: header, but I don't think it should. I can also confirm (as the author of MailKit) that it currently does not reject such messages. That is up to the SMTP server and/or the application that makes use of MailKit to decide.

Community
  • 1
  • 1
jstedfast
  • 35,744
  • 5
  • 97
  • 110
  • but i do receive the message, according the thread i mentioned it should be possible to have a different Return-Path than the sender email. – oussama benyaala Nov 02 '20 at 06:46
  • I think I misunderstood your question. Setting the `Sender` property does not set the `Return-Path:` header and I don't understand why you expected it to. Setting the `Sender` property sets the `Sender:` header. To set the `Return-Path:` header, you need to set `mailMessage.Headers.Add ("Return-Path", "value");` – jstedfast Nov 02 '20 at 16:58
  • Sorry if my question was not clear. I did try that before, adding Return-Path to the header just adds a header at the end but doesn't change the original therefor having not the wanted effect. According to the [https://www.ietf.org/rfc/rfc2821.txt] (RFC 2821) A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. That is why I did set the Sender because that is one of the solutions i found but it did not work. – oussama benyaala Nov 03 '20 at 07:13
  • Thank you for your time. I really appreciate your help. Inserting in the header didn't solve the problem. There was different between Add and Insert, it kept the original Reutrn-Path and added a third one therefore causing it to work as Bounce. As mentioned in the article you are not supposed to add to the header because the SMTP server inserts a return-path line at the beginning of the mail data. I did some more digging some suggest to set the Envelope sender. I did find the class envelope but no idea how to use. I hope it clear what I am trying to achieve. BIG Thanks – oussama benyaala Nov 03 '20 at 20:24
  • It's not clear what you are trying to achieve and the Envelope class in MailKit is definitely not what you are looking for. The Envelope class is for IMAP, not SMTP. – jstedfast Nov 03 '20 at 20:49
  • I have edited my question for more details. Thanks again – oussama benyaala Nov 05 '20 at 07:38
  • @oussama-benyaala did you find a solution with mailkit or what you problem is? I also tried inserting Return-Path at 0 in the header, but the return path still ends up being the From email address. – GisMofx Sep 05 '21 at 03:41