-to option and specifying Display Name

[tgice]

I often want to include a display name with my automatic emails. When I try to do this:

-to "John Smith john.smith@example.org"

mailsend interprets this, I'm guessing, as three separate addresses, because of the spaces. I can remove the space between "Smith" and the "<", without causing much trouble, but this isn't very desirable for me.

I also see the '-name' option which allows you to set the display name, I think, on just the From address.

Is there already some method by which I can accomplish what I want here?

I tried using the list-address option to do this, but then everything is treated as BCC and only 'undisclosed-recipients' shows up. I've seen the earlier responses to similar questions about this and how list-address is working as designed.

What I'd propose is that list-address handling be modified so that it can properly handle included Display Names in the addresses (if it doesn't already -- it may), but also that it honors To and Cc prefixes in such a way that they actually show up, visibly, in the To and Cc lines, and everything is not treated as Bcc.

This would be a convenient way to all at once (in a single file) define all of my recipients with To, Cc, and BCc designation as well as Display Names (if desired).

Does this sound reasonable, or is there another way for me to pursue a similar effect?

Thanks for the excellent product, by the way, I'm coming from using Blat, which does not offer native SSL support for sending to Gmail and similar servers.

[muquit]

The To address specified with -t (which is used in SMTP RCPT TO) can not be other than john.smith@example.org. mailsend adds the < and > around the address. However, you can add a TO header with -H but it is up to the SMTP server to accept it or not. Example, -H "TO: \"John Smith\" <john.smith@example.com>"

Thanks.

[tgice]

Thanks for your quick response!

I understand what you're saying about the SMTP RCPT TO issue, and how that needs to be the bare email address.

The problem with your header option workaround is that mailsend puts its own "To: john.smith@example.org" header in, so if I added an additional one I end up with:

To: john.smith@example.org To: John Smith john.smith@example.org

which really isn't correct.

I see no way to do want I want here, cleanly, like I think I can do in blat or CMail.

This is the only non-trivial issue I've run into so far with mailsend. I'd appreciate it if you'd consider some method whereby a user could simply specify display names in a way that's functionally similar to how blat, CMail and others work.

Thanks again for your consideration.

[muquit]

Actually mailsend does not add any To header, it is added by SMTP server (Which was used in RCPT TO). If you can send me a sample of mail sent by Blat or CMail (with raw headers) it would be great, otherwise I will look at it when I get some time.

Thanks.

[muquit]

If you are trying to change display name, it can be accomplished with -name option. Example: -name "\"Your Name\" <you@example.com>". I am not sure why you want to add name with To.

[tgice]

Here's a snippet of what I'm talking about, with '-superdebugT' option in blat (which shows all of the SMTP protocol activity):

  220 mail.example.com ESMTP Postfix
  <<<getline<<< 220 mail.example.com ESMTP Postfix
  superDebug: Attempting to send 13 bytes:
  EHLO ClientPC
  >>>putline>>> EHLO ClientPC
  superDebug: Received 179 bytes:
  250-mail.example.com
  250-PIPELINING
  250-SIZE 22528000
  250-ETRN
  250-STARTTLS
  250-AUTH PLAIN LOGIN
  250-AUTH=PLAIN LOGIN
  250-ENHANCEDSTATUSCODES
  250-8BITMIME
  250 DSN
  <<<getline<<< 250-mail.example.com
  <<<getline<<< 250-PIPELINING
  <<<getline<<< 250-SIZE 22528000
  <<<getline<<< 250-ETRN
  <<<getline<<< 250-STARTTLS
  <<<getline<<< 250-AUTH PLAIN LOGIN
  <<<getline<<< 250-AUTH=PLAIN LOGIN
  <<<getline<<< 250-ENHANCEDSTATUSCODES
  <<<getline<<< 250-8BITMIME
  <<<getline<<< 250 DSN
  Sending stdin.txt to john.smith@example.com
  Subject: test
  Login name is john.smith@example.com
  superDebug: Attempting to send 40 bytes:
  MAIL FROM:<john.smith@example.com>
  >>>putline>>> MAIL FROM:<john.smith@example.com>
  superDebug: Received 14 bytes:
  250 2.1.0 Ok
  <<<getline<<< 250 2.1.0 Ok
  superDebug: Attempting to send 38 bytes:
  RCPT TO:<john.smith@example.com>
  >>>putline>>> RCPT TO:<john.smith@example.com>
  superDebug: Received 14 bytes:
  250 2.1.5 Ok
  <<<getline<<< 250 2.1.5 Ok
  superDebug: Attempting to send 6 bytes:
  DATA
  >>>putline>>> DATA
  superDebug: Received 37 bytes:
  354 End data with <CR><LF>.<CR><LF>
  <<<getline<<< 354 End data with <CR><LF>.<CR><LF>
  superDebug: Attempting to send 379 bytes:
  Date: Thu, 10 Aug 2017 17:44:20 -0500
  From: john.smith@example.com
  To: John Smith <john.smith@example.com>
  X-Mailer: Blat v2.6.2 w/GSS encryption, a Win32 SMTP/NNTP mailer http://www.blat.net
  Message-ID: <01d3122a$Blat.v2.6.2$3645530b$142462d40d91@example.com>
  Subject: test
  Content-Transfer-Encoding: 7BIT
  Content-Type: text/plain; charset=ISO-8859-1
  body
  .
  superDebug: Received 33 bytes:
  250 2.0.0 Ok: queued as 2059D61
  <<<getline<<< 250 2.0.0 Ok: queued as 2059D61
  superDebug: Attempting to send 6 bytes:
  QUIT
  >>>putline>>> QUIT
  superDebug: Received 15 bytes:
  221 2.0.0 Bye
  <<<getline<<< 221 2.0.0 Bye

and the resulting email I get in my client (with later, not-relevant headers stripped and again, as I did above, mailbox and domain names changed for privacy):

Date: Thu, 10 Aug 2017 17:44:20 -0500
From: john.smith@example.com
To: John Smith <john.smith@example.com>
X-Mailer: Blat v2.6.2 w/GSS encryption, a Win32 SMTP/NNTP mailer http://www.blat.net
Message-ID: <01d3122a$Blat.v2.6.2$3645530b$142462d40d91@example.com>
Subject: test
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1

body

I don't know how it's working vs the test I did with mailsend where I included a custom 'To:' header with the display name and ended up with two 'To:' headers in the email body, but somehow, blat and this server are interacting in such a way that only a single To header ends up in the email, and the RCPT TO exchange only uses the bare email address.

Also, you said above that mailsend does not add the 'To:' header itself -- are you sure? When looking at a mailsend session in '-v' mode right now, it appears to me that mailsend does include the To header, right between the Date and the X-Mailer headers, which would explain why I get two when I try to include my own custom header including Display Name.

[tgice]

I figured you (and I guess all users of mailsend) have no need to add display names to To,Cc,BCc addresses, but it is something that I'm generally accustomed to doing (when I have them available), even though it's not critical.

I guess it's mostly just so the email client displays some addresses in the cleaner format vs. the sometimes messier real email address.

And it definitely is something that's supported by the RFCs for email and by some of these other command line clients.

If you're not interested in supporting such a feature, I understand.

I think it might be difficult for you to support it without breaking backwards compatibility on your '-t' option, etc., but maybe I'm misunderstanding how it's parsed.

Thanks again for your replies.

[muquit]

I don't have any problem supporting it. I have to play with it over the weekends to see what's going on. It appears Blat is just adding a To header in DATA section like mailsend does. But I didn't try with postfix to test how it differs with gmail smtp. Thanks.

[muquit]

So you tried mailsend and Blat with the same SMTP server and mailsend is behaving differently than Blat?

Thanks

[tgice]

Hi again, sorry for the long delay in response, but I did some further testing. I went out of my way to install stunnel to get blat to talk to Gmail's SSL SMTP (something I do not want to do in production, hence my investigation of mailsend and cmail [as an alternative]).

I ran a command line like this (all have been obfuscated, but it should be simple to make them really work if you want to test yourself, by replacing with your own email addresses & gmail authentication):

blat -server localhost:25 -u GOOGLEMAILBOX@gmail.com -pw GOOGLEPASSWORD -f "Sender Name <GOOGLEMAILBOX@gmail.com>" -t "John Smith <john.smith@example.org>" -cc "CC Receiver <john.smith.cc@example.org>" -subject "Blat Test" -body "Test Body" 

cmail -host:GOOGLEMAILBOX:GOOGLEPASSWORD@smtp.gmail.com -starttls -secureport -from:GOOGLEMAILBOX@gmail.com:"Sender Name" -to:"john.smith@example.org:To Receiver" -cc:john.smith.cc@example.org:"CC Receiver" -subject:"Cmail Test" -body:"Test Body"

mailsend -smtp smtp.gmail.com -port 587 -starttls -auth-login -user GOOGLEMAILBOX@gmail.com -pass GOOGLEPASSWORD -f GOOGLEMAILBOX@gmail.com -t "To Receiver <john.smith@example.org>" -sub "Mailsend Test" -M "Test Body" 

You can see how blat & cmail use different syntax to allow optional display names for the from, to and cc addresses. Both of them work, as I expected. The email comes in with headers like this:

From: Sender Name <GOOGLEMAILBOX@gmail.com>
To: John Smith <john.smith@example.org>
Cc: CC Receiver <john.smith.cc@example.org>

which is exactly what I want. Cmail's headers look essentially identical. As mentioned in earlier posts, when I try a command line like the above mailsend, as you know, it fails because Mailsend parses off the first space-delimited token, 'To' and tries to use it in a RCPT-TO:

RCPT TO:

which of course causes Gmail to drop the connection. I don't think the problem here has anything to do with the particular SMTP server (whether Postfix, Gmail, etc.) -- it has to do with Mailsend's inability to accept display names for To, CC, BCC.

If I had my preference, what you'd add to Mailsend (perhaps to completely avoid the possibility of breaking backwards compatibility) would be a new file-based recipient option rather like '-list_address' only it's of a type where you can specify, one per line, an email recipient, whether it's To, CC or BCC and have an optional Display Name included, with a syntax like blat or cmails above, or something else that makes sense to you.

If you could even include the (only) From address in the same format in that file, that'd be even better.

Anyway, whatever you choose to do, I just wanted to point out that at least two other similar utilities do successfully support this, and that's why I was going to the trouble of reporting the issue to you.

Thanks for your attention, and your product.

jl

[muquit]

Thanks for the input. I will look at it as soon as get some time!

Just looking at your example, the way To is specified it can not be used with RCPT as you saw. So are they not just custom headers? Then why they can not be specified with -H with mailsend? A quick observation. I will give it a deeper look.

Thanks.

[tgice]

Yes, I think what happened when I tried to do a custom To header (which of course I don't need to do with blat and cmail), it still doesn't really work properly because the final email ends up with two To headers, one that I've specified and one that mailsend (or the SMTP server, as you theorized) embedded itself, without the display name.

So that's not a solution for both the additional hassle and the fact that it doesn't result in a proper RFC compliant email anyway (I don't think multiple To, CC, BCC headers are allowed).

[SirHumphreyAppleby]

tgice. You are correct, mailsend does add the To header, and the issue is not specific to certain SMTP servers. Blat and CMail both parse the settings to extract the addresses for the envelope (rcpt to), then insert To/Cc headers into the message with the address and display name if provided. Both take different approaches to handle this, using tokens or escape sequences to handle some of the edge cases, as e-mail addresses can be quite complex.

A quick workaround for mailsend could be to surpress the addition of a To header if one is provided using -H. This has limited scope for abuse as it's not really any different from specifying recipients using Bcc. It could however be used to suggest an e-mail was also sent to someone it wasn't.

Disclosure: I am the author of CMail.

[tgice]

Thanks for the confirmation, Sir. For the time being, I will probably be using CMail for my immediate application.