[atlas] RIPE Atlas SMTP Measurement
- Previous message (by thread): [atlas] RIPE Atlas SMTP Measurement
- Next message (by thread): [atlas] RIPE Atlas SMTP Measurement
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Avamander
avamander at gmail.com
Tue Sep 20 19:15:33 CEST 2022
> - Forced Encryption: MTA-STS available and 'enforced' or 'testing' or 'report'? TLS-RPT would also be a good addition to MTA-STS and DANE checks. > - Forced Authentication: DANE available and check successful? Just mentioning it, but when DANE is measured then DNSSEC should be as well. > What we could measure: In theory things like TCP Fast Open would be nice to measure as well. On Tue, Sep 20, 2022 at 7:23 PM Simon Brandt via ripe-atlas < ripe-atlas at ripe.net> wrote: > Hi Michel, > > Currently, HTTP and SSL are separate measurements. But for SMTP it will > probably not work this way... Encryption is not mandatory for SMTP and thus > negotiated between client and server every time on port 25. Ports 465 and > 587 are used for Client Email Submission. You could run some measurements > for these ports as well, but for the beginning, i would focus on > server2server communication. > > So here's what i think: > > What we could measure: > - General reachability/availability of the e-mail service > - Response time of the remote server: time between connection establish > and first SMTP response (220 service ready) > - Which enhanced status codes are offered by the server? > - Forward/Reverse DNS matching? > - SMTP banner matching the DNS name? > - if not: what is it? > - Does the remote server offer encryption (250-STARTTLS) > - Which cipher settings are offered by the server (SSL/TLS Version, Key > Exchange Algorithms, Encryption Algorithms, Hashing Algorithms) > - alternatively: Which cipher setting has been negotiated between > probe and server? > - Can we successfully establish a TLS connection? > - Certificate Check: is the server-certificate valid and does it match the > hostname? > - Forced Encryption: MTA-STS available and 'enforced' or 'testing' or > 'report'? > - Forced Authentication: DANE available and check successfull? > > > What we should not do: > - send MAIL FROM: command > - send RCPT TO: command > - send DATA command > - measure e-mail delivery/roundtrip time, etc. > - Sending e-mails at all > > The Atlas probe should quit the connection after the data is collected. An > actual e-mail should not be send. The target mailserver would count this > session as "incomplete" or "aborted" which is totally fine. If someone > would want to monitor what happens after a mailserver has successfully > accepted a testmail, he should better use a monitoring service/solution. We > measure the INTERnet, not what comes after (Intra) :) > > I don't expect any "spam" problems. Since the Atlas probes wouldn't send > e-mails, there's nothing a spamfilter could analyze. The only thing that > could theoretically happen, is that the probes ip addresses are flagged as > bad by services like Spamhaus etc. and thus be listed on DNSBL/IPBL, but i > really don't see a reason why that should happen. There wouldn't be any > activity originating from the probes which could be classified as bad. IP > addresses are normally only blacklisted, if they send unwanted mails like > spam. Also: there are a lot of "check you mailserver" or "check your > SSL/TLS" websites. The RIPE Atlas probes would behave the same way. No big > deal. > > Maybe we can think of an "extended" SMTP measurement where RIPE Atlas > sends actual e-mails, but that would require (in my opinion), that the > person who is creating the measurement somehow provides proof, to be the > owner of the target mailserver. > > > BR, > Simon > > > On 15.09.22 12:03, Michel Stam wrote: > > Hello Simon, > > Thank you for the suggestion. > > I have a couple of questions to get a better idea: > > - Can you maybe describe what a SMTP measurement would look like? > - Simple EHLO/HELO > - Sending an email to a designated address (which would then > validate that the SMTP server is capable of relaying etc.) > - How would DNSBL or other spam prevention techniques fit into this? > - What would the result be? > - Delay until mail received > - Response time by the actual mail server > - Using the Received: headers to get a “traceroute” like result. > - What about the more uncommon ports such as 565 (SMTP+SSL/TLS) or 587 > (mail submission port). > - How can we prevent this implementation from having RIPE Atlas be > identified as a spam bot network? > > > Best regards, > > Michel > > On 3 Sep 2022, at 14:48, Simon Brandt via ripe-atlas <ripe-atlas at ripe.net> > wrote: > > Hello, > > i'd like to start a discussion about having a RIPE Atlas SMTP measurements. > First of all: yes, i know there's a big obstacle for such a measurement > type. A lot of probes are deployed using enduser internet-connections like > dsl, cable, etc. with dynamic/eyeball IP addresses. Those IP spaces are > usually blocked by SMTP servers as approach to reduce spam mails. For > Example: by using blocklists like Spamhaus PBL. So a proper SMTP > measurement wouldn't work. > > BUT we could have an easy way for RIPE Atlas probe hosters to signalize, > that their probe is eligible for SMTP measurements: > > Step 1: enable "Simple DNS Entry" > Step 2: create a matching reverse DNS record for the probes IP address > > Everybody who is able so configure a reverse DNS record for his probes IP > address, is most likely using a non-dynamic/non-home ip address space e.g. > a datacenter or office network. If an ISP provides the option for his > customers to configure a reverse DNS record, it's most likely a > "business-customer" subnet which can be used to run mailservers. After Step > 1+2 are done, the RIPE Atlas platform would easily be able to verify if > forward-confirmed reverse DNS is successful, and if so, automatically > enable that probe for SMTP measurements. Alternatively: probe hosters > choose their own Forward-confirmed reverse DNS name and submit it on the > RIPE Atlas website. > > Also: if we would have STMP measurements, forward-confirmed reverse DNS > should be mandatory for anchors, or is it already? > > Why should we have SMTP measurements? > > Besides general reachability checks, we could also evaluate SMTP response > codes. But the most important thing for me is this: the SMTP protocol is > old. Very old. From a security point of view, it's absolutely outdated. > Most security features have been added years after the initial RfC. Thus, > those security features are optional. Mandatory SMTP encryption is not > provided by the SMTP RfC. So both sides have to signalize, that they are > capable of encryption using the STARTTLS command. An attacker > (man-in-the-middle) can perform a downgrade attack by suppressing the > STARTTLS command. So both sides are forced to fallback and communicate > unencrypted. RIPE Atlas would be a really good tool to identify such > attacks, by monitor/measure the (enhanced) status codes of a target. > > But there's more! > I see a two-sided model here. Either use the RIPE Atlas SMTP measurements > to monitor/measure your own mailserver by alot of other RIPE probes out > there, OR probe hosters could run SMTP measurements originating from their > own probe to find out, if their own IP address is currently blocked by > other mailservers. > > > What do you think? > > > BR, > Simon > -- > ripe-atlas mailing list > ripe-atlas at ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > > > > -- > ripe-atlas mailing list > ripe-atlas at ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20220920/4915bc93/attachment.html>
- Previous message (by thread): [atlas] RIPE Atlas SMTP Measurement
- Next message (by thread): [atlas] RIPE Atlas SMTP Measurement
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]