Is it possible not to send an email to the to-recipient seen by the CC/BCC-recipients ?
In other words: Is it possible to send an email via CC or BCC but not to the to-recipient (i.e. the recipient in the 'to' header field) ?
Andrew wants Bob to receive either one of these emails without actually sending it to Alice:
from: Andrew
to: Alice
or
from: Andrew
to: Alice
cc: Bob
Is that possible?
I poorly understand the subject matter, but from my readings it appears as though the sender (Andrew) had to use different recipients for the to and envelope-to fields, but I don't know how this can be achieved.
Does the sender (Andrew) inevitably have to set up his own mail server to achieve this or is there an easier solution?
To, From, CC and even BCC are just headers in the email. You can put in whatever you want, at least if you use a library that gives you control over the headers in your email.
Let's do a very simple example using telnet to send an email.
First, look up which email servers handle mail for a domain (here gmail.com), e.g., with host:
robert@here:~$ host gmail.com
gmail.com has address 142.250.115.19
gmail.com has address 142.250.115.83
gmail.com has address 142.250.115.17
gmail.com has address 142.250.115.18
gmail.com has IPv6 address 2607:f8b0:4000:803::2005
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
I'll use the first given email server, gmail-smtp-in.l.google.com. As per RFC 5321 you can connect to a mail server and send an email like this:
robert@here:~$ telnet gmail-smtp-in.l.google.com 25
Trying 142.250.138.27...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP v9si1145647ooe.55 - gsmtp
Each line starting with numbers is the SMTP server's reply. A code in the 200s is ok, a 400 is a temporary error, and a 500 a permanent error.
Next you say "hello", or rather, the "extended hello" (ehlo) and the server replies with all the extensions it supports:
ehlo me
250-mx.google.com at your service, [1.2.3.4]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
Then you tell the server you want to send an email, using the mail from: command, and telling it the SMTP envelope sender email address. If the server accepts the email, it again replies with something that starts with a 200s code.
mail from: <me@example.org>
250 2.1.0 OK v9si1145647ooe.55 - gsmtp
Then you give the SMTP envelope recipient, and the server accepts again with a 200s code:
rcpt to: <smtp-env@example.org>
250 2.1.5 OK v9si1145647ooe.55 - gsmtp
Next is the data command which the server acknowledges with a 354 code, telling you to enter the message:
data
354 Go ahead v9si1145647ooe.55 - gsmtp
The email is made up of headers, then a blank line, and then the body of the email. The example below is very simplistic, but should work. You specify a From: header, a To:, maybe a CC: or BCC: (sic!) header, and of course a Subject:, Date:, and others.
From: me
To: you
CC: me again
Subject: test
Hello, this is a test.
Here you see 4 headers (From, To, CC, and Subject), followed by the empty line that separates headers and email body, and then the body, which is just that one line.
End the email with a single dot on a line by itself:
.
250 2.0.0 OK 1619472375 v9si1145647ooe.55 - gsmtp
The server now has accepted the message and should either deliver or bounce it. You can now send another email (start over with mail from: above) or end the dialog:
quit
221 2.0.0 closing connection v9si1145647ooe.55 - gsmtp
Connection closed by foreign host.
As you can see, I've entered smtp-env@example.org as the SMTP envelope recipient email address. This is the one that matters, this is where the email actually gets sent. Nothing prevents you from adding people to the CC: or BCC: lines without ever specifying a rcpt-to: for them. They will not get the email, but it will look to the recipients that actually do get the email, that these people should also receive it. Nothing prevents you from adding a different email address in the To: header than what you used in the rcpt-to: command.
Usually, a MUA will add a To: or CC: header that matches the SMTP envelope address, but that is not required. Not having some of these headers, or having headers not match the SMTP envelope commands, may get you some spam points, however.
You don't need a user name or password in many cases. And this is intentionally. For example, you are a gmail user and want to send something to someone on yahoo.com. You will need your gmail user name and password to log in to your gmail account, but you don't need an account with yahoo.com to send email to someone with a yahoo.com account. If you were required to have a login with each email server you could ever want to send to, you'd have to have an insane amount of user names and passwords! This is an advantage of email, it's open, it's free, everybody can run a server and send and receive email.
Du kannst Dir die Welt machen, wie sie Dir gefällt. ;-)
If this whole thing sounds odd, keep in mind that email is an almost 50 years old system, with security, attachments, and non-ascii characters being bolted on over the years, with a constant concern for backwards compatibility. But if you couldn't telnet into other email servers, you'd never be able to send an email to anybody. As the person running the email server, you cannot create accounts for the whole world to be able to receive email from everybody.
When you do this programmatically, it depends on what library you use. Most libraries will set defaults for the headers and let you override headers as needed.