Re, Le 22/02/2020 à 21:25, Søren Aurehøj a écrit : >> Den 22. feb. 2020 kl. 20.01 skrev Archange <archa...@activis.me >> <mailto:archa...@activis.me>>: >> Le 22/02/2020 à 19:55, Søren Aurehøj a écrit : >>> Hi Misc >>> >>> I am using OpenSMTPD 6.6.0 on OpenBSD 6.6 stable >>> >>> Currently I’m using the tls-require option in order to get mandatory >>> TLS on outgoing mail, but with that follows the normal time-out >>> values regarding bounce intervals. >>> Because of greylisting, I’m not sure that adjusting these time-out >>> values is the best way around this problem. >> >> I’m not sure how greylisting is involved here. Can you elaborate? >> > I was lowering bounce warn-interval as an interim measure to speed up > non-deliveries due to missing TLS - that could collide with > greylisting intervals if lowered the warn-interval to much.
OK I see, and indeed that’s not a good idea to lower this interval to a too low value. >>> I have tested the scenario with a mailserver which is unable to use >>> TLS, by sending mail to mailnesia.com <http://mailnesia.com/>. >>> This gives the expected result - "mta event=error reason=TLS >>> required but not supported by remote host” in the maillog. >>> >>> My mailserver recognizes when it is unable to continue the >>> delivery due to a configuration setting on my mailserver. >>> But instead of bouncing the mail immediately, it is queued anyway >>> for later delivery. >>> >>> Is it possible to enforce outgoing mail to always use TLS - and >>> bounce more or less immediately, >>> if the sending mailserver registers that the receiving mailserver is >>> unable to meet our requirements regarding TLS? >> >> I don’t know, but it seems a bad idea: what about a transient >> failure? The mail systems expect you to keep retrying to deliver for >> some time. They are several reasons that could lead to your email >> being temporarily rejected because your MTA was unable to establish a >> correct TLS session, but still succeed some time after that. >> > That’s a risk I am ready to accept - sending with TLS is mandatory > according to our data protection officer, citing GDPR and the > sensitivity of the emails sent. I agree that sending with TLS should be mandatory (though that’s not enough without a good TLS configuration and DANE+DNSSEC according to me…). But that’s not the point. I’m not saying you should still send if TLS is not available. I’m saying that it could be only temporarily unavailable on the receiving end (like say for some hours or one day), and be back right after. Because for instance someone on the other side misconfigured their service after an update, and they will fix it the next day after realizing it. ;) So they are two possibilities in my opinion: 1. Either your care a lot about delivering delay, and you should lower the bounce interval —but to something that let greylisting work— in order to fail early in ALL cases (and not just TLS being unavailable). 2. Or you don’t care that much, and you should leave things untouched: if TLS really isn’t available on the receiving end, your delivery will fail after the bounce interval, but if ever TLS becomes available (again) on the receiving end in the mean time, you will successfully deliver (and over TLS of course). Regards, Archange
