[atlas] RIPE Atlas SMTP Measurement

> - Forced Encryption: MTA-STS available and 'enforced' or 'testing' or
'report'?

TLS-RPT would also be a good addition to MTA-STS and DANE checks.

> - Forced Authentication: DANE available and check successful?

Just mentioning it, but when DANE is measured then DNSSEC should be as well.

> What we could measure:

In theory things like TCP Fast Open would be nice to measure as well.

On Tue, Sep 20, 2022 at 7:23 PM Simon Brandt via ripe-atlas <
ripe-atlas at ripe.net> wrote:

> Hi Michel,
>
> Currently, HTTP and SSL are separate measurements. But for SMTP it will
> probably not work this way... Encryption is not mandatory for SMTP and thus
> negotiated between client and server every time on port 25. Ports 465 and
> 587 are used for Client Email Submission. You could run some measurements
> for these ports as well, but for the beginning, i would focus on
> server2server communication.
>
> So here's what i think:
>
> What we could measure:
> - General reachability/availability of the e-mail service
> - Response time of the remote server: time between connection establish
> and first SMTP response (220 service ready)
> - Which enhanced status codes are offered by the server?
> - Forward/Reverse DNS matching?
> - SMTP banner matching the DNS name?
>     - if not: what is it?
> - Does the remote server offer encryption (250-STARTTLS)
> - Which cipher settings are offered by the server (SSL/TLS Version, Key
> Exchange Algorithms, Encryption Algorithms, Hashing Algorithms)
>     - alternatively: Which cipher setting has been negotiated between
> probe and server?
> - Can we successfully establish a TLS connection?
> - Certificate Check: is the server-certificate valid and does it match the
> hostname?
> - Forced Encryption: MTA-STS available and 'enforced' or 'testing' or
> 'report'?
> - Forced Authentication: DANE available and check successfull?
>
>
> What we should not do:
> - send MAIL FROM: command
> - send RCPT TO: command
> - send DATA command
> - measure e-mail delivery/roundtrip time, etc.
> - Sending e-mails at all
>
> The Atlas probe should quit the connection after the data is collected. An
> actual e-mail should not be send. The target mailserver would count this
> session as "incomplete" or "aborted" which is totally fine. If someone
> would want to monitor what happens after a mailserver has successfully
> accepted a testmail, he should better use a monitoring service/solution. We
> measure the INTERnet, not what comes after (Intra) :)
>
> I don't expect any "spam" problems. Since the Atlas probes wouldn't send
> e-mails, there's nothing a spamfilter could analyze. The only thing that
> could theoretically happen, is that the probes ip addresses are flagged as
> bad by services like Spamhaus etc. and thus be listed on DNSBL/IPBL, but i
> really don't see a reason why that should happen. There wouldn't be any
> activity originating from the probes which could be classified as bad. IP
> addresses are normally only blacklisted, if they send unwanted mails like
> spam. Also: there are a lot of "check you mailserver" or "check your
> SSL/TLS" websites. The RIPE Atlas probes would behave the same way. No big
> deal.
>
> Maybe we can think of an "extended" SMTP measurement where RIPE Atlas
> sends actual e-mails, but that would require (in my opinion), that the
> person who is creating the measurement somehow provides proof, to be the
> owner of the target mailserver.
>
>
> BR,
> Simon
>
>
> On 15.09.22 12:03, Michel Stam wrote:
>
> 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://mailman.ripe.net/
>
>
>
> --
> ripe-atlas mailing list
> ripe-atlas at ripe.net
> https://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20220920/4915bc93/attachment.html>