Telnet Email Address Validation (Existence)

CyberPunk Tips & Tricks
Telnet Email Address Validation (Existence)

Introduction

Whether it’s reconnaissance or some useful email address validation pre-processing, it might be handy to know a few things about telnet email address validation. This subject is tightly related to OpenRelay hunt/abuse, email Spoofing, spam and other nice things, but that’s not what we’re after. Our goal here is to find a passive way to check if there is a specific email address on a mail server. So, educational purposes only, be nice 🙂

Methods mentioned here are still used, but it’s not exact science. Different rules, services and limits have different behaviour, provide different answers. It takes time and experience to know them all and find some of your answers. There are a lot of tools & services out there (metasploit, smtp-user-enum, nmap, ismtp), that do this kind of checks automatically, but we’re going raw here.

Mail Server Ports & Commands

Quick info on email Server ports:

  • SMTP, Port 25:
    • Allow Encryption: Yes, after connections is opened, using <cmd> STARTLS
    • Allow Plain: Yes
    • Relay, Server2Server
  • SMTP, Port 465 (SSL/TLS):
    • Allow Encryption: Yes, implicit, as soon as connection is opened
    • Allow Plain: No
    • Used for SMTP relaying (email sending)
    • IANA has reassigned this one to a new service. It should no longer be used for SMTP communications, but it frequently is.
  • SMTP, Port 587 (STARTTLS):
    • Allow Encryption: Yes, explicit, after connections is opened, using <cmd> STARTLS
    • Allow Plain: Yes
    • Default mail submission port. When a mail client/server is submitting an email to be router by a proper mail serv, it should use this port.
  • IMAP, Port 143:
    • Allow Encryption:Yes, after connections is opened, using <cmd> STARTLS
    • Allow Plain: Yes
  • IMAPS, Port: 993 (SSL/TLS):
    • Allow Encryption: Yes, implicit, as soon as connection is opened
    • Allow Plain: No
  • POP3, Port 110:
    • Allow Encryption: Yes, explicit, after connections is opened, using <cmd> STARTLS
    • Allow Plain: Yes
  • POP3S, Port 995:
    • Allow Encryption: Yes, implicit, as soon as connection is opened
    • Allow Plain: No

and most important SMTP commands:

  • HELO – This is the command that the client sends to the server to initiate a conversation. Generally, the IP address or domain name must accompany this command, such as HELO 192.168.101 or HELO client.microsoft.com
  • EHLO – This command is the same as HELO, but communicates to the server that the client wants to use Extended SMTP. If the server does not offer ESMTP, it will still recognize this command and reply appropriately
  • STARTTLS – Normally, SMTP servers communicate in plaintext. To improve security, the connection between SMTP servers can be encrypted by TLS (Transport Layer Security). This command starts the TLS session
  • RCPT – Specifies the email address of the recipient
  • DATA – Starts the transfer of the message contents
  • RSET – Used to abort the current email transaction
  • MAIL – Specifies the email address of the sender
  • QUIT – Closes the connection
  • HELP – Asks for the help screen
  • AUTH – Used to authenticate the client to the server
  • VRFY – Asks the server to verify is the email user’s mailbox exists

Email address validation steps

To find a domain mailserver, rely on nslookup or dig cmd:

# nslookup set type=mx
random_domain.com
mx.random_domain.com internet address = 1.1.1.1

or

# dig mx random_domain.com
random_domain. 300 IN MX 10 mx.random_domain.com.

Then go ahead and try to connect. Usually it’s port 25 (smpt), but sometimes 465 and 587 work just fine.

# telnet mx.random_domain.com 25

There are couple of methods you can sometime use to determine if a recipient actually exists:

VRFY

Some servers support this, but you can try. If user exists the server responds with a 2.0.0 DSN (250, 251, 252), the user exists, e.g.:

HELO random_domain.com
VRFY admin@random_domain.com 
252 2.0.0 admin@random_domain.com 
VRFY non-existent-user@random_domain.com 
550 5.1.1 <non-existent-user@random_domain.com>: Recipient address rejected: User unknown in virtual mailbox table

EXPN

EXPN asks the server for the membership of a mailing list. Some servers treat a local user as a “mailing list” with one subscriber, so that EXPN subsumes VRFY.

EXPN ALL

250-User1 User <User1@random_domain.com>
250-User2 User <User2@random_domain.com>
...

RCPT

HELO random_domain.com
250 mx.random_domain.com Hello [xxx.xxx.xxx.xxx]
mail from:<user@random_domain.com>
250 Sender OK
rcpt to:<user@random_domain.com.com>
550 Anti-Spoofing policy - Inbound not allowed - https://community.random_domain.com.com/docs/DOC-1369#550

Hmm, refused.. Ok, before we continue, you should check few other details about mail server anti- spam/spoof defenses (at least SPF). There might be a way around this:

We stuck with “Anti-Spoofing policy – Inbound not allowed” (but the message can be anything, blocked, Spam, ..). If we check DNS TXT record of the domain:

# dig TXT random_domain.com
random_domain.com. 60 IN TXT "v=spf1 include:_netblocks.domain.com include:other_domain.com ~all"

We can use that information to change our query:

# telnet mx.random_domain.com 25

HELO random_domain.com
250 mx.random_domain.com Hello [xxx.xxx.xxx.xxx]
mail from:<user@other_domain.com>
250 Sender OK
rcpt to:<user@random_domain.com.com>
250 Recipient OK

Now, we went through. Recipient address is confirmed.

SMTP-TLS / SSL

With secure email transmissions, you can rely on openssl cmd  to test (optionally include -debug) :

# openssl s_client -starttls smtp -crlf -connect mx.cyberpunk.rs:587
CONNECTED(00000003) 
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = cyberpunk.rs
verify return:1
---
Certificate chain
0 s:/CN=cyberpunk.rs
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGFjCCBP6gAwIBAgISAy7aM+6MAb6LGXUFzpr/dAiTMA0GCSqGSIb3DQEBCwUA
...
...
---
250 DSN
> EHLO cyberpunk.rs
235 2.0.0 OK
> MAIL FROM:<test@cyberpunk.rs>
250 Sender address accepted
> RCPT TO:<recipient@cyberpunk.rs>
250 Recipient address accepted

Check mail server vulnerability (OpenRelay)

Check your TXT records for v=spf1, and v=DMARC1.

If SPF record ends with “-all” that’s ok. If it ends with “+all” or “~all”  then DMARC record must contain “p=reject” or “p=quarantine“. In any other case it’s insufficient (Control: p-main domain, sp-subdomains)

Note: Vulnerable variants:

  • If there is no SPF at all
  • The SPF is set with softfail only
  • A SPF with softfail and DMARC with action none

Open Relay

Server is an open relay if it accepts messages on behalf of other domains and does NOT require user authentication. Of course, such servers are frequently misused by spammers to send unsolicited emails. It can be a way to bring down your network to its knees (by sending millions of emails) or it can lead to your server being banned. There are some databases that keep track of Open Relay servers, and can result in many SMTP servers refusing to accept emails from you.

Use some online tool. There is a vast number of services that offer this:

  • https://mxtoolbox.com/diagnostic.aspx
  • https://mxtoolbohttps//www.wormly.com/test_smtp_serverx.com/diagnostic.aspx
  • http://smtper.nanogenesis.fr/
  • http://www.test-smtp.com/

or, similar to the example at the begining of this article, you can try and send email youself:

# telnet mx.your_mail_server.com

EHLO your_mail_server.com
250-ESMTP Server Ready
250-SIZE 0
250-DSN
250-STARTTLS
250 TLS
MAIL FROM: <valid_user@your_mail_server.com>
250 +OK Sender OK
RCPT TO: <valid_user@any_domain.com> SIZE=43251
250 +OK Recipient OK
DATA
354 Start mail input, end with '<CR><LF>.<CR><LF>'
TO: Valid_user
FROM: valid_user@your_mail_server.com
SUBJECT Test
Here is the content text
.

250 2.0.0 ???????? Message accepted for delivery
QUIT

Mail is at this point sent, and that is a certain sign you’re open to abuse. If you receive some type of refusal message:

RCPT TO: <valid_user@any_domain.com> SIZE=43251
550 mail@myisp.com... Relaying Denied

You’re probably in the clear.

Additional Info

Here and there people mention that the only way to validate address is to send an email to it. If it bounces back, it doesn’t exist. That’s not always the case. There are “Catch-All” email addresses, which receive even invalid ones. In such cases email doesn’t bounce back to a sender, and there’s no reliable way to detect catch-all emails. Mail can be quarantined or dropped, or bounce simply doesn’t make back to you.

There is also a strange behaviour I didn’t yet get to inspect. For e.g.: *.mail.protection.outlook.com email addresses (Office 365). I was unable to verify them. From terminal/telnet they behave like catch-all addresses, but the emails bounce back if account doesn’t exist. So, it looks like some post-processing.

Random info:

(SSL)-SSL V1.0 (never released by Netscape)
|-(1995)-> SSL V2.0
|-(1996)-> SSL V3.0
|-(1999)-> SSL changes name to->TLS
|-(1999)-> TLS V1.0
|-(2006)-> TLS V1.1
|-(2008)-> TLS V1.2
|-(201*)-> TLS V1.3 (RFC 8446)
V
(TLS)

SSL 2.0 has been deprecated in 2011 (RFC 6176).
SSL 3.0 has been deprecated in June 2015 (RFC 7568) – Vulnerable to POODLE attack / man-in-the-middle exploit.

TLS is preferred.

Around 1/3rd of the planet population rely on email. On average, each user has ~2 email addreses. Based on some stats online, close to 90% of daily email volume is spam.

Conclusion

As mentioned , it’s not exact science. There is no 100% reliable way to detect email addresses, but some of these methods might provide the thing you’re looking for. All this can come in handy.

EmailMail ServerTelnet