0
  • Case 1: When user creates an account, a confirmation email is sent.
  • Case 2: When user invites a coworker to his/her account, an invitation email is sent.

Problem: If a user makes a typo in the email, it cannot be delivered.

It might be more user-friendly to immediately show an error message to a user if this email cannot be delivered. So this user won't waste time waiting for this email and could fix the typo. The potential risk is that someone can use it to check for someone's else mailbox existence. But there are easier ways to check for email address existence, and with throttling, the risk can probably be mitigated.

I wonder if I missed something from the security point of view.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
Elder
  • 101
  • 2

4 Answers4

1

Generally, when an attacker tries or other directory harvest attack (DHA), it requires using an asset they control to make the probe. Defensive systems like anti-spam gateways take note of this sort of attack and have protections against it.

An attacker could launch such an attack using this service, gaining insight into which emails on a list accept mail while externalizing the consequences (IP reputation, etc) to this service.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
1

If the receiving mail server uses 'greylisting' to block spam, even valid email addresses are rejected at first (the sending mail server has to retry). So, it may take several retries and some time until you know that the email address is valid or not. In general, it is a bad idea to try to use in a synchronous way (the user sits and waits for a reply live) a system that was designed to be asynchronous (email system).

papajony
  • 454
  • 2
  • 8
  • 1
    Greylisting does not reject or issue a permanent delivery failure. As noted in [RFC 5321 §4.2.1](https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.1 "Simple Mail Transfer Protocol § Reply Code Severities and Theory"), it temp-fails (a 4yz reply code, "transient negative completion", basically "please try later") as opposed to rejection (a 5yz reply code, "permanent negative completion", basically "do not retry"). Since greylisting can be impossible to distinguish from actual temporary failures, it would not be responsible to relay that information to a third party. – Adam Katz Sep 14 '21 at 15:09
  • Yes, it is not permanent failure, but the point is that the user cannot wait for the delivery to be completed after mail delivery is retried. – papajony Sep 15 '21 at 16:10
  • 1
    If greylisting is involved and the service is configured to "immediately show an error message" upon any temporary failure, then that will confuse everybody. The whole point of the 4yz codes is that they're temporary! Even mail submission agents (MSA, aka outbound SMTP servers) wait a bit before sending warnings of a pending bounce, so I'm not sure what gain a service would have in reporting them immediately here either. – Adam Katz Sep 15 '21 at 16:19
1

It depends whether you considere existing users as possible attackers or not. And that in turns may depend on the way you validate your users. If a user has only to provide a valid e-mail address to register, then you cannot trust them, at least at the beginning.

There are ways to later validate users and trust them. In some organization, they have to prove their real identity with various ways, including by a physical meeting with an administrator. On other communities, the reputation level can be used to trust users above a threshold.

Once a user is trusted, you can safely send them a warning if they tried to invite a broken e-mail. Simply they should not invite more that a number of bad e-mails in a definite time (a tenth of errors per day) or you should have to declare their account back as untrusted.

If a newly registered user tries to invite a co-worker, you just should warn them that as they are not well known in the system they should contact directly their co-worker if they do not receive a positive confirmation.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
0

Regardless of whether it makes sense for an attacker to use your system for enumeration, it's possible and therefore you should avoid doing this because your sender reputation could be significantly damaged. This could result in loss of service (eg. AWS SES will suspend service if there are too many bouncebacks) or spam/phishing warnings being attached to your emails.

Gethin LW
  • 71
  • 3