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@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
