-3

I've managed to find a lot of closely related information, but not an answer truly addressing my question.

I am expanding on my homelab server, and have decided to use a small publicly hosted server as a simple proxy. My homelab will operate Mailcow and I want to use only port 587 for secure SMTP, but I want to make sure my setup doesn't appear broken, off, or somehow anomalous to say - a deliverability scan or blacklist/greylist crawler or email client/etc.

So I will have port 25 explicitly banned by IPtables to prevent resource drain from fraudulent access attempts, but I don't want to look like the server does not have SMTP available - but rather that secure SMTP is required on port 587.

Is there a way to indicate that to a requesting client/scanner/MTS server that SMTP requires TLS on port 587, should this be handled with a redirect like a webserver from 80->443? I don't want to, say, deliver a response with my webserver or anything like that, I'm hoping there's somehow some iptables config or something that naturally integrates at layer 2 or 3 for this so I can leave that port closed in IPtables, but not appear just down on SMTP.

I'm not sure that even makes sense or is necessary but I want external access to be normal through public DNS without any possible shadow banning or reputation management lists seeing me as suspicious and possibly prompting some (mostly web based) clients to flag or worse drop traffic from my domain/IP, or make a client think it can't make SMTP submissions.

Am I nuts or is there a way to do this/is this a sensible concern? Thanks in advance.

EDIT: I forgot to mention I am using HAproxy as my host's edge - so I can just redirect 25->587 and be done if that make's the most sense, I was just hoping to leave 25 blocked off entirely as botnets and DDOS/etc will then be transferred as well...

MJHd
  • 107
  • 6
  • Thanks for the downvotes without explanation - very helpful... – MJHd May 03 '23 at 23:53
  • 1
    Have you read [rfc5321](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4.2), specifically the place where it says the SMTP port is 25? Have you [read rfc3297](https://datatracker.ietf.org/doc/html/rfc3207#section-4) specifically the part warning you not to break interoperability, at least not in the general case? – anx May 04 '23 at 00:34
  • No, but honestly I don't see how that would affect my question - are you saying that port 587 for secure SMTP is not valid? The link you sent references IANA's spec but they also spec 587 as mail submission here: https://www.rfc-editor.org/rfc/rfc6409.html – MJHd May 04 '23 at 01:20
  • That appears to be a valid MTS mail submission port according to IANA and is commonly used(industry standard) for submitting SMTP traffic requiring SSL/TLS encryption - a quick google search shows dozens of well reputed sources denoting this as a standard port for secure SMTP submission... – MJHd May 04 '23 at 01:49
  • On your second source - it's denoting behavior for STARTTLS, it defines a CLIENT request, so that would require the client looking for secure connection, as the server I can't rely on that - I am trying to exclude traffic LOOKING for insecure access, while not accidentally signalling that SMTP in general is not available - since it IS on 583 – MJHd May 04 '23 at 01:50
  • 1
    `MTS` what is this? – Jasen May 05 '23 at 02:59
  • @MJHd 587 is standard for mail **submission**. This is for **clients**, for MUAs like Thunderbird. When they originate mail, this is called "submission". All inter-server mail transfers go through 25. Nobody will use another port, because it is a standard, compiled into all servers around the world and there is no way to tell all the world you are wishing to use another port for mail deliveries towards you. MX uses 25. – Nikita Kipriyanov May 05 '23 at 04:06
  • This is completely independed to where you require TLS. And, by the way, you should **never require STARTTLS on port 25**. You will lose mail. If you do this at work you will be fired, because mail will be lost solely because of your irresponsibility. – Nikita Kipriyanov May 05 '23 at 04:08
  • Sorry MTA - not MTS – MJHd May 05 '23 at 04:30
  • @NikitaKipriyanov - so, if I give someone SMTP credentials, and they log in to Gmail and enter the SMTP server info - will the submission count as from a client - or from a server? – MJHd May 05 '23 at 04:33
  • I don't understand the question. Where in Gmail you can enter other server's credentials and server info? You only may only enter destination email address which has a domain part (after @). If mail for this domain is not served by the Gmail itself, the destination server will be determined by doing DNS MX lookup against the domain, and eventually some Gmail's server will attempt to deliver mail to the resolved address via SMTP over port 25. Also, Gmail *will* issue STARTTLS (on port 25), if the target server announces the support. – Nikita Kipriyanov May 05 '23 at 11:55

1 Answers1

4

Is there a way to indicate that to a requesting client/scanner/MTS server that SMTP requires TLS on port 587

Assuming MTS is a typographic error and you meant MTA.

587 is not secure SMTP, 587 is Submission. Submission is for user agents, not for transfer agents, the only way to secure mail transfer is STARTTLS on port 25. port 465 is SubmissionS (submission with implicit tls) - but again can't be used for transfer.

You can require starttls using DANE or MTA-STS (you should probably deploy both) DANE is going to need DNSSEC at your DNS provider and MTA-STS a HTTPS server.

So no you can't close port 25 and still act as a MX for a domain.

As for user agents they usually probe a number of popular ports (465,587,25 etc) until they see something they like during setup, so closing 25 will not hurt them significantly.

If you're getting lots of garbage traffic on port 25 consider using something like fail2ban

I am using HAproxy as my host's edge

That's going to make firewall rules harder to write, but I think there's a netfilter plugin of some sort that makes haproxy transparent - so possibly that could work with fail2ban,.

Jasen
  • 826
  • 6
  • 12
  • Yes - it was supposed to say MTA – MJHd May 05 '23 at 04:34
  • So, I think I've gotten a bit mixed up in the terms - I'm a dev/programmer so I don't know this stuff well - but I think the main takaway is that I can't leave 25 closed and have normal MTA/SMTP functionality - should I redirect 25 -> 465 for starttls? – MJHd May 05 '23 at 05:30
  • Also for my own sanity - the mail client will submit to 465 using SMTP protocol right? So it's still SMTP traffic, just that different ports are defined for different purposes yeah? – MJHd May 05 '23 at 05:33
  • 1
    465 (smtps) and 587 (submission) are redundant. You can have both or only 587 (more compartible) or only 465. 587 starts raw and announces STARTTLS support (if configured), then client is able to run this command and then it switches to TLS secured connection. In general you can disable authentication until STARTTLS is performed, so this doesn't reduce security. 465 starts already in TLS, it can't support non-TLS-enabled clients inherently. And, none of them can replace a functionality of 25, which stands alone and is required to accept mail from other servers, also it can support STARTTLS too – Nikita Kipriyanov May 05 '23 at 18:12