[AusNOG] Issues receiving from TPG Mail servers.

[Paul Wilkins]

Granted there's likely environment/business/DNS specifics in Bradley's
environment, but there seems 2 clear requirements:

Exim mail on internal servers

Mail exchange (inc TLS1.0) with ISG.

You're not going to get there by making this ISG's problem.
1 - It's not their problem
2 - There's the rest of the internet where any inbound server may attempt
TLS1.0

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.

Kind regards

Paul Wilkins


On 24 July 2018 at 07:24, Mark Foster <blakjak at blakjak.net> wrote:

> > Hi Mark,
> >
> > Exim has two types of receiving:
> > Authenticated Mail
> > Un-authenticated mail.
>
> This I think we all understand.
>
> >
> > The difference is that when using the server for Authenticated mail, the
> > user must supply valid credentials in order to send mail through it. This
> > is what you would use for a mail client, such as Outlook. The connecting
> > server (unless it is an open relay) requires that you provide details in
> > order to send mail through it, and then that server will forward it on to
> > the next server.
> > If you do this, and that server is used for payments and the like, the
> > then
> > you must comply with PCI.
>
> If you control all external interactions the server has, then sure. That
> would then mean you need an external mail relay that you control....
>
>
> > In a cPanel environment, where mail and hosting
> > are on the same server, this isn't optional if we wish to tell customers
> > that the servers there data is on is PCI compliant.
>
> >
> > Un-authenticated mail, however, doesn't require credentials in order to
> > accept mail, however, unless that server is relay, it also won't pass
> that
> > mail on. It would only accept mail from a server if the mailbox was
> > actually on it. So when a sending MTA sends mail to us, our server will
> > accept it if the email account is on that server.
> > This *doesn't* require authentication and thus no username or password
> are
> > supplied. As such encryption isn't required because there are no details
> > to
> > steal, unless as someone pointed out, you're silly enough to send credit
> > card details via email.
>
> ... and if you are sending or receiving email from the world-at-large
> (thus, unauthenticated, as you put it) then you can't mandate encryption,
> true.
>
>
> >
> > I appreciate everyone's help, and I do understand where you are all
> coming
> > from. But I assure you:
> > - Both mail and web hosting will almost always be on the same server in a
> > shared hosting environment.
> > - If the same server is both hosting websites that have credit card
> > details, and having a mail program such as Exim, then Exim must comply
> > with
> > PCI.
> > - If you do plan on having both on the same server, the server must
> comply
> > with the minimum highest spec to qualify (since there is web hosting that
> > requires high levels of encryption, the mail also requires it, where as
> if
> > the mail server was by itself you could use a lesser encryption.
>
> ... but this is where you lose it. You can't _require_ encryption if your
> MTA is talking to the public internet. It simply doesn't fly.
>
> I would be surprised if any shared/public hosting environment can also
> deliver PCI compliance as a result. Dedicated tin ensuring segregation
> between your systems and those of $RANDOM_STRANGER is required.
> Or have we forgotton meltdown/spectre?
>
> >
> > Please don't think I am not thankful for all your help, I just wanted to
> > make it clear what we've been told and what I understand from my own
> > research.
> >
> > You are all right that in a perfect world they would be on totally
> > seperate
> > servers, but for shared hosting this is almost always not going to be the
> > case!
>
>
> I don't see how you can be PCI compliant and also use shared hosting.
>
> Logically you could achieve in-the-clear support for external SMTP by
> having a dedicated smarthost outside of your PCI environment, that you
> also control of, thus you could control the support for encryption both
> sides. But you need to support non-compliant protocols for talking to the
> rest of the world, and expecting the rest of the world to conform to your
> expectations is unreasonable. Hell, even RFC compliance (the baseline,
> minimum just to be able to reliably communicate, nevermind encrypt) is
> iffy.
>
>
> Mark.
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20180724/91836595/attachment.html>