<div dir="ltr">Granted there's likely environment/business/DNS specifics in Bradley's environment, but there seems 2 clear requirements:<br><br>Exim mail on internal servers<br><br>Mail exchange (inc TLS1.0) with ISG.<br><br>You're not going to get there by making this ISG's problem. <br>1 - It's not their problem<br>2 - There's the rest of the internet where any inbound server may attempt TLS1.0<br><br>Best way forward is likely SSL intercept on an external facing MTA, that supports TLS1.0 front end, TLS1.2 to the Exim servers on the back end.<br><br>Kind regards<br><br>Paul Wilkins<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 July 2018 at 07:24, Mark Foster <span dir="ltr"><<a href="mailto:blakjak@blakjak.net" target="_blank">blakjak@blakjak.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Hi Mark,<br>
><br>
> Exim has two types of receiving:<br>
> Authenticated Mail<br>
> Un-authenticated mail.<br>
<br>
</span>This I think we all understand.<br>
<span class=""><br>
><br>
> The difference is that when using the server for Authenticated mail, the<br>
> user must supply valid credentials in order to send mail through it. This<br>
> is what you would use for a mail client, such as Outlook. The connecting<br>
> server (unless it is an open relay) requires that you provide details in<br>
> order to send mail through it, and then that server will forward it on to<br>
> the next server.<br>
> If you do this, and that server is used for payments and the like, the<br>
> then<br>
> you must comply with PCI.<br>
<br>
</span>If you control all external interactions the server has, then sure. That<br>
would then mean you need an external mail relay that you control....<br>
<span class=""><br>
<br>
> In a cPanel environment, where mail and hosting<br>
> are on the same server, this isn't optional if we wish to tell customers<br>
> that the servers there data is on is PCI compliant.<br>
<br>
><br>
> Un-authenticated mail, however, doesn't require credentials in order to<br>
> accept mail, however, unless that server is relay, it also won't pass that<br>
> mail on. It would only accept mail from a server if the mailbox was<br>
> actually on it. So when a sending MTA sends mail to us, our server will<br>
> accept it if the email account is on that server.<br>
</span>> This *doesn't* require authentication and thus no username or password are<br>
<span class="">> supplied. As such encryption isn't required because there are no details<br>
> to<br>
> steal, unless as someone pointed out, you're silly enough to send credit<br>
> card details via email.<br>
<br>
</span>... and if you are sending or receiving email from the world-at-large<br>
(thus, unauthenticated, as you put it) then you can't mandate encryption,<br>
true.<br>
<span class=""><br>
<br>
><br>
> I appreciate everyone's help, and I do understand where you are all coming<br>
> from. But I assure you:<br>
> - Both mail and web hosting will almost always be on the same server in a<br>
> shared hosting environment.<br>
> - If the same server is both hosting websites that have credit card<br>
> details, and having a mail program such as Exim, then Exim must comply<br>
> with<br>
> PCI.<br>
> - If you do plan on having both on the same server, the server must comply<br>
> with the minimum highest spec to qualify (since there is web hosting that<br>
> requires high levels of encryption, the mail also requires it, where as if<br>
> the mail server was by itself you could use a lesser encryption.<br>
<br>
</span>... but this is where you lose it. You can't _require_ encryption if your<br>
MTA is talking to the public internet. It simply doesn't fly.<br>
<br>
I would be surprised if any shared/public hosting environment can also<br>
deliver PCI compliance as a result. Dedicated tin ensuring segregation<br>
between your systems and those of $RANDOM_STRANGER is required.<br>
Or have we forgotton meltdown/spectre?<br>
<span class=""><br>
><br>
> Please don't think I am not thankful for all your help, I just wanted to<br>
> make it clear what we've been told and what I understand from my own<br>
> research.<br>
><br>
> You are all right that in a perfect world they would be on totally<br>
> seperate<br>
> servers, but for shared hosting this is almost always not going to be the<br>
> case!<br>
<br>
<br>
</span>I don't see how you can be PCI compliant and also use shared hosting.<br>
<br>
Logically you could achieve in-the-clear support for external SMTP by<br>
having a dedicated smarthost outside of your PCI environment, that you<br>
also control of, thus you could control the support for encryption both<br>
sides. But you need to support non-compliant protocols for talking to the<br>
rest of the world, and expecting the rest of the world to conform to your<br>
expectations is unreasonable. Hell, even RFC compliance (the baseline,<br>
minimum just to be able to reliably communicate, nevermind encrypt) is<br>
iffy.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Mark.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">http://lists.ausnog.net/<wbr>mailman/listinfo/ausnog</a><br>
</div></div></blockquote></div><br></div>