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
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
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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
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? o Simple EHLO/HELO o 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? o Delay until mail received o Response time by the actual mail server o 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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
- 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@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication. a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays. On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas < ripe-atlas@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
I should add that having RIPE atlas probes in random IP blocks begin probing peoples' smtpd without successfully authenticating or transferring mail un a very high likelihood of getting those particular IPs or parent netblocks added to lists of abusive smtp traffic, which is not something that many probe hosts want to see happen. On Tue, 20 Sept 2022 at 10:22, Eric Kuhnke <eric.kuhnke@gmail.com> wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas < ripe-atlas@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
It would look very different though, there's a large difference between trying to probe for an open relay and just making a connection without any specific commands being issued.
because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
If a few connections are sufficient to trigger that, then such configurations are simply too trigger-happy. Checking the existence and availability of a domain's MX is a very common operation. Things like rspamd have such functionality built-in and I'm sure there are many others. On Tue, Sep 20, 2022 at 8:23 PM Eric Kuhnke <eric.kuhnke@gmail.com> wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas < ripe-atlas@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
I have the various postfix smtpd that I control set to be what you would call "trigger happy" and it has had absolutely **zero** impact blocking legitimate incoming smtp traffic from other domains' legitimate MX, but has had the greatly beneficial effect of cutting down on the absolutely incredible volume of virus/worm/trojan compromised hosts out on the internet that are probing for open relays or trying repeated login/password combinations, which does nothing but clutter up log files. A single connection to check that my MX answers and exists on ports 25 or other is not enough to trigger it but multiple repeated same attempts coming from the same origin IP in a span of multiple hours will. On Tue, 20 Sept 2022 at 10:29, Avamander <avamander@gmail.com> wrote:
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
It would look very different though, there's a large difference between trying to probe for an open relay and just making a connection without any specific commands being issued.
because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
If a few connections are sufficient to trigger that, then such configurations are simply too trigger-happy. Checking the existence and availability of a domain's MX is a very common operation. Things like rspamd have such functionality built-in and I'm sure there are many others.
On Tue, Sep 20, 2022 at 8:23 PM Eric Kuhnke <eric.kuhnke@gmail.com> wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas < ripe-atlas@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
but has had the greatly beneficial effect of cutting down on the absolutely incredible volume of virus/worm/trojan compromised hosts out on the internet that are probing for open relays or trying repeated login/password combinations, which does nothing but clutter up log files.
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. On Tue, Sep 20, 2022 at 8:39 PM Eric Kuhnke <eric.kuhnke@gmail.com> wrote:
I have the various postfix smtpd that I control set to be what you would call "trigger happy" and it has had absolutely **zero** impact blocking legitimate incoming smtp traffic from other domains' legitimate MX, but has had the greatly beneficial effect of cutting down on the absolutely incredible volume of virus/worm/trojan compromised hosts out on the internet that are probing for open relays or trying repeated login/password combinations, which does nothing but clutter up log files.
A single connection to check that my MX answers and exists on ports 25 or other is not enough to trigger it but multiple repeated same attempts coming from the same origin IP in a span of multiple hours will.
On Tue, 20 Sept 2022 at 10:29, Avamander <avamander@gmail.com> wrote:
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
It would look very different though, there's a large difference between trying to probe for an open relay and just making a connection without any specific commands being issued.
because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
If a few connections are sufficient to trigger that, then such configurations are simply too trigger-happy. Checking the existence and availability of a domain's MX is a very common operation. Things like rspamd have such functionality built-in and I'm sure there are many others.
On Tue, Sep 20, 2022 at 8:23 PM Eric Kuhnke <eric.kuhnke@gmail.com> wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas < ripe-atlas@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my*
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. Making arguments based upon extreme cases, assumptions, or
On 9/20/2022 10:45 AM, Avamander wrote: point of view. You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own. potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE. -- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com>
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways. Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described? Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list. On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas < ripe-atlas@ripe.net> wrote:
On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections.
What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care.
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi everyone, Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this! So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err. The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators. With this in mind, I am wondering: Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? Does the SSL measurement cover the intended use cases? Is it worth exploring STARTTLS support as an extension and what would the implications be? Have a good weekend! Best regards, Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com> wrote:
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/>-- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing. BR, Simon On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering:
* Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? * Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? * Does the SSL measurement cover the intended use cases? o Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com> wrote:
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections.
What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care.
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi everyone, multiple times, i wrote about "enhanced SMTP Status Codes". That was nonsense. What i meant were Extended SMTP commands (e.g. 250-STARTTLS). Sounds similar, but is something different: ESMTP - https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Extensions Enhanced Status Codes - https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes#Enhanced_stat... My apologies! Best regards, Simon On 23.09.22 17:08, Simon Brandt via ripe-atlas wrote:
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering:
* Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? * Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? * Does the SSL measurement cover the intended use cases? o Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com> wrote:
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections.
What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care.
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi Simon,
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610 <https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support? Regards, Michel
On 23 Sep 2022, at 17:08, ripe.net@toppas.net wrote:
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering: Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? Does the SSL measurement cover the intended use cases? Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com <mailto:avamander@gmail.com>> wrote:
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/>-- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> -- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas>
Hi Michel,
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
First, let's define the testmethod. In my opinion: - reachable 3-way TCP Handshake with target on tcp/25 successful? - responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)? - capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there. For all three checks, it's the easiest to use netcat. Reachability:
$ nc -vz mahimahi.ripe.net 25 mahimahi.ripe.net [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here. Responsiveness (wait for 220):
$ nc -C mahimahi.ripe.net 25 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200 quit 221 mahimahi.ripe.net closing connection
You might want to use the -w option here, to specify a timeout. capable of secured transmissions (send EHLO and check response):
$ nc -C mahimahi.ripe.net 25 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200 EHLO p123456.probes.atlas.ripe.net 250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net [123.123.123.123] 250-SIZE 52428800 250-8BITMIME 250-ETRN 250-PIPELINING 250-PIPE_CONNECT 250-STARTTLS 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL:
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 (output to long, i stripped it)
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type. Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement. Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running. Oh, and please make the SMTP measurement IPv6 capable :) BR, Simon On 29.09.22 11:50, Michel Stam wrote:
Hi Simon,
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how?
I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support?
Regards,
Michel
On 23 Sep 2022, at 17:08, ripe.net@toppas.net wrote:
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering:
* Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? * Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? * Does the SSL measurement cover the intended use cases? o Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com> wrote:
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections.
What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care.
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi Simon, Thanks for the rundown, that helps. The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same. I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process? As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level. With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion. As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too. Regards, Michel
On 1 Oct 2022, at 17:11, ripe.net@toppas.net wrote:
Hi Michel,
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions
First, let's define the testmethod. In my opinion:
- reachable 3-way TCP Handshake with target on tcp/25 successful?
- responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)?
- capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there.
For all three checks, it's the easiest to use netcat.
Reachability:
$ nc -vz mahimahi.ripe.net 25 mahimahi.ripe.net [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here.
Responsiveness (wait for 220):
$ nc -C mahimahi.ripe.net 25 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200 quit 221 mahimahi.ripe.net closing connection
You might want to use the -w option here, to specify a timeout.
capable of secured transmissions (send EHLO and check response):
$ nc -C mahimahi.ripe.net 25 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200 EHLO p123456.probes.atlas.ripe.net 250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net [123.123.123.123] 250-SIZE 52428800 250-8BITMIME 250-ETRN 250-PIPELINING 250-PIPE_CONNECT 250-STARTTLS 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL:
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 (output to long, i stripped it)
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type.
Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement.
Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running.
Oh, and please make the SMTP measurement IPv6 capable :)
BR, Simon
On 29.09.22 11:50, Michel Stam wrote:
Hi Simon,
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how?
I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610 <https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support?
Regards,
Michel
On 23 Sep 2022, at 17:08, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering: Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? Does the SSL measurement cover the intended use cases? Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com <mailto:avamander@gmail.com>> wrote:
Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: On 9/20/2022 10:45 AM, Avamander wrote:
Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own.
Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/>-- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> -- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas>
Hi Michael,
Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes?
If you have a timeout while waiting for the initial 220 response (service ready), the service is not available. Maybe the SMTP daemon is not running or not answering for some reason, or there's a network issue. If a timeout occurs later during the STARTTLS phase, the server is available and also the underlying network connection seems to be fine. So yes, the conclusion would be a different. But we still don't have to run two separate tests, i think.
Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
Yes. Since we do not really want to send an e-mail, we can probably use OpenSSL for everything in a single run. If you use the -debug parameter, you'll get *very* detailed output which contains all informations we want (except for response-times, i think). There might be a more elegant way to get a better-looking output from OpenSSL. But I don't know how, to be honest. I haven't read the whole man-page :)
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 -debug
Most work is probably to study the OpenSSL documentation, to find out the different error messages we have to expect, depending on the problems we might face: - TCP handshake not successfull - Server does not reply with 220 (timeout) - Server does not reply with 220 (server replies with another 4xx or 5xx code) - Server is not ESMTP capable** - Connection successfull, but the server does not offer 250-STARTTLS (not supported or suppressed because of MITM attack) - 250-STARTTLS was offered, but establishing encryption was still not successful for some reason and maybe other typical certificate problems like: - certificate invalid (self-signed) - certificate invalid (expired) - certificate invalid (broken chain) ** SMTP Encryption is optional, but it is not supported by the original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by RFC 1869. From a communication perspective, the main difference is, that the initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the client it's features. If the server does not support ESMTP, it will reply with an error. I don't know what the OpenSSL output looks like, if you try to connect to a server which does not support ESMTP. It will probably output some error message. This error should be evaluated by the Atlas SMTP measurement too. 99.9% of all mailservers nowadays should support ESMTP, but there might be some usecases... "special application blabla". It could be possible that someone would start a Atlas SMTP measurement for a non-ESMTP compliant target. That's why i am mention this. BR, Simon On 05.10.22 17:55, Michel Stam wrote:
Hi Simon,
Thanks for the rundown, that helps.
The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same.
I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level.
With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion.
As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too.
Regards,
Michel
On 1 Oct 2022, at 17:11, ripe.net@toppas.net wrote:
Hi Michel,
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
First, let's define the testmethod. In my opinion:
- reachable 3-way TCP Handshake with target on tcp/25 successful?
- responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)?
- capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there.
For all three checks, it's the easiest to use netcat.
Reachability:
$ nc -vz mahimahi.ripe.net <http://mahimahi.ripe.net> 25 mahimahi.ripe.net <http://mahimahi.ripe.net> [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here.
Responsiveness (wait for 220):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net> ESMTP Sat, 01 Oct 2022 15:25:22 +0200 quit 221 mahimahi.ripe.net <http://mahimahi.ripe.net> closing connection
You might want to use the -w option here, to specify a timeout.
capable of secured transmissions (send EHLO and check response):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net> ESMTP Sat, 01 Oct 2022 15:54:04 +0200 EHLO p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net> 250-mahimahi.ripe.net <http://250-mahimahi.ripe.net> Hello p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net> [123.123.123.123] 250-SIZE 52428800 250-8BITMIME 250-ETRN 250-PIPELINING 250-PIPE_CONNECT 250-STARTTLS 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL:
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25> (output to long, i stripped it)
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type.
Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement.
Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running.
Oh, and please make the SMTP measurement IPv6 capable :)
BR, Simon
On 29.09.22 11:50, Michel Stam wrote:
Hi Simon,
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how?
I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support?
Regards,
Michel
On 23 Sep 2022, at 17:08, ripe.net@toppas.net wrote:
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering:
* Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? * Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? * Does the SSL measurement cover the intended use cases? o Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com> wrote:
> Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right?
In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways.
Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected)
> What _objective_ risk/benefit analysis are you basing your opinions upon?
And you? What's the implication here about systems being as trigger-happy as previously described?
Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes.
> Are you a systems administrator?
Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list.
On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 9/20/2022 10:45 AM, Avamander wrote: > Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view.
You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own. > Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific.
Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE.
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com/> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hello Simon, I’ll first have a look at OpenSSL to gauge the amount of effort required. I’ll also look at the existing SSL measurement to see what that offers. That will likely provide the best path forward. Lastly, I’ll have an internal discussion on measuring SMTP/STARTTLS/etc. Ripe 85 is up next week, I’ll be attending there, so my response may be delayed somewhat. Please bear with me. Regards, Michel
On 16 Oct 2022, at 03:37, ripe.net@toppas.net wrote:
Hi Michael,
Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes?
If you have a timeout while waiting for the initial 220 response (service ready), the service is not available. Maybe the SMTP daemon is not running or not answering for some reason, or there's a network issue. If a timeout occurs later during the STARTTLS phase, the server is available and also the underlying network connection seems to be fine. So yes, the conclusion would be a different. But we still don't have to run two separate tests, i think.
Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
Yes. Since we do not really want to send an e-mail, we can probably use OpenSSL for everything in a single run. If you use the -debug parameter, you'll get *very* detailed output which contains all informations we want (except for response-times, i think). There might be a more elegant way to get a better-looking output from OpenSSL. But I don't know how, to be honest. I haven't read the whole man-page :)
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 -debug
Most work is probably to study the OpenSSL documentation, to find out the different error messages we have to expect, depending on the problems we might face:
- TCP handshake not successfull - Server does not reply with 220 (timeout) - Server does not reply with 220 (server replies with another 4xx or 5xx code) - Server is not ESMTP capable** - Connection successfull, but the server does not offer 250-STARTTLS (not supported or suppressed because of MITM attack) - 250-STARTTLS was offered, but establishing encryption was still not successful for some reason
and maybe other typical certificate problems like:
- certificate invalid (self-signed) - certificate invalid (expired) - certificate invalid (broken chain)
** SMTP Encryption is optional, but it is not supported by the original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by RFC 1869. From a communication perspective, the main difference is, that the initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the client it's features. If the server does not support ESMTP, it will reply with an error. I don't know what the OpenSSL output looks like, if you try to connect to a server which does not support ESMTP. It will probably output some error message. This error should be evaluated by the Atlas SMTP measurement too. 99.9% of all mailservers nowadays should support ESMTP, but there might be some usecases... "special application blabla". It could be possible that someone would start a Atlas SMTP measurement for a non-ESMTP compliant target. That's why i am mention this.
BR, Simon
On 05.10.22 17:55, Michel Stam wrote:
Hi Simon,
Thanks for the rundown, that helps.
The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same.
I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level.
With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion.
As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too.
Regards,
Michel
On 1 Oct 2022, at 17:11, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michel,
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions
First, let's define the testmethod. In my opinion:
- reachable 3-way TCP Handshake with target on tcp/25 successful?
- responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)?
- capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there.
For all three checks, it's the easiest to use netcat.
Reachability:
$ nc -vz mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 mahimahi.ripe.net <http://mahimahi.ripe.net/> [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here.
Responsiveness (wait for 220):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:25:22 +0200 quit 221 mahimahi.ripe.net <http://mahimahi.ripe.net/> closing connection
You might want to use the -w option here, to specify a timeout.
capable of secured transmissions (send EHLO and check response):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:54:04 +0200 EHLO p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> 250-mahimahi.ripe.net <http://250-mahimahi.ripe.net/> Hello p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> [123.123.123.123] 250-SIZE 52428800 250-8BITMIME 250-ETRN 250-PIPELINING 250-PIPE_CONNECT 250-STARTTLS 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL:
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> (output to long, i stripped it)
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type.
Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement.
Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running.
Oh, and please make the SMTP measurement IPv6 capable :)
BR, Simon
On 29.09.22 11:50, Michel Stam wrote:
Hi Simon,
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how?
I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610 <https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support?
Regards,
Michel
On 23 Sep 2022, at 17:08, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michel,
Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote:
Hi everyone,
Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this!
So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err.
The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions
The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators.
With this in mind, I am wondering: Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? Does the SSL measurement cover the intended use cases? Is it worth exploring STARTTLS support as an extension and what would the implications be?
Have a good weekend!
Best regards,
Michel
> On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com <mailto:avamander@gmail.com>> wrote: > > > Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. > > From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right? > > In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways. > > Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected) > > > What _objective_ risk/benefit analysis are you basing your opinions upon? > > And you? What's the implication here about systems being as trigger-happy as previously described? > > Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes. > > > Are you a systems administrator? > > Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list. > > On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: > On 9/20/2022 10:45 AM, Avamander wrote: >> Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. > What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view. > > You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own. >> Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. > Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. > > Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE. > > -- > Paul Theodoropoulos > anastrophe.com <https://www.anastrophe.com/>-- > ripe-atlas mailing list > ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> > https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> > -- > ripe-atlas mailing list > ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> > https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas>
Hi Simon, This seems to have gotten a bit idle since RIPE85. Let me give a bit of an update: Adding TLSv1.3 is gonna be tricky since the SSL measurement implements the first stages of the TLS handshake only. This means adding that complexity to the code, which as Niall commented to me is not trivial. Note: the SSL measurement currently does not use the OpenSSL library. Other than retrieving the certificate from the peer, no other validation happens in the current SSL measurement. This includes not validating the certificate chain, which may be a self-signed certificate. Adding STARTTLS the way OpenSSL has done it involves issuing the appropriate command after receiving certain output from the remote end, then starting the TLS handshake. This should be doable. Hope this helps, have a nice weekend! Regards, Michel
On 20 Oct 2022, at 17:30, Michel Stam <mstam@ripe.net> wrote:
Hello Simon,
I’ll first have a look at OpenSSL to gauge the amount of effort required. I’ll also look at the existing SSL measurement to see what that offers. That will likely provide the best path forward. Lastly, I’ll have an internal discussion on measuring SMTP/STARTTLS/etc.
Ripe 85 is up next week, I’ll be attending there, so my response may be delayed somewhat.
Please bear with me.
Regards,
Michel
On 16 Oct 2022, at 03:37, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michael,
Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes?
If you have a timeout while waiting for the initial 220 response (service ready), the service is not available. Maybe the SMTP daemon is not running or not answering for some reason, or there's a network issue. If a timeout occurs later during the STARTTLS phase, the server is available and also the underlying network connection seems to be fine. So yes, the conclusion would be a different. But we still don't have to run two separate tests, i think.
Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
Yes. Since we do not really want to send an e-mail, we can probably use OpenSSL for everything in a single run. If you use the -debug parameter, you'll get *very* detailed output which contains all informations we want (except for response-times, i think). There might be a more elegant way to get a better-looking output from OpenSSL. But I don't know how, to be honest. I haven't read the whole man-page :)
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> -debug
Most work is probably to study the OpenSSL documentation, to find out the different error messages we have to expect, depending on the problems we might face:
- TCP handshake not successfull - Server does not reply with 220 (timeout) - Server does not reply with 220 (server replies with another 4xx or 5xx code) - Server is not ESMTP capable** - Connection successfull, but the server does not offer 250-STARTTLS (not supported or suppressed because of MITM attack) - 250-STARTTLS was offered, but establishing encryption was still not successful for some reason
and maybe other typical certificate problems like:
- certificate invalid (self-signed) - certificate invalid (expired) - certificate invalid (broken chain)
** SMTP Encryption is optional, but it is not supported by the original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by RFC 1869. From a communication perspective, the main difference is, that the initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the client it's features. If the server does not support ESMTP, it will reply with an error. I don't know what the OpenSSL output looks like, if you try to connect to a server which does not support ESMTP. It will probably output some error message. This error should be evaluated by the Atlas SMTP measurement too. 99.9% of all mailservers nowadays should support ESMTP, but there might be some usecases... "special application blabla". It could be possible that someone would start a Atlas SMTP measurement for a non-ESMTP compliant target. That's why i am mention this.
BR, Simon
On 05.10.22 17:55, Michel Stam wrote:
Hi Simon,
Thanks for the rundown, that helps.
The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same.
I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level.
With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion.
As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too.
Regards,
Michel
On 1 Oct 2022, at 17:11, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michel,
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? The intent of the measurement would be to validate whether an SMTP server is: reachable responsive capable of secured transmissions
First, let's define the testmethod. In my opinion:
- reachable 3-way TCP Handshake with target on tcp/25 successful?
- responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)?
- capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there.
For all three checks, it's the easiest to use netcat.
Reachability:
$ nc -vz mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 mahimahi.ripe.net <http://mahimahi.ripe.net/> [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here.
Responsiveness (wait for 220):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:25:22 +0200 quit 221 mahimahi.ripe.net <http://mahimahi.ripe.net/> closing connection
You might want to use the -w option here, to specify a timeout.
capable of secured transmissions (send EHLO and check response):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:54:04 +0200 EHLO p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> 250-mahimahi.ripe.net <http://250-mahimahi.ripe.net/> Hello p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> [123.123.123.123] 250-SIZE 52428800 250-8BITMIME 250-ETRN 250-PIPELINING 250-PIPE_CONNECT 250-STARTTLS 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL:
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> (output to long, i stripped it)
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type.
Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement.
Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running.
Oh, and please make the SMTP measurement IPv6 capable :)
BR, Simon
On 29.09.22 11:50, Michel Stam wrote:
Hi Simon,
>Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how?
I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610 <https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
>Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support?
Regards,
Michel
On 23 Sep 2022, at 17:08, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michel,
>Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command).
>Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
>Does the SSL measurement cover the intended use cases? I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement.
Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
BR, Simon
On 23.09.22 16:04, Michel Stam wrote: > Hi everyone, > > Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this! > > So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err. > > The intent of the measurement would be to validate whether an SMTP server is: > reachable > responsive > capable of secured transmissions > > The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators. > > With this in mind, I am wondering: > Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? > Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? > Does the SSL measurement cover the intended use cases? > Is it worth exploring STARTTLS support as an extension and what would the implications be? > > Have a good weekend! > > Best regards, > > Michel > >> On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com <mailto:avamander@gmail.com>> wrote: >> >> > Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. >> >> From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right? >> >> In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways. >> >> Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected) >> >> > What _objective_ risk/benefit analysis are you basing your opinions upon? >> >> And you? What's the implication here about systems being as trigger-happy as previously described? >> >> Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes. >> >> > Are you a systems administrator? >> >> Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list. >> >> On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: >> On 9/20/2022 10:45 AM, Avamander wrote: >>> Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. >> What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view. >> >> You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own. >>> Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. >> Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. >> >> Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE. >> >> -- >> Paul Theodoropoulos >> anastrophe.com <https://www.anastrophe.com/>-- >> ripe-atlas mailing list >> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> > >
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi Michel, Thanks for your feedback!
Note: the SSL measurement currently does not use the OpenSSL library. Is that a reason to not use OpenSSL for SMTP measurements? Are there any reasons to not use OpenSSL?
BR, Simon On 11.11.22 13:57, Michel Stam wrote:
Hi Simon,
This seems to have gotten a bit idle since RIPE85. Let me give a bit of an update:
* Adding TLSv1.3 is gonna be tricky since the SSL measurement implements the first stages of the TLS handshake only. This means adding that complexity to the code, which as Niall commented to me is not trivial. Note: the SSL measurement currently does not use the OpenSSL library. * Other than retrieving the certificate from the peer, no other validation happens in the current SSL measurement. This includes not validating the certificate chain, which may be a self-signed certificate. * Adding STARTTLS the way OpenSSL has done it involves issuing the appropriate command after receiving certain output from the remote end, then starting the TLS handshake. This should be doable.
Hope this helps, have a nice weekend!
Regards,
Michel
On 20 Oct 2022, at 17:30, Michel Stam <mstam@ripe.net> wrote:
Hello Simon,
I’ll first have a look at OpenSSL to gauge the amount of effort required. I’ll also look at the existing SSL measurement to see what that offers. That will likely provide the best path forward. Lastly, I’ll have an internal discussion on measuring SMTP/STARTTLS/etc.
Ripe 85 is up next week, I’ll be attending there, so my response may be delayed somewhat.
Please bear with me.
Regards,
Michel
On 16 Oct 2022, at 03:37, ripe.net@toppas.net wrote:
Hi Michael,
Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes?
If you have a timeout while waiting for the initial 220 response (service ready), the service is not available. Maybe the SMTP daemon is not running or not answering for some reason, or there's a network issue. If a timeout occurs later during the STARTTLS phase, the server is available and also the underlying network connection seems to be fine. So yes, the conclusion would be a different. But we still don't have to run two separate tests, i think.
Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
Yes. Since we do not really want to send an e-mail, we can probably use OpenSSL for everything in a single run. If you use the -debug parameter, you'll get *very* detailed output which contains all informations we want (except for response-times, i think). There might be a more elegant way to get a better-looking output from OpenSSL. But I don't know how, to be honest. I haven't read the whole man-page :)
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> -debug
Most work is probably to study the OpenSSL documentation, to find out the different error messages we have to expect, depending on the problems we might face:
- TCP handshake not successfull - Server does not reply with 220 (timeout) - Server does not reply with 220 (server replies with another 4xx or 5xx code) - Server is not ESMTP capable** - Connection successfull, but the server does not offer 250-STARTTLS (not supported or suppressed because of MITM attack) - 250-STARTTLS was offered, but establishing encryption was still not successful for some reason
and maybe other typical certificate problems like:
- certificate invalid (self-signed) - certificate invalid (expired) - certificate invalid (broken chain)
** SMTP Encryption is optional, but it is not supported by the original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by RFC 1869. From a communication perspective, the main difference is, that the initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the client it's features. If the server does not support ESMTP, it will reply with an error. I don't know what the OpenSSL output looks like, if you try to connect to a server which does not support ESMTP. It will probably output some error message. This error should be evaluated by the Atlas SMTP measurement too. 99.9% of all mailservers nowadays should support ESMTP, but there might be some usecases... "special application blabla". It could be possible that someone would start a Atlas SMTP measurement for a non-ESMTP compliant target. That's why i am mention this.
BR, Simon
On 05.10.22 17:55, Michel Stam wrote:
Hi Simon,
Thanks for the rundown, that helps.
The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same.
I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level.
With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion.
As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too.
Regards,
Michel
On 1 Oct 2022, at 17:11, ripe.net@toppas.net wrote:
Hi Michel,
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? The intent of the measurement would be to validate whether an SMTP server is:
* reachable * responsive * capable of secured transmissions
First, let's define the testmethod. In my opinion:
- reachable 3-way TCP Handshake with target on tcp/25 successful?
- responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)?
- capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there.
For all three checks, it's the easiest to use netcat.
Reachability:
$ nc -vz mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 mahimahi.ripe.net <http://mahimahi.ripe.net/> [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here.
Responsiveness (wait for 220):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:25:22 +0200 quit 221 mahimahi.ripe.net <http://mahimahi.ripe.net/> closing connection
You might want to use the -w option here, to specify a timeout.
capable of secured transmissions (send EHLO and check response):
$ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:54:04 +0200 EHLO p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> 250-mahimahi.ripe.net <http://250-mahimahi.ripe.net/> Hello p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> [123.123.123.123] 250-SIZE 52428800 250-8BITMIME 250-ETRN 250-PIPELINING 250-PIPE_CONNECT 250-STARTTLS 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL:
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> (output to long, i stripped it)
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type.
Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement.
Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running.
Oh, and please make the SMTP measurement IPv6 capable :)
BR, Simon
On 29.09.22 11:50, Michel Stam wrote:
Hi Simon,
> >Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how?
I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability.
> >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement. > > Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing.
You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support?
Regards,
Michel
> On 23 Sep 2022, at 17:08, ripe.net@toppas.net wrote: > > Hi Michel, > > >Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? > First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command). > > >Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp). > > >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL _does_ support SMTP and STARTTLS. So you could probably modify the existing SSL measurement. > > Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing. > > BR, > Simon > > > > On 23.09.22 16:04, Michel Stam wrote: >> Hi everyone, >> >> Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this! >> >> So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err. >> >> The intent of the measurement would be to validate whether an SMTP server is: >> >> * reachable >> * responsive >> * capable of secured transmissions >> >> >> The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators. >> >> With this in mind, I am wondering: >> >> * Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? >> * Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? >> * Does the SSL measurement cover the intended use cases? >> o Is it worth exploring STARTTLS support as an extension and what would the implications be? >> >> >> Have a good weekend! >> >> Best regards, >> >> Michel >> >>> On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com> wrote: >>> >>> > Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. >>> >>> From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right? >>> >>> In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways. >>> >>> Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected) >>> >>> > What _objective_ risk/benefit analysis are you basing your opinions upon? >>> >>> And you? What's the implication here about systems being as trigger-happy as previously described? >>> >>> Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes. >>> >>> > Are you a systems administrator? >>> >>> Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list. >>> >>> On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net> wrote: >>> >>> On 9/20/2022 10:45 AM, Avamander wrote: >>>> Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. >>> What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view. >>> >>> You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own. >>>> Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. >>> Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. >>> >>> Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE. >>> >>> -- >>> Paul Theodoropoulos >>> anastrophe.com <https://www.anastrophe.com/> >>> -- >>> ripe-atlas mailing list >>> ripe-atlas@ripe.net >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >>> >>> -- >>> ripe-atlas mailing list >>> ripe-atlas@ripe.net >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> >
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi Simon, This development happened before my joining RIPE NCC, but my guess is that this is historical. Having the OpenSSL library requires more flash and memory, something which the version 1 and 2 probes did not really have. This doesn’t mean that this needs to be the same going forward, just that adding OpenSSL will take more time, and providing we find a good use for that. Cheers, Michel
On 11 Nov 2022, at 14:16, ripe.net@toppas.net wrote:
Hi Michel,
Thanks for your feedback!
Note: the SSL measurement currently does not use the OpenSSL library. Is that a reason to not use OpenSSL for SMTP measurements? Are there any reasons to not use OpenSSL?
BR, Simon
On 11.11.22 13:57, Michel Stam wrote:
Hi Simon,
This seems to have gotten a bit idle since RIPE85. Let me give a bit of an update:
Adding TLSv1.3 is gonna be tricky since the SSL measurement implements the first stages of the TLS handshake only. This means adding that complexity to the code, which as Niall commented to me is not trivial. Note: the SSL measurement currently does not use the OpenSSL library. Other than retrieving the certificate from the peer, no other validation happens in the current SSL measurement. This includes not validating the certificate chain, which may be a self-signed certificate. Adding STARTTLS the way OpenSSL has done it involves issuing the appropriate command after receiving certain output from the remote end, then starting the TLS handshake. This should be doable.
Hope this helps, have a nice weekend!
Regards,
Michel
On 20 Oct 2022, at 17:30, Michel Stam <mstam@ripe.net <mailto:mstam@ripe.net>> wrote:
Hello Simon,
I’ll first have a look at OpenSSL to gauge the amount of effort required. I’ll also look at the existing SSL measurement to see what that offers. That will likely provide the best path forward. Lastly, I’ll have an internal discussion on measuring SMTP/STARTTLS/etc.
Ripe 85 is up next week, I’ll be attending there, so my response may be delayed somewhat.
Please bear with me.
Regards,
Michel
On 16 Oct 2022, at 03:37, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michael,
Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes?
If you have a timeout while waiting for the initial 220 response (service ready), the service is not available. Maybe the SMTP daemon is not running or not answering for some reason, or there's a network issue. If a timeout occurs later during the STARTTLS phase, the server is available and also the underlying network connection seems to be fine. So yes, the conclusion would be a different. But we still don't have to run two separate tests, i think.
Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
Yes. Since we do not really want to send an e-mail, we can probably use OpenSSL for everything in a single run. If you use the -debug parameter, you'll get *very* detailed output which contains all informations we want (except for response-times, i think). There might be a more elegant way to get a better-looking output from OpenSSL. But I don't know how, to be honest. I haven't read the whole man-page :)
$ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> -debug
Most work is probably to study the OpenSSL documentation, to find out the different error messages we have to expect, depending on the problems we might face:
- TCP handshake not successfull - Server does not reply with 220 (timeout) - Server does not reply with 220 (server replies with another 4xx or 5xx code) - Server is not ESMTP capable** - Connection successfull, but the server does not offer 250-STARTTLS (not supported or suppressed because of MITM attack) - 250-STARTTLS was offered, but establishing encryption was still not successful for some reason
and maybe other typical certificate problems like:
- certificate invalid (self-signed) - certificate invalid (expired) - certificate invalid (broken chain)
** SMTP Encryption is optional, but it is not supported by the original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by RFC 1869. From a communication perspective, the main difference is, that the initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the client it's features. If the server does not support ESMTP, it will reply with an error. I don't know what the OpenSSL output looks like, if you try to connect to a server which does not support ESMTP. It will probably output some error message. This error should be evaluated by the Atlas SMTP measurement too. 99.9% of all mailservers nowadays should support ESMTP, but there might be some usecases... "special application blabla". It could be possible that someone would start a Atlas SMTP measurement for a non-ESMTP compliant target. That's why i am mention this.
BR, Simon
On 05.10.22 17:55, Michel Stam wrote:
Hi Simon,
Thanks for the rundown, that helps.
The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same.
I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process?
As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level.
With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion.
As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too.
Regards,
Michel
On 1 Oct 2022, at 17:11, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote:
Hi Michel,
> That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? > The intent of the measurement would be to validate whether an SMTP server is: > reachable > responsive > capable of secured transmissions
First, let's define the testmethod. In my opinion:
- reachable 3-way TCP Handshake with target on tcp/25 successful?
- responsive when establishing and SMTP connection, does the smtp-server signalize readiness of the service (SMTP 220)?
- capable of secured transmissions when sending an EHLO, the server will tell us his features. 250-STARTTLS should be there.
For all three checks, it's the easiest to use netcat.
Reachability: > $ nc -vz mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 > mahimahi.ripe.net <http://mahimahi.ripe.net/> [193.0.19.114] 25 (smtp) open
Note, that we have not measured the response time. That's why you wanted to use TCP Traceroute, right? We can also go with TCP Traceroute here.
Responsiveness (wait for 220): > $ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 > 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:25:22 +0200 > quit > 221 mahimahi.ripe.net <http://mahimahi.ripe.net/> closing connection
You might want to use the -w option here, to specify a timeout.
capable of secured transmissions (send EHLO and check response): > $ nc -C mahimahi.ripe.net <http://mahimahi.ripe.net/> 25 > 220 mahimahi.ripe.net <http://mahimahi.ripe.net/> ESMTP Sat, 01 Oct 2022 15:54:04 +0200 > EHLO p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> > 250-mahimahi.ripe.net <http://250-mahimahi.ripe.net/> Hello p123456.probes.atlas.ripe.net <http://p123456.probes.atlas.ripe.net/> [123.123.123.123] > 250-SIZE 52428800 > 250-8BITMIME > 250-ETRN > 250-PIPELINING > 250-PIPE_CONNECT > 250-STARTTLS > 250 HELP
To check the Certificate validity and if encryption is indeed successful, we can use OpenSSL: > $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> (output to long, i stripped it)
> You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp (ftps, not sftp).
As i said before, there are additional e-mail security features that we could check. There's MTA-STS, where we would have to perform a combination of HTTP and SSL check. Also, there is DANE, where we would perform a combination of DNS and SSL check (including DNSSEC). But DANE can be used for other protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate check type.
Last but no least, we should check for Forward-confirmed reverse DNS and matching SMTP banner, which is a combination of DNS and netcat check. This would be a reasonable part of every smtp measurement.
Please note, that the creator of the measurement should either specify the exact mailserver FQDN, or the target Domain. In the latter case, an MX record lookup has to be performed before the measurement starts, not while the measurement is running. Otherwise it could cause credit consumption trouble, if suddenly multiple mx records are added the domain, while the measurement is running.
Oh, and please make the SMTP measurement IPv6 capable :)
BR, Simon
On 29.09.22 11:50, Michel Stam wrote: > Hi Simon, > >> >Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? >> I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp). > > That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? > > I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610 <https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability. > >> >Does the SSL measurement cover the intended use cases? >> I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement. >> >> Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing. > > > You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. > I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support? > > Regards, > > Michel > > >> On 23 Sep 2022, at 17:08, ripe.net@toppas.net <mailto:ripe.net@toppas.net> wrote: >> >> Hi Michel, >> >> >Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? >> First of all, we are monitoring the service of a specific target. Same as http or ntp measurements, just another protocol. But we also monitor the Internet. Using an SMTP measurement, we could identify censorship or discover Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS command). >> >> >Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? >> I would say no. Using TCP Traceroute, you can may check for reachability/responsiveness of the host, but not the actual service (smtp). >> >> >Does the SSL measurement cover the intended use cases? >> I would say no. Correct me if am am wrong. Usually (for example HTTPS or LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was successfull. For SMTP, that doesn't work. That's because regular SMTP communication starts first, so both sides can negotiate if SSL/TLS encryption is possible (via Enhanced SMTP Status Codes). However, as far as i know, OpenSSL does support SMTP and STARTTLS. So you could probably modify the existing SSL measurement. >> >> Keep in mind that there's also MTA-STS and DANE, which are really enhancing SMTPs security. A dedicated SMTP measurement would be a good thing. >> >> BR, >> Simon >> >> >> >> On 23.09.22 16:04, Michel Stam wrote: >>> Hi everyone, >>> >>> Great that this request sparked a good discussion on the merits of a measurement, as well as its potential impact on servers around the world. Good to see this! >>> >>> So I’m going to do a quick recap here, hoping that I capture the intent and the concerns correctly. Please correct me if I err. >>> >>> The intent of the measurement would be to validate whether an SMTP server is: >>> reachable >>> responsive >>> capable of secured transmissions >>> >>> The concern is that such a check would trigger one of a variety of anti spam measures in place around the world, and/or cause undue traffic to SMTP server operators. >>> >>> With this in mind, I am wondering: >>> Are we monitoring the Internet or monitoring a service using the proposed SMTP measurement? >>> Can we achieve the first 2 items of this measurement by doing a TCP traceroute on port 25? >>> Does the SSL measurement cover the intended use cases? >>> Is it worth exploring STARTTLS support as an extension and what would the implications be? >>> >>> Have a good weekend! >>> >>> Best regards, >>> >>> Michel >>> >>>> On 21 Sep 2022, at 00:11, Avamander <avamander@gmail.com <mailto:avamander@gmail.com>> wrote: >>>> >>>> > Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. >>>> >>>> From the perspective of your previous sentences that's kinda humorous. "To avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view." Because sure, a few (hypothetical RIPE probe) connections are exactly that, zero exaggeration, right? >>>> >>>> In the end such fail2ban-fueled (or similar) behaviour I initially addressed, is exactly a non-scientific extreme-case assumption-based approach. There are better and even more standard ways. >>>> >>>> Crutch solutions out in the wild shouldn't be a showstopper for measuring the ecosystem. (That is already quite neglected) >>>> >>>> > What _objective_ risk/benefit analysis are you basing your opinions upon? >>>> >>>> And you? What's the implication here about systems being as trigger-happy as previously described? >>>> >>>> Because sure, at some point rate limits make total sense, but certainly not at the point where it would ban any potential RIPE probes. >>>> >>>> > Are you a systems administrator? >>>> >>>> Let's not get into such measuring contests, even if it is the RIPE Atlas mailing list. >>>> >>>> On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: >>>> On 9/20/2022 10:45 AM, Avamander wrote: >>>>> Great to hear it works for you, but the potential unfortunate collateral from such a blanket action is not really RIPE Atlas' problem. There are more fine-grained methods against bruteforce attempts and open relay probes, than triggering on a few connections. >>>> What _objective_ risk/benefit analysis are you basing your opinions upon? Are you a systems administrator? My responsibility is to avoid unnecessary costs incurred from disruption of service, excessive traffic, annoyances using up *my* time, and countless other reasonable rationale from *my* point of view. >>>> >>>> You suggest that it is "not really RIPE Atlas' problem". That's very true. And it is not really my problem if I bounce yoinky, pointless probes of my server, and ruthlessly block them from contacting my server ever again. My server, my choice, my wallet, nobody's business but my own. >>>>> Some webmasters ban IP's for simply visiting a domain, I know one that even dispatches an email to your ISP's abuse@ address upon visit. Should RIPE Atlas probes then not probe any HTTP servers? The answer is obviously no, they shouldn't care. >>>> Making arguments based upon extreme cases, assumptions, or potential-for-collateral-damage is not scientific. "I know one that even [...]" Anecdotal evidence isn't scientific. >>>> >>>> Note, I run a probe myself. I don't block any RIPE Atlas traffic on my separate servers hosted on AWS, Oracle, and GCE. >>>> >>>> -- >>>> Paul Theodoropoulos >>>> anastrophe.com <https://www.anastrophe.com/>-- >>>> ripe-atlas mailing list >>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> >>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> >>>> -- >>>> ripe-atlas mailing list >>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> >>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> >>> >>> >> >
-- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas>
because common configurations of fail2ban [...] absolutely will ban your IP [...] after multiple connection attempts and no successful mail transfer
I would consider this a heavy misconfiguration. Please explain to me what incomplete SMTP connections have in common with spammers, virus/worm/trojan compromised hosts or open relay searching bots. Those bad senders WANT to _successfully_ deliver mails to you. They will never abort the connection on purpose. For example: bots which search for open relays ALWAYS try to send mails with a foreign sender and recipient domain. That's how you discover them. But as suggested, the Atlas SMTP check should not send E-Mails at all, not even send MAIL FROM: or RCPT TO: command. You will not achieve mitigation of inbound spam/malware/phishing traffic by blocking IP addresses of hosts from incomplete SMTP sessions. Usually, incomplete SMTP sessions indicate a misconfiguration. For example: forced TLS enabled, but expired certificate or no matching cipher suites. But that is no reason to ban the senders! I think you have to go a little bit deeper in your logs and consider why mailtransfer was not successfull, before blocking ip addresses. I am no expert for fail2ban, but as far is i know, i searches for failed login attempts. So that affects mostly authenticated SMTP connections (client E-Mail submission on tcp/465 or tcp/587), right? This should not concern us here. I work with enterprise mailgateway solutions for years (mostly Proofpoint), but i have never encountered what you describe. Reject or throttle because of too much connections at the same time? Yes. Reject or throttle because of too much non-existing recipient adresses? Yes. Reject or throttle because both sender and recipient domain is foreign? Yes. Reject or throttle because of bad reputation (known spammer or TOR exit node ip address)? Yes. But not because of incomplete SMTP connections. From my point of view, I can not confirm that this common behaviour. BR, Simon On 20.09.22 19:22, Eric Kuhnke wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas <ripe-atlas@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? o Simple EHLO/HELO o 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? o Delay until mail received o Response time by the actual mail server o 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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
No legitimate incoming SMTP traffic comes from IPs that abort connections to my mx prior to attempting to deliver mail, so however I choose to declutter my log files has absolutely zero real world impact in deliverablity of legitimate incoming mail. Nor does it hurt anybody at the other end whatever the connect-and-do-nothing software at the other side. On Tue, Sep 20, 2022, 12:37 PM <ripe.net@toppas.net> wrote:
because common configurations of fail2ban [...] absolutely will ban your IP [...] after multiple connection attempts and no successful mail transfer
I would consider this a heavy misconfiguration. Please explain to me what incomplete SMTP connections have in common with spammers, virus/worm/trojan compromised hosts or open relay searching bots. Those bad senders WANT to *successfully* deliver mails to you. They will never abort the connection on purpose. For example: bots which search for open relays ALWAYS try to send mails with a foreign sender and recipient domain. That's how you discover them. But as suggested, the Atlas SMTP check should not send E-Mails at all, not even send MAIL FROM: or RCPT TO: command.
You will not achieve mitigation of inbound spam/malware/phishing traffic by blocking IP addresses of hosts from incomplete SMTP sessions. Usually, incomplete SMTP sessions indicate a misconfiguration. For example: forced TLS enabled, but expired certificate or no matching cipher suites. But that is no reason to ban the senders! I think you have to go a little bit deeper in your logs and consider why mailtransfer was not successfull, before blocking ip addresses.
I am no expert for fail2ban, but as far is i know, i searches for failed login attempts. So that affects mostly authenticated SMTP connections (client E-Mail submission on tcp/465 or tcp/587), right? This should not concern us here.
I work with enterprise mailgateway solutions for years (mostly Proofpoint), but i have never encountered what you describe.
Reject or throttle because of too much connections at the same time? Yes. Reject or throttle because of too much non-existing recipient adresses? Yes. Reject or throttle because both sender and recipient domain is foreign? Yes. Reject or throttle because of bad reputation (known spammer or TOR exit node ip address)? Yes.
But not because of incomplete SMTP connections. From my point of view, I can not confirm that this common behaviour.
BR, Simon
On 20.09.22 19:22, Eric Kuhnke wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas < ripe-atlas@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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
There's literally no danger for you (recipient), if the sender terminates the connection before the an e-mail has been successfully transmitted. No need to ban the ip address. You would only risk to block a legitimate ip address which might have trouble sending e-mails to you. If you want to do this because you don't want to see such connections in you logs that's fine. But i do not share your opinion, that this is a common configuration. However, we have digressed from the topic. BR, Simon On 20.09.22 21:47, Eric Kuhnke wrote:
No legitimate incoming SMTP traffic comes from IPs that abort connections to my mx prior to attempting to deliver mail, so however I choose to declutter my log files has absolutely zero real world impact in deliverablity of legitimate incoming mail. Nor does it hurt anybody at the other end whatever the connect-and-do-nothing software at the other side.
On Tue, Sep 20, 2022, 12:37 PM <ripe.net@toppas.net> wrote:
>> because common configurations of fail2ban [...] absolutely will ban your IP [...] after multiple connection attempts and no successful mail transfer
I would consider this a heavy misconfiguration. Please explain to me what incomplete SMTP connections have in common with spammers, virus/worm/trojan compromised hosts or open relay searching bots. Those bad senders WANT to _successfully_ deliver mails to you. They will never abort the connection on purpose. For example: bots which search for open relays ALWAYS try to send mails with a foreign sender and recipient domain. That's how you discover them. But as suggested, the Atlas SMTP check should not send E-Mails at all, not even send MAIL FROM: or RCPT TO: command.
You will not achieve mitigation of inbound spam/malware/phishing traffic by blocking IP addresses of hosts from incomplete SMTP sessions. Usually, incomplete SMTP sessions indicate a misconfiguration. For example: forced TLS enabled, but expired certificate or no matching cipher suites. But that is no reason to ban the senders! I think you have to go a little bit deeper in your logs and consider why mailtransfer was not successfull, before blocking ip addresses.
I am no expert for fail2ban, but as far is i know, i searches for failed login attempts. So that affects mostly authenticated SMTP connections (client E-Mail submission on tcp/465 or tcp/587), right? This should not concern us here.
I work with enterprise mailgateway solutions for years (mostly Proofpoint), but i have never encountered what you describe.
Reject or throttle because of too much connections at the same time? Yes. Reject or throttle because of too much non-existing recipient adresses? Yes. Reject or throttle because both sender and recipient domain is foreign? Yes. Reject or throttle because of bad reputation (known spammer or TOR exit node ip address)? Yes.
But not because of incomplete SMTP connections. From my point of view, I can not confirm that this common behaviour.
BR, Simon
On 20.09.22 19:22, Eric Kuhnke wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas <ripe-atlas@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? o Simple EHLO/HELO o 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? o Delay until mail received o Response time by the actual mail server o 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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
(Coffee is to blame for the length of this) It's worth bearing in mind that the internet is a large place, populated with large, larger, very large, enormous, gargantuan....and extremely tiny, extremely budget-limited, personal, private servers that cannot afford the charges for non-productive traffic. The internet is not just Proofpoint or Sendgrid or "Meta" or etc.; it is also vast numbers of people in second- and third-world countries trying to engage with the world and learn, and who literally can't afford excess, unproductive bytes hitting their server that will cost them money. I used to be the sole systems admin for a site that sent variously anywhere from a million to eleven million emails per day (yes, all opt-in, legitimate email for our customers, just for the record), so I've spent a fair bit of my life going zen analyzing logs for hours and hours. I'm now retired and run my own personal mail and webservers, on one t3.micro on AWS that costs me a few hundred bucks over the course of three years commitment, and a free server on each of GCE and Oracle, the former of which also costs me a few bucks a month in traffic charges. I'm not poor, and can afford these charges. So I don't block any RIPE Atlas traffic (to my knowledge), as I don't have (or need) extreme restrictions on incoming traffic. I do occasionally sift through my logs to find new pointless traffic that's 'annoying' my systems, and may set something up to block them. I run a couple of stratum one timeservers from home, part of the ntp pool project, and regularly have to block nitwits (some of them ISP's themselves) who hammer my little primary RPI with multiple connections per minute. I have to block those malefactors simply because they interfere with legitimate traffic. There are countless ways that 'internet hooligans' and/or the clueless can cause harm with useless traffic. There are potentially millions of individuals trying to contribute for the benefit of the internet who don't have the lack of concern for costs that I have. Thus why there are so many Raspberry Pi probes out there in non-first-world nations; and likely no small number of tiny personal mailservers running on a shared 56k line, the cost of which is _just_ bearable to maintain. There is no one-size-fits-all on the internet. It is common - and very human - to view the internet and world through our own perspective. There are other perspectives. Okay, that's my coffee-fueled bloviation for the day, and with that, I acknowledge the significant digression involved...so I'll shut up now. Cheers! On 9/20/2022 13:04 PM, Simon Brandt via ripe-atlas wrote:
There's literally no danger for you (recipient), if the sender terminates the connection before the an e-mail has been successfully transmitted. No need to ban the ip address. You would only risk to block a legitimate ip address which might have trouble sending e-mails to you. If you want to do this because you don't want to see such connections in you logs that's fine. But i do not share your opinion, that this is a common configuration.
However, we have digressed from the topic.
BR, Simon
On 20.09.22 21:47, Eric Kuhnke wrote:
No legitimate incoming SMTP traffic comes from IPs that abort connections to my mx prior to attempting to deliver mail, so however I choose to declutter my log files has absolutely zero real world impact in deliverablity of legitimate incoming mail. Nor does it hurt anybody at the other end whatever the connect-and-do-nothing software at the other side.
On Tue, Sep 20, 2022, 12:37 PM <ripe.net@toppas.net> wrote:
>> because common configurations of fail2ban [...] absolutely will ban your IP [...] after multiple connection attempts and no successful mail transfer
I would consider this a heavy misconfiguration. Please explain to me what incomplete SMTP connections have in common with spammers, virus/worm/trojan compromised hosts or open relay searching bots. Those bad senders WANT to _successfully_ deliver mails to you. They will never abort the connection on purpose. For example: bots which search for open relays ALWAYS try to send mails with a foreign sender and recipient domain. That's how you discover them. But as suggested, the Atlas SMTP check should not send E-Mails at all, not even send MAIL FROM: or RCPT TO: command.
You will not achieve mitigation of inbound spam/malware/phishing traffic by blocking IP addresses of hosts from incomplete SMTP sessions. Usually, incomplete SMTP sessions indicate a misconfiguration. For example: forced TLS enabled, but expired certificate or no matching cipher suites. But that is no reason to ban the senders! I think you have to go a little bit deeper in your logs and consider why mailtransfer was not successfull, before blocking ip addresses.
I am no expert for fail2ban, but as far is i know, i searches for failed login attempts. So that affects mostly authenticated SMTP connections (client E-Mail submission on tcp/465 or tcp/587), right? This should not concern us here.
I work with enterprise mailgateway solutions for years (mostly Proofpoint), but i have never encountered what you describe.
Reject or throttle because of too much connections at the same time? Yes. Reject or throttle because of too much non-existing recipient adresses? Yes. Reject or throttle because both sender and recipient domain is foreign? Yes. Reject or throttle because of bad reputation (known spammer or TOR exit node ip address)? Yes.
But not because of incomplete SMTP connections. From my point of view, I can not confirm that this common behaviour.
BR, Simon
On 20.09.22 19:22, Eric Kuhnke wrote:
I would discourage anyone from relying upon the data from "probing" the MX and SMTP daemons for a domain name no matter what port they run on, because common configurations of fail2ban used with postfix and others absolutely will ban your IP at the host operating system level (iptables or other) after multiple connection attempts and no successful mail transfer or authentication.
a probe of smtpd will look not much different from the many things out there on the internet already maliciously probing smtpd trying to find open relays.
On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas <ripe-atlas@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? o Simple EHLO/HELO o 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? o Delay until mail received o Response time by the actual mail server o 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@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@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- Paul Theodoropoulos anastrophe.com <https://www.anastrophe.com>
participants (5)
-
Avamander -
Eric Kuhnke -
Michel Stam -
Paul Theodoropoulos -
ripe.net＠toppas.net