Why no SMTP Auth?
 

Hi,

I tested another provider and found out, that it is possible to use SMTP Auth with own Domains. Which is kind of neat.

Why does Fastmail not use SMTP Auth within it's service? It would be much more secure as I can be sure, that no one else is using my domain/alias to send mails from...

What do you think about?

Fastmail does use SMTP AUTH - it authenticates you as a user when using their submission servers, but it has nothing to do with what their servers will relay.

Fastmail will let you relay email purporting to be from other systems. I'm not sure whether this applies to other people's local addresses and hosted domains - I've never tried spoofing another user.

I don't understand what is bothering you. As the previous post describes, Fastmail does require SMTP Authentication (over a secure connection).

• This means that someone attempting to use the Fastmail SMTP outgoing email server must authenticate using a password.
• Even better, Fastmail forces you to use a unique App Password for every email client you use. If you lose your phone or PC with an email client installed, you can disable that one App Password so that one device is disabled from sending or receiving email.
• You can choose which services that device can access. So you can enable one device to access your Fastmail calendar but not send or receive email.
• See: https://www.fastmail.com/help/clients/apppassword.html

But SMTP Authentication has nothing to do with your complaint:
The existing email standards allow anyone to use your domain/alias in the From field of their emails!

• There is currently no way to prevent any SMTP sending server from generating an email using any From address, including one at your personal domain.
• However, the destination (receiving) server can choose to reject connections from known insecure sending servers.
• Spam filtering systems at the destination server can also use sender authentication (which has nothing to do with SMTP authentication) in an attempt to verify that the email was sent by the intended sender, and there are several current and new methods to do this. See:
  https://www.fastmail.com/help/techni...ntication.html
• Fastmail supports some of these sender authentication standards on both the sending and the receiving end. For example, if you host your domain with Fastmail they can provide support for sending messages with features such as:
  • DKIM
  • SPF
  • DMARC
• For example, I host my domain (and DNS records) at Fastmail. When I send email through the Fastmail outgoing SMTP server, DKIM proves that my message was not corrupted (accidentally or purposely) during transmission and relays. SPF allows me to specify that only the Fastmail SMTP outgoing servers are allowed to send messages From my domain without generating an internal warning at the receiver. DMARC allows me to specify that I want messages that fail both DKIM and SPF tests to be rejected - I can't force the receiving server to reject these fake messages, but I can instruct them that I want them to take that action.

So if you host your personal domain at Fastmail, it's possible to set it up so that you are doing everything possible to specify that others don't spoof your domain with fake emails. But you can't force other email servers to follow these standards.

Bill

There's nothing in the standards that requires a submission server to relay arbitrary content or allow spoofing of any address. It's a matter of policy and what the software allows.

It's convenient that FM allows people to send email from third-party domains, but it shouldn't allow anyone to send using someone else's address that hosted at FM. If they do it makes a mockery of SPF and DMARC.

The likes of Google and Microsoft don't allow it, I would hope FM doesn't, but I've never tested it.

I believe there can be legitimate reasons why one might want to send using a FastMail email address other than your own in the From field. However, the owner of the address ought to first authorise doing so.

It looks like they do allow it. I found an FM hosted domain in a mailing list and spoofed the address (both header and envelope) in an email to a gmail account of mine. It was received, as expected, with a DMARC pass.

That's not good - clearly FM could prevent that. Have you reported it?

It haven't because it doesn't really effect me.

Surely it potentially affects all of us. I raised a ticket.

FM's reply:

We are aware of the potential for spoofing or rewriting
of headers, and this is a limitation of email itself and
not specific to Fastmail! Anybody can send emails using
any Fastmail address. This is similar to someone going
around sending postcards or snail mail to people but
forging your postal address. The postal department will
deliver the cards, but they really can't stop someone
from doing this. We are in a similar situation here..

To address any instances of abuse we maintain the
monitored address abuse@fastmail.com. We take any
reports of phishing, spam or fraud very seriously.

If a message is sent from the Fastmail SMTP servers, the
full headers of a message will evidence the original
sender in the form of an encrypted header, X-ME-Sender.

This is a header which we can use to find the sending
account for any email sent by a user, this is used when
handling spam and email abuse. As this header is
encrypted it is not possible for third parties to use
this to find a sending account.

Please let me know if you have any additional questions.


My view: the encrypted header is good news, but of course the recipient of such a mail will not realise that the only way to find out who really sent the mail is to ask FM. And if they're not an FM customer the chances are they won't do that. I still don't see why they can't block misuse my one FM customer of another FM customer's address.

But why not use these sender authentication?

Couldn’t it be possible to check, if the sender is legible to send from this domain (check if the account credentials have a domain which matches the sender)?

It’s actually only a cross check within databases?!

Check if User XX sending with password XX a mail from domain XY if this domain is within it‘s account.

If not. It’s not allowed to send from that domain.

It's not really about spoofing headers, it's about refusing to relay based on the SMTP 'mail from' field.

Snail mail is a good analogy if you live in a country where the post office requires you to provide ID and your return address before accepting a letter, but doesn't require them to match - otherwise it's bogus.

In the case of spear-phishing or other targeted fraud, it's unlikely that X-ME-Sender will be any use.

I replied again, more forcefully. The first-level support person said they'd passed the problem up the line. I'll let you know what the expert says.

Really interested in their feedback.

It would be so much better to have this auth method integrated.

Don't want, that anybody else can send (without a problem) mails with my mail-addresses and domain names...
That's a big issue!

Other mail-providers do check, if the domain belongs to the sender.

I've had a more encouraging reply:

"Yes, what you have noted is actually a known issue. However, the good news is that, its something we plan to address soon. We have a project in progress to restrict sending to be from verified addresses only.

Since this is likely to interfere with some users legitimate workflows it has to be introduced very carefully. So, no timeline at the moment, but we are working on it."


I replied saying that I thought that how useful this turns out to be (for example whether I could send mails 'from' an address I own, that's not an FM one) will depend on what they mean by "verified"...