The Apple Mail app user guide has a page describing how to use aliases in Mail (link below). The steps are all performed within the Mail preferences interface without any mention or requirement of establishing a valid alias with the user’s mail hosting provider. That doesn’t sound like it will work.
Following the steps to create a fabricated user name and email address then sending an outgoing email did work, but when the recipient of that aliased email attempts to reply it fails as an unknown or non-existent address. Any thoughts on what this capability is for, beyond spoofing the sending address on a one-off, one-way message? Perhaps it works differently, yielding successful round-trip communication for @iCloud.com addresses? I tested with a non-Apple address.
Isn’t what Apple is describing how you send email from one account but using name/address of another? That still requires you provide that other valid account. It’s not like Mail would just let you set up random new email addresses that get aliased to an existing address. Or have I misunderstood the question?
I was unaware of this feature, so thanks for the interesting question. It does seem to be a bit bizarre, from what I can tell. It appears to use the outbound server settings for the legitimate account to which it’s assigned to send an email whose Return-Path and envelope-from headers have the value of the alias, which could be completely bogus.
However, as you observed, it’s only one way. Since the above headers are (essentially) faked, there’s no way for anyone to reply to such a message.
If you have an iCloud account, Mail does offer a “Hide My Email” option in the From: drop-down menu for new messages. That creates a legitimate, random email address that works for both sending and receiving.
The headers aren’t faked, and it’s not one-way. I have multiple, valid, email addresses that point to the same mailbox on my email host. So in Mail, the account has the details of the mailbox, but I also have aliases for the account with the other email addresses. Mail would be seriously crippled without this feature. As @Scott5 notes, creating an alias in Mail does not create a valid alias at the hosting provider. But that isn’t the point of this feature. This feature allows you to send email from addresses/aliases you have already created with your hosting provider. Without it, there would be no way to do that (from Mail).
[As a side note, earlier versions of Mail on MacOS X supported aliases but if you wanted a different name to go with the alias, you had to manually edit a plist file. I’m very glad those days are behind us!]
Interesting. I do have multiple mailboxes at my hosting provider. However, I’ve set up each one as a separate account in Mail. If I understand you correctly, I could use one account in Mail, but create an alias attached to that account for each of the other mailboxes? So if I have, say, 10 mailboxes on my email host, I’d create one account in Mail, and attach nine aliases to that account? If that is correct, then the advantage is that managing nine aliases is easier than managing nine accounts in Mail? Or are there additional benefits?
It seems (from the linked help page) like I could choose my iCloud account address in Mail Settings, (for example) email@example.com, and then enter a new email address, (for example) firstname.lastname@example.org, and then I can receive email to either address at the first address. Is it that simple? And what if the second address already exists?
To further confuse me, it appears that I can do this for my Google account. Or for my school account. How does this work?
The idea isn’t to send mail with bogus addresses, although can (as you determined) do that. But as you already found out, nobody can reply to your bogus address, and you may also run afoul of spam filters.
This feature is meant so you can use one outbound mail server for multiple legitimate mailboxes.
For example, I have 7 different e-mail address. Three free webmail services (which I normally use), plus one from my college, one from my ISP and my work address.
I can choose to configure a mail client so that when I send mail from each of these addresses, the mail is sent through that service’s server. But I could also choose to send all of my mail (regardless of address) through a single server. That’s what this feature is for.
Why would you want to do that? I can think of many possibilities, including:
One service’s server is better than the others. Maybe it has more bandwidth or holds mail for less time before forwarding it to its destination.
One server might be down, and you want to send through another one so you don’t have to wait for it to come up again.
Your network (corporate or ISP) may have a firewall policy that prevents you from sending mail through anybody else’s server.
You’re using a mail aggregator service (e.g. you can configure Google to collect mail from multiple accounts and present it all in your GMail box) and you want to send all your mail via the aggregator’s server.
And, of course, it also supports services where you can have multiple addresses tied to a single account. For example:
Apple mailboxes come in @icloud.com, @me.com and maybe also @mac.com varieties.
Most ISPs support “plus addressing”. You can suffix a + character and arbitrary text to an e-mail address without changing how it is delivered. For example email@example.com and firstname.lastname@example.org and email@example.com all refer to the same mailbox.
So you can configure your mail client with a bunch of these variants - you can choose which one you want to send with and replies will come back to them. You can then filter your mail based on this or use the suffixes to identify which web site sold your address to spammers.
If you own your own mail domain, you can configure it so your mailbox receives all mail delivered to the domain. You can then generate as many addresses as you want and give them out as you see fit.
As others have pointed out, this feature is to allow you to use multiple addresses with a single mailbox. If you don’t already have other addresses, it doesn’t set them up on the server side. If the utility of all this isn’t apparent – and yes, it’s an obscure but important feature – it might not be something you need. In my situation, I own my own domains, so I have many email addresses that I want consolidated into one mailbox. This feature allows me to do that, and choose a “from” address when I create a new message.
Wow. I think my mind just got blown (tiny target, very small explosion).
Let’s say I own “mydomain.com.” My standard email address is firstname.lastname@example.org. If I understand you correctly, you’re saying I could add “email@example.com” as an alias to my Mail account for iCloud (where I have a traditional mac.com address), and then when I send an email from firstname.lastname@example.org, it will actually be transmitted by Apple’s servers?
If so, that may relieve the persistent issues I’ve had with the hosting provider for mydomain.com (where I share a server) having their outbound email servers blocked from time-to-time due to other spammy tenants I’m forced to live with. It would also make moot all the work I’ve done to DMARC-ify mydomain.com.
[In trying to answer my own question, I just did a test. You can’t add a “traditional” alias (the type we’ve been discussing) to an iCloud account in Mail. If you try, it takes you to iCloud.com where you’re permitted to associate another sender name with your iCloud account, but not a full email@example.com address. Gmail will allow this, but there are some odd transformations and headers in the raw source, and a reply to a message sent from Mail via a Gmail alias won’t necessarily go back to the alias that sent it. In my case, it somehow transformed the “firstname.lastname@example.org” address into my primary “email@example.com” address (see below–some obsfucation has been added.]
Sender: fisxxxx <firstname.lastname@example.org>
From: Jeff Fischer <email@example.com>
X-Google-Original-From: Jeff Fischer <firstname.lastname@example.org>
That isn’t what this feature is for, and it wouldn’t work reliably. If you had both an account with email@example.com and also used that address as an alias on your firstname.lastname@example.org account, the account/server that Mail uses to send email will be indeterminate. Since the email@example.com address is now associated with two accounts, Mail will just pick one to send with and you can’t influence the choice. If you want to send email from your firstname.lastname@example.org account through the email@example.com server, you can set this in Mail preferences/settings: Accounts » Server Settings » Outgoing Mail Account.
No, in general you can’t do this. From a technical standpoint you can theoretically do it, and in the early days of the internet you could do it from a practical standpoint too. But those days are long gone. Many/most SMTP servers will outright reject email you try and send through them that doesn’t come from one of their supported domains, and the anti-spam records in a domain’s DNS record will ensure that messages which do get sent are quarantined/binned/rejected by receiving servers.
This won’t work because of the issues I outline above. DMARC and SPF are your friends (even if they are difficult friends to deal with!) so your work was not in vain.
Again, no, this isn’t how this works. For any of your mailboxes, you could set up one or more additional forwarding/alias addresses on your hosting provider. So if you have firstname.lastname@example.org you can create a forwarding address that points to it called email@example.com on your host. Then in Mail you set up an account for firstname.lastname@example.org and as part of that account create an alias email@example.com using the feature discussed in this thread.
Thanks for the response. Probably I don’t need it, but sometimes there’s something new that becomes something I need.
I use that, but many organizations (erroneously) claim I’ve entered an invalid email address when I enter it on a web page. And one organization let me enter it to conclude a transaction, but won’t let me enter it to see the transaction after the fact. Bah!
Assuming Apple’s mail servers allow it. But based on your test, it would appear that they don’t.
As @jzw wrote, open relays no longer exist on the Internet, because spammers abused them into oblivion.
But if a service provider requires authentication before sending (that is, requiring an explicit login of some kind) instead of just deciding based on your provided source address, then it might work. As long as the account you log in to the server with is valid, they may allow you to use any source address you like (or may allow you to register your own addresses with them in order to permit their use). The mail will be delivered via the server you configure, even though the “From:” address in the message header has your own domain address.
Since I’m not a user of Apple’s mail client, I can’t really disagree.
But I know that with my mail client, Thunderbird, whenever I configure an account, its SMTP server goes into a big list of configured servers. I can choose which server each e-mail account uses for its outgoing mail. Yes, I can only configure one server per account, but I can change it at any time, and all the accounts can use the same server.
This depends entirely on policy. I’ve seen plenty of servers (especially corporate and ISP servers) where you are expected to provide some kind of login credentials to the SMTP server (SMTP AUTH is one. There are other mechanisms as well) as a part of the sending process. As long as the login credentials are valid, they know the mail is coming from a legitimate customer and will forward whatever you send (maybe requiring you to register your source addresses with them in advance, maybe not).
But yes, open relays are long since dead and gone. This mechanism was much easier back before the spammers ruined the Internet for everybody else.
Again, in theory they can but in practice I have found this to be relatively rare these days, an understandable (though depressing in its necessity) belt-and-braces approach to preventing spam. In my experience, the big providers don’t allow sending email from arbitrary alternate domains through their servers, even though authentication is required. Obviously this will vary based on what email providers someone is using, but I wouldn’t assume I could rely on using an arbitrary (authenticated) SMTP server to relay my mail.
Mail is exactly the same. However the alias feature discussed in this thread is a different thing. It’s a way of populating the From: pop-up menu with multiple addresses so you can easily select on a per-message basis what address to send from. The account settings used for a particular address, including SMTP server, are based on which account includes the ‘from’ address either as its main address or an alias. It’s up to the user to make sure the ‘from’ address is a valid address – both in terms of being able to receive replies and that the SMTP server selected on the associated account will send email for that domain.
I think what this thread really highlights is that documentation shouldn’t make promises without also providing the caveats and detailed explanation. If it had made these generally true statements (which nonetheless are sadly incomprehensible to those not in the know), probably there would be less confusion:
A mailbox is a collection of folders and messages to access, and the POP/IMAP parameters needed to access it;
An “SMTP” server is used for the submission of email, and it may limit the sender addresses in the envelope and/or header by policy to the user who is logging in to those addresses known to be valid and belong to the user;
An “Alias” is an email address associated with an account that the user can choose to send with;
An account is a mailbox, a default selection of no or a single SMTP server, and one or more aliases (which means that even an account used for incoming email exclusively needs an address, even though it is unnecessary and unused);
mail is sent from a selected alias via the SMTP server configured for the account that lists that alias;
An email address must be configured at a service provider that hosts email for a domain (either directly or indirectly using e.g. a catch-all for a domain or set of domains or using plus-style addressing) to receive mail from the Internet, regardless of whether or not you are able to send mail using that address via any given SMTP server; and
As a practical matter, there is only ever one SMTP server you can use to send e-mail corresponding to a given address, because anti-spam authentication technologies and server policies require it.
It’s also just possible that Internet e-mail has simply got much more complicated since the spammers (and those anti-spammers who thought burning down the village was the best way to save it) ruined it for everyone and made the conditions for simply injecting a message into the Internet’s mail routing facility with the reasonable expectation that it would end up where it was supposed to go infeasible. Which, yes, as a long-time lover and devotee of e-mail, makes me very, very sad.
The aliases for iCloud are unique in that you can’t enter them directly because they are managed by a combination of the iCloud Mail preferences on icloud.com and the iOS Settings app (yes, really). Note though that this does include iCloud Plus Custom Domains, so if you add an address to a custom domain it will appear in your list of iCloud valid aliases just as any mac.com, me.com or icloud.com address would.
There are several places in an email that contain a sending or originating address, but for now let’s focus on the ones used when you send from an alias. There’s the RFC5321 envelope-from address, also called the “Return path”, after a header (called “return-path”), which usually holds the value of the return path in delivered mail. This value is sent between SMTP clients and servers (either during submission, or when messages are relayed between servers). It indicates the address to which reports about a message should be sent in the event of problems, and it is designed to break loops in such mail by requiring such diagnostic mail, itself, to be from an empty envelope sender. Then you have the RFC5322 From person, found in a header in the email message itself, by the name of “From”. It is the originator of the message, i.e. the person who put hands to keyboard (or voice to dictation software, etc) to write the original missive. It’s a required field, it can actually contain multiple mailboxes, and unless other headers in the message say otherwise, it is assumed to be the sender of the message (i.e. the person or entity that dropped the email into an SMTP submission server for onward transmission). This one is the one you recognise as “From”, and it’s prominently displayed by email clients. Depending on policy, either the envelope and/or the From person are restricted to the approved senders. Envelope-from restriction was possible to work around, with effort, if you wanted to use a single provider for sending email for other accounts or identities. But in these (IMNSHO) unenlightened times of heavy anti-forgery protection in the form of DMARC, it is the From person that is frequently being restricted (this is the case with iCloud). Thus any email, even legitimate email destined for your own mailbox, that happens to have a From person different than your own is simply often always rejected, much to the surprise of those who have used the “Redirect” feature to redirect/bounce mail to another party, or to those who have traditionally forwarded automated system mail from UNIX systems to email providers for reading (often coming from usernames like “root”). It is typical, especially nowadays, for email generated by end-user systems and devices to simply always have matching envelope sender and From person; Mail.app offers no configuration, but older, or CLI mailers often do. We live in different times, where the “From” person is heavily authenticated, because it’s the only visible field, and email providers are acting accordingly.
This is correct, providing that all the SMTP settings are identical for all your existing accounts and you are only using other mailboxes than the primary for sending, i.e. those mailboxes are behaving more like aliases. Then yes, it certainly makes much more sense for you to use the alias feature described. Delete all the other accounts and add the aliases to your primary account and, as long as you haven’t lost access to any mail (present or future) in the process, this is a net benefit and much easier to manage. I would, however, advise against using any email address that you are not monitoring in some way; if those mailboxes aren’t forwarding to another account where you can read them, you might reconsider this. In most cases it is easier and more efficient to deploy an actual alias at your service provider that forwards mail; it won’t have mailbox storage associated with it, or any account credentials. This is clearly superior.
Sadly, it is not that simple. In your case, you’re directed to the iCloud Mail app on icloud.com, where you configure the permissible aliases. When you add an alias, you are permitted to send from it, but not before. In effect, Apple takes full advantage of the fact that it controls both Mail.app behaviour and iCloud to ensure that “The Right Thing” (™) is done. Apple gives three aliases per account. You might have more, if your addresses are available at multiple Apple domains due to historical privileges (mac.com, me.com, icloud.com, in order).
As you discovered, Apple won’t let you do it in the UI. But even if it had, that wouldn’t work, because iCloud would refuse mail with a “Forged” From person.
But there’s hope! If you really want to ride Apple’s coat-tails, you could sign up for iCloud Plus, set up a custom domain, add the (max. 3 per mailbox, even for non-family domains) email address(es) you want to use at your domain, then return to the exact same iCloud aliases page and/or iOS Settings app to enable/disable those addresses in the Mail UI in the From pop-up menu, which Apple’s iCloud servers will then gladly accept. (As Part of setting up your domain, you add DNS records to support SPF and DKIM, and you can choose to add DMARC policy as well if you want.) It is possible, with some subterfuge, to trick, albeit temporarily, Apple into maintaining your custom domain configuration, whilst you receive your email, or additionally send it, from other hosts. But it’s a delicate dance and I expect it’s not worth the effort for most. It’s designed to be used as an exclusive solution, and you are properly expected to host your mailboxes with iCloud if you are going to send via their SMTP server. Also, iCloud Custom Domains does now support catch-alls, for receiving; you’re still limited to the 3 for sending, but at least you can get all mail for a domain.