Greetings,

If you are here because some of our IPs showed up in your mail server logs, the following explanations aim to address your questions and concerns.

We can assure you of the following:

1. We did not attempt to deliver spam to your server. Our software does not (and in fact cannot) send any emails whatsoever.

2. We are not checking for security holes or otherwise attempting to gain elevated access to your resources.

1) Our process.

We are running an email validity-checking process for research purposes.

This consists of connecting to the remote SMTP server and asking it (RCPT TO) if one or several recipients are considered an acceptable destination.

The queried recipients will be one of the following:

1. The postmaster@ address.

2. A string we use to ascertain the catch-all status.

3. Opt-in customer lists of small and medium-sized companies which are using our service to prune their contact lists (not spammers).

The interaction with the remote server is meant to be minimal and performed with limited IPs and Domains, we simply:

1. Connect to the public SMTP port.

2. Exchange standard handshake messages.

3. Send the RCPT TO commands (containing recipients).

4. Disconnect.

In case of a failure, we may retry the process from different IPs.

We do not send any emails.

2) What do your logs show?

The above description of the use case will be corroborated by the logs, which will show that, our machine[s]:

1. Connected to the SMTP port.

2. Exchanged the standard protocol messages mentioned above.

3. Disconnected.

There is nothing in our activity that could, upon an exhaustive technical analysis, be mistaken for:

1. An attempt to send an email.

Our software is not programmed to send the full set of SMTP commands required for the sending of emails.

You can verify this right now if you’re looking at the logs: our client always disconnects after the RCPT TO commands, and did not attempt to proceed with filling in an email subject or the body.

2. A brute force password-guessing attack.

We do not attempt to authenticate with a username/password combination.

3. An attempt to hack the remote system.

We do not perform any commands that aren’t part of the SMTP standard (including any specially crafted payloads which could be used to exploit a known or unknown vulnerability).

3) Summing up.

For the above reasons, we consider that our activity does not represent abuse.

• We have performed hundreds of millions of checks thus far, without triggering a single abuse report indicating specific damaging or malicious behaviour in our activity.

• We strive to adhere to all protocol regulations and best practices in our data collection activities.

We believe this is sufficient to address your concerns.

4) Possible actions on our part.

On request, we can prevent your @domain[s] from being included in any future project.

Please just let us know what @domain[s] you want exempted by writing to our [email protected] email address.