Dear Matthias,

I think there's a misunderstanding here. The server is already shutdown. I thought you meant that I should shutdown the server permanently and move on with my life because I'm incapable of running a server, which seems to have been the context (I'll explain next why that's obvious). But please allow me to elaborate that usually the cost of that is extremely high, and I'm willing to pay it. Luckily I'm on vacation now so I'm just spending my own time to do this. I've spent so far no less than 100 hours on this fiasco. Zero regrets.

Btw, the relays happened because I actively changed mynetworks_style to subnet, forgetting and not checking that all incoming connections will come from the gateway of docker subnet. Still under research to identify how that works.

There have been suggestions on the email list that I could start the containers locally to do the experiments. Maybe I'm missing something, but isn't the primary problem that I need to identify connection sources with the PROXY protocol? How will I do that if I can't produce remote connections? There's no way to guarantee that unless I do that remotely. That's why I'll have to turn on the server before it's fully tested... because the ultimate test will be communicating with the server remotely and getting the desired results.

And again, let's not forget that disabling email relaying is the primary solutions (as many have pointed out already). So none of this is that bad. I think we have a fair assessment of the risk, all things considered.

Now about learning, people have shared interesting opinions and I read the email chain (readers, please read them first before commenting on what I'm saying) and I agree with many of them and disagree with others, and yes, it's not as simple as it seems. There's no point in anyone's life where one said "now I'm educated, let's run an email server". Not really. Even people graduating university don't know what they're doing after having spent years grinding information. The reason for this phenomenon is complex and has to do with human nature and upbringing, but it's what it's. You either inherit a system that works and you're taught the caveats in it and how to test it and what to look for, or you start from somewhere (some configuration online?) and learn as you go. The Linux ecosystem in general is based on testing things manually, which is why configuration mistakes happen all the time, and which is why there are tons of online tools to test the obvious vulnerabilities (OSS, etc, most of which use public interfaces, because no one knows everything). Email is very sensitive, granted, but I'm sorry, you're asking for the impossible. You're asking for people to "learn first", well, I have news for you... THIS is what learning looks like :-)

There's a saying I like: Experience is the number of mistakes you've done so far.

You're asking for "safe and possibly reviewed configuration", I'm sorry, but that doesn't really mean anything in practice unless you have an army of experts to support you. It's just words that sound nice. Even with all the wonderful people here and all the help I got, when I shared my configuration, I barely got commentary on my configuration, and when I asked further I got your email asking me to "learn". It didn't take more than one email admitting my ignorance to start getting requests to shutdown my server (which I had already done), instead of providing more information. That's not odd, it's just human nature, which leads to where we are right now. Please don't misunderstand what I'm saying, I'm in NO WAY entitled to anything, and I'm already very grateful for everything I learned here, but please be realistic in what you're asking for. I'm trying to make the best of the current situation.

Thank you all, lovely people. I wanna emphasize that I'm learning from every email I'm reading here.

Best regards,
Sam




On 22/12/2022 10:05 PM, Matthias Andree wrote:
Am 22.12.22 um 01:47 schrieb Samer Afach:
Thank you, Matthias, for your opinion.

Ironically, the proxy part in this whole story is not only the simple
part that I fully understand, but also the part that's very easily
testable with my current knowledge and understanding of networking.
It's easy to look into the IP addresses of incoming connections and
cross-check them with the senders. It's easy to see whether a PROXY
protocol with HAProxy works. I'm looking into that setup as we speak.
All that is easy. I'm actually surprised you're using that part as
argument to why I should shutdown my server.

Thanks to the wonderful people in this email list, now I understand my
mistake with that regard. I learned a lot.

If I were you, I'd focus on my lack of understanding of the email
protocol. Now that, is a part that I still cannot fully understand,
embarrassingly so. I still don't know what ehlo means, except that
it's the first message. I don't know why it matters what address we
put after it. That does make me look like an idiot, doesn't it? :-)

I fully understand your opinion and why you'd want me to shutdown my
server. But if I were you, I'd try to encourage people to learn more
or explain more to them. This whole incident reminds me of people who
fall for scams and pay scammers money. They can be ashamed of it and
never talk about it, or try to learn how to not fall for it again.
Just my humble opinion.

Sam,

your proxy is what underminded Postfix's relay guards, by your own
assessments and descriptions - because it was the proxy that connected
with its own IP address to Postfix's smtpd, and $mynetworks subnets are
usually permitted to relay.
So while you may have understood how the proxy itself works, you have
not identified the implications for operating a mail server proofed
against unintended relaying.
Reading Postfix's documentation thoroughly would have brought you across
XCLIENT (and I was saying application-level or -layer proxy because it
talks SMTP not TCP), and you would have asked specific questions.

And why does your server have to go online BEFORE you have learned the
ropes? I did not ask you to shut down permanently (that should have been
clear, but you are getting defensive so I may have stepped on your toes
after you stepped on the public's), but implied to first learn and then
go online with a safe and possibly reviewed configuration. The public
constantly has to put up with people who experiment in public and ask
for help *after* accidents. Not sure where such dangerous approaches are
taught.

Postfix has been around for a quarter century, and it has always been
*the* example of good design, documentation and compatibility with
predecessor versions.

I would really appreciate if people in general learned BEFORE putting
systems live.

Cheers,
Matthias


Cheers,
Sam



On 21/12/2022 10:21 PM, Matthias Andree wrote:
Am 21.12.22 um 09:45 schrieb Samer Afach:
Thank you for these hints, Benny. I wanna point out that I'm, in no
way, an expert in any of this, and my configuration is based on online
research and some copy/paste.


Then with all due respect, please shut down your mail server and do not
start it again until you have fully understood what your services are
doing, and need to do instead in order to be operated securely. We don't
need more public accidents.

Postfix has ways to let application-level proxies convey actual client
IP (XCLIENT). You will want those in the logs, and not your proxy's IP
address. Sooner or later you will find it necessary to at least
temporarily block offending subnets.

If your proxy can't do that, or you don't know how, or you don't know
how to do that with containers, perhaps use postscreen instead and run
your Postfix on a bridged networked container of VM instead.

I do not believe you (personally - no offense, but after your statement
above) are currently fit for setting up and operating such a complex
setup as you are using with several proxy and NAT layers and all that.
Containers may seem like a good idea, but if they dispose of crucial
information such as the client address, then revise your setup
THOROUGHLY.

Sorry to be blunt without asking, but we've all had our shares of eating
unsolicited e-mail.

Thank you.

S

Reply via email to