:
Dnia 24.12.2022 o godz. 07:51:42 Samer Afach pisze:
1. I see you're telling me to remove smtpd_client_restrictions (for
both 465 and 587?) and only keep smtpd_recipient_restrictions. Can
you please elaborate on the difference? I thought clients connecting
to the server are what we
Actually I would appreciate advice on how to do this on an internal
environment. Is there a way to do this, like tools? The challenge is
that I need an external email client to check IP addresses through the
proxy, do the TLS communication, etc. My plan is to completely cut off
relaying by
I see. Thank you for the explanation. So the right way to state this is
that HELO/EHLO requires a valid FQDN/hostname only for MTAs, and for
MUAs it's just ignored because authentication is what matters.
Cheers,
Sam
On 23/12/2022 9:34 AM, Peter wrote:
On 23/12/22 15:48, Samer Afach wrote
Got it. So HELO/EHLO is specifically for MTAs. Thank you very
much for explaining!
All the best,
Sam
On 23/12/2022 6:37 AM, Wietse Venema
wrote:
Samer Afach:
Thank you very much, Raf. I really appreciate your
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
, but when we say "client",
that sounds like any client, and not all clients share having a global
hostname/FQDN.
Thanks for explaining EHLO, I think I understand it now.
Cheers,
Sam
On 23/12/2022 5:01 AM, raf wrote:
On Thu, Dec 22, 2022 at 04:47:57AM +0400, Samer Afach
wrote:
problems. I don't
expect others to use such restrictions but it works for me.
On Fri, 23 Dec 2022 09:51:48 +0400 Samer Afach wrote:
I see. Thank you for the explanation. So the right way to state this is
that HELO/EHLO requires a valid FQDN/hostname only for MTAs, and for
MUAs it's just ignored
call it
unusual, but it's the optimum solution for the problem I have,
portability.
If you have any further scrutiny for my setup in mind, please go
ahead. I appreciate your input.
Cheers,
Sam
On 23/12/2022 1:51 PM, Matthias Andree
wrote:
Dear postfix experts:
I think I'm getting to the end of this problem. I was able to use
haproxy to relay connections to my docker container with correct source
information (and I'm seeing the correct IP addresses in the logs of
postfix/dovecot). I would appreciate it if you could take a look
On 24/12/2022 5:30 AM, raf wrote:
On Fri, Dec 23, 2022 at 04:35:03PM +0400, Samer Afach
wrote:
About your great loud thought, my containers are versioned but there's
no CI in there, and every launch for them recreates them. They're all
based on either Debian or Ubuntu (depending
moves
to new servers and will minimize the chance of any mistakes happening.
Cheers,
Sam
On 23/12/2022 9:47 PM, Demi Marie Obenour wrote:
On 12/23/22 09:58, Samer Afach wrote:
Dear postfix experts:
I think I'm getting to the end of this problem. I was able to use
haproxy to relay connections
.
Thanks a lot for looking into my configuration. That's very generous of you.
Cheers,
Sam
On 24/12/2022 6:29 AM, raf wrote:
On Fri, Dec 23, 2022 at 06:58:17PM +0400, Samer Afach
wrote:
Dear postfix experts:
I think I'm getting to the end of this problem. I was able to use haproxy to
relay
months ago: https://github.com/trusteddomainproject/OpenDKIM/issues/153
Hopefully someone will find the time to do it.
Cheers,
Sam
On 24/12/2022 7:38 AM, raf wrote:
On Sat, Dec 24, 2022 at 06:28:29AM +0400, Samer Afach
wrote:
On 24/12/2022 5:30 AM, raf wrote:
On Fri, Dec 23, 2022 at 04:35
virtual_uid_maps = static:5000
```
Best regards,
Sam
On 21/12/2022 8:35 AM, Phil Stracchino wrote:
On 12/20/22 21:39, Samer Afach wrote:
I could share postconf too, but it's huge and I don't want to make this
a huge burden unless necessary.
'postconf -n' is much more concise. Try it.
Dear postfix experts:
So, apparently I failed at configuring my server properly after moving
my whole email services to docker, and some spambot eventually was able
to send a "claim prize" email through my server. The reason I think it's
relay is that the account, from which the email was
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
:35, Samer Afach wrote:
Dear Pat:
Thank you for throwing this idea, because I really thought it
wasn't possible to retrieve docker logs without setup, but I dug
and found the logs. I have them all. Unfortunately, I can't
share them all
additional information or additional logs, please let me
know.
Best regards,
Sam
On 21/12/2022 10:31 AM, Patrick Proniewski wrote:
Hello,
Do you have the logs (postfix and maybe dovecot) showing the spammer
interaction with the server?
pat
On 21 Dec 2022, at 05:45, Samer Afach wrote
they do, then that is the problem.
On Wed, 21 Dec 2022 11:35:13 +0400 Samer Afach wrote:
Dear Pat:
Thank you for throwing this idea, because I really thought it wasn't
possible to retrieve docker logs without setup, but I dug and found the
logs. I have them all. Unfortunate
tls_session_cache_database =
btree:${data_directory}/smtp_scache"?
Will apply the recommendations that I understood. Thank you very much.
Cheers,
Sam
On 21/12/2022 12:12 PM, Benny Pedersen wrote:
Samer Afach skrev den 2022-12-21 05:45:
Thank you, Phil. Here we go. Here's postconf -n:
x-and-load-balancers/
On Wed, 21 Dec 2022 12:39:30 +0400 Samer Afach wrote:
Thank you. You and Pat actually may be onto something. I grepped the whole logs for "connect from",
and all the "connect from" and "disconnect from" statements seem to be coming from
172.
21 matches
Mail list logo
