[atlas] RIPE Atlas SMTP Measurement

Two more thoughts:

1. obfuscated DNS entrys should be possible too, of course.
2. i think it would be the best to ask applicants in the apply-form, if they can provide a reverse dns record for the probe they apply for.

BR,
Simon



On 03.09.22 14:48, Simon Brandt via ripe-atlas 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20220903/cdd0d0f9/attachment.html>