[atlas] RIPE Atlas SMTP Measurement

Hello Simon,

Thank you for the suggestion.

I have a couple of questions to get a better idea:
Can you maybe describe what a SMTP measurement would look like?
Simple EHLO/HELO
Sending an email to a designated address (which would then validate that the SMTP server is capable of relaying etc.)
How would DNSBL or other spam prevention techniques fit into this? 
What would the result be? 
Delay until mail received
Response time by the actual mail server
Using the Received: headers to get a “traceroute” like result.
What about the more uncommon ports such as 565 (SMTP+SSL/TLS) or 587 (mail submission port).
How can we prevent this implementation from having RIPE Atlas be identified as a spam bot network?
 
Best regards,

Michel

> On 3 Sep 2022, at 14:48, Simon Brandt via ripe-atlas <ripe-atlas at ripe.net> wrote:
> 
> Hello,
> 
> i'd like to start a discussion about having a RIPE Atlas SMTP measurements.
> First of all: yes, i know there's a big obstacle for such a measurement type. A lot of probes are deployed using enduser internet-connections like dsl, cable, etc. with dynamic/eyeball IP addresses. Those IP spaces are usually blocked by SMTP servers as approach to reduce spam mails. For Example: by using blocklists like Spamhaus PBL. So a proper SMTP measurement wouldn't work.
> 
> BUT we could have an easy way for RIPE Atlas probe hosters to signalize, that their probe is eligible for SMTP measurements:
> 
> Step 1: enable "Simple DNS Entry"
> Step 2: create a matching reverse DNS record for the probes IP address
> 
> Everybody who is able so configure a reverse DNS record for his probes IP address, is most likely using a non-dynamic/non-home ip address space e.g. a datacenter or office network. If an ISP provides the option for his customers to configure a reverse DNS record, it's most likely a "business-customer" subnet which can be used to run mailservers. After Step 1+2 are done, the RIPE Atlas platform would easily be able to verify if forward-confirmed reverse DNS is successful, and if so, automatically enable that probe for SMTP measurements. Alternatively: probe hosters choose their own Forward-confirmed reverse DNS name and submit it on the RIPE Atlas website.
> 
> Also: if we would have STMP measurements, forward-confirmed reverse DNS should be mandatory for anchors, or is it already?
> 
> Why should we have SMTP measurements?
> 
> Besides general reachability checks, we could also evaluate SMTP response codes. But the most important thing for me is this: the SMTP protocol is old. Very old. From a security point of view, it's absolutely outdated. Most security features have been added years after the initial RfC. Thus, those security features are optional. Mandatory SMTP encryption is not provided by the SMTP RfC. So both sides have to signalize, that they are capable of encryption using the STARTTLS command. An attacker (man-in-the-middle) can perform a downgrade attack by suppressing the STARTTLS command. So both sides are forced to fallback and communicate unencrypted. RIPE Atlas would be a really good tool to identify such attacks, by monitor/measure the (enhanced) status codes of a target.
> 
> But there's more!
> I see a two-sided model here. Either use the RIPE Atlas SMTP measurements to monitor/measure your own mailserver by alot of other RIPE probes out there, OR probe hosters could run SMTP measurements originating from their own probe to find out, if their own IP address is currently blocked by other mailservers.
> 
> 
> What do you think?
> 
> 
> BR,
> Simon
> -- 
> ripe-atlas mailing list
> ripe-atlas at ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20220915/6dcd2484/attachment.html>