On 29/12/22 07:00, Bill Cole wrote:
The first non-StackOverflow link I get is
https://blog.myhro.info/2017/01/how-fast-are-unix-domain-sockets which
is a reasonable explanation with demo code.
The simplest explanation is that TCP/IP's encapsulation of data, the
whole acknowledgment,
On 2022-12-27 at 20:06:34 UTC-0500 (Wed, 28 Dec 2022 14:06:34 +1300)
Peter
is rumored to have said:
On 24/12/22 16:38, raf wrote:
I wouldn't be too keen to do that. UNIX domain sockets
are faster than TCP.
This is the first time I've ever heard that. Can you back this up
with a link or
On Tue, Dec 27, 2022 at 06:06:50PM -0800, Dan Mahoney
wrote:
> (Speaking with my Trusted Domain Project hat on).
>
> Yes, we'll take help.
>
> I have commit access to all the Github repos, and am trying to push
> out a new release of OpenDKIM. I've been meaning to do this for
> months, but
On 28/12/22 15:06, Dan Mahoney wrote:
(Speaking with my Trusted Domain Project hat on).
Yes, we'll take help.
I have commit access to all the Github repos, and am trying to push out a new
release of OpenDKIM. I've been meaning to do this for months, but life and
family stuff has been
(Speaking with my Trusted Domain Project hat on).
Yes, we'll take help.
I have commit access to all the Github repos, and am trying to push out a new
release of OpenDKIM. I've been meaning to do this for months, but life and
family stuff has been getting in the way.
Here are the things I'd
On 23/12/22 15:19, Samer Afach wrote:
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.
I would recommend that
On 24/12/22 16:38, raf wrote:
I wouldn't be too keen to do that. UNIX domain sockets
are faster than TCP.
This is the first time I've ever heard that. Can you back this up with
a link or something, I'd like to find out more.
There's nothing dirty about them.
It's just another network
On 28/12/22 12:12, raf wrote:
Actually, it's been nearly five years since the last
commit. But dead is a strong word. I expect there's
still a lot of people using it. And there are 21 pull
requests. I've emailed the trusted domain project to
ask if it's dead, and if they'd accept help. If not, a
On Mon, Dec 26, 2022 at 11:45:52AM +0200, mailm...@ionos.gr wrote:
> On Mon, 26 Dec 2022 20:22:19 +1100 raf wrote:
>
> > That issue hasn't had any response, so maybe they aren't interested.
> > But I've just created a pull request to fix it:
> >
> >
isn't opendkim a dead project? I think their last commit was two years ago...
last time I checked, the EPEL package maintainer had to apply patches manually
because the opendkim owners had stopped working on their project.
On Mon, 26 Dec 2022 20:22:19 +1100 raf wrote:
> That issue hasn't
On Sat, Dec 24, 2022 at 08:05:12AM +0400, Samer Afach
wrote:
> Dear Raf:
>
> Thank you for the hint about UNIX sockets. I'll keep them. My only fear
> is/was that they're inappropriate to use across containers and something
> will break in the future. I guess I'll have to wait and see.
On 24/12/22 16:51, Samer Afach wrote:
(and if you're wondering
why port 25's encryption is `may` in main.cf, it's because I still don't
know how to get fetchmail to deliver emails without that... another
issue to be solved).
Fetchmail should not be delivering to port 25 as port 25 should be
On 25/12/22 02:48, Jaroslaw Rafa wrote:
The various smtpd_*_restrictions lists are applied at various stages of the
SMTP transaction. smtpd_client_restrictions are applied right at the
beginning of the connection, smtpd_helo_restrictions are applied after
HELO/EHLO, and so on.
This is not
On 24/12/22 14:22, raf wrote:
On Fri, Dec 23, 2022 at 09:51:48AM +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 because authentication is what
On Sat, Dec 24, 2022 at 07:51:42AM +0400, Samer Afach
wrote:
> Dear Raf:
>
> Thank you very much. I just tested my server with mxtoolbox, and all seems
> good. I didn't realize mxtoolbox works without MX records, thanks for that
> hint.
>
> I applied 90% of your suggestions, and some I didn't
On 12/23/22 21:29, 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 connections to my docker container with correct source information
>> (and I'm
Thank you very much!
I think we're closing to the end of this very long thread. Thanks to
everyone here. I learned tons of things from you. All the best
wishes.
Cheers,
Sam
On 24/12/2022 5:48 PM, Jaroslaw Rafa
wrote:
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 need
Am 24.12.22 um 03:28 schrieb Samer Afach:
Dear Raf:
That's actually what I do on all the bare-metal machines, but from my
understanding of how docker works, every container is made to run
exactly one service, and somehow default Linux images disable system
services. They can be re-enabled, but
Am 23.12.22 um 13:35 schrieb Samer Afach:
Dear Matthias:
I completely agree with you. My only contention is that some times
simple solutions with simple assumptions are good enough, instead of
developing a nuclear silo for something that can be tested in an hour
and then tested with public
Yep. Totally agree.
In fact, these ports (25, 465 and 587) aren't even exposed off
docker-compose. So that's guaranteed at the container level. Entering
the container can only be done through the proxy protocol and its ports
on the container-set. This will basically simplify all my future
Dear Raf:
Thank you for the hint about UNIX sockets. I'll keep them. My only fear
is/was that they're inappropriate to use across containers and something
will break in the future. I guess I'll have to wait and see.
There's actually an open issue in OpenDKIM github with this request from
Dear Raf:
Thank you very much. I just tested my server with mxtoolbox, and all
seems good. I didn't realize mxtoolbox works without MX records, thanks
for that hint.
I applied 90% of your suggestions, and some I didn't out of fear. I'm
working on understanding them more.
I have two
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:03PM +0400, Samer Afach
> > wrote:
> >
> > > About your great loud thought, my containers are versioned but there's
> > > no CI in there, and every
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 connections to my docker container with correct source information
> (and I'm seeing the correct IP addresses in the
Dear Raf:
That's actually what I do on all the bare-metal machines, but from my
understanding of how docker works, every container is made to run
exactly one service, and somehow default Linux images disable system
services. They can be re-enabled, but it's not the way it's meant to
work,
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 on support for my
>
On Fri, Dec 23, 2022 at 09:51:48AM +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 because authentication is what matters.
>
> Cheers,
> Sam
It's
On Fri, Dec 23, 2022 at 06:19:06AM +0400, Samer Afach
wrote:
> 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
>
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 to my docker container with correct source
> information (and I'm seeing the correct IP addresses in the logs of
>
I would recommend a "divide and conquer" or "separation of concerns"
approach.
On Fri, 23 Dec 2022, Samer Afach wrote:
[...]
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
I've run a similar setup for my hosting needs, while not related to Docker
containers, you may find my configuration helpful and copy some parts.
More experienced postfix'ers can comment on my mistakes :)
https://gitlab.com/noumenia/aetolos/-/blob/master/modules/el8/postfix/maincf.tpl
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
Dear Matthias:
I completely agree with you. My only contention is that some times
simple solutions with simple assumptions are good enough, instead of
developing a nuclear silo for something that can be tested in an
hour and then tested with public tools. Reminds me of
Am 23.12.22 um 03:19 schrieb Samer Afach:
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
Thank you. I will re-visit this next after the proxy problem is solved.
Btw, thank you very much for suggesting HAProxy's proxy protocol. I've
succeeded in getting it partially to work (I'm not done yet, there's
more to configure), and I can see external IP addresses in postfix and
dovecot
In my case, I reject invalid HELO names with:
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
I've run postfix like this for about 10 years now without any 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
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:
On 23/12/22 15:48, Samer Afach wrote:
Got it. So HELO/EHLO is specifically for MTAs. Thank you very much for
explaining!
It still needs to be sent for submission connections, but the hostname
does not have to be a legitimate FQDN. What is important for submission
is that it passes some
On 12/22/22 21:19, Samer Afach wrote:
There's a saying I like: Experience is the number of mistakes you've
done so far.
There is truth in that. We are each the sum of our own experiences,
including our mistakes.
--
Phil Stracchino
Babylon Communications
ph...@caerllewys.net
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
Samer Afach:
> Thank you very much, Raf. I really appreciate your empathy and all this
> help.
>
> I'm reading more and more every day. I really appreciate your support.
> The challenge is knowing what matters.
>
> And about your HELO definition, thanks for explaining it. What confuses
> me
Thank you very much, Raf. I really appreciate your empathy and all this
help.
I'm reading more and more every day. I really appreciate your support.
The challenge is knowing what matters.
And about your HELO definition, thanks for explaining it. What confuses
me is that clients usually
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
On Thu, Dec 22, 2022 at 04:47:57AM +0400, Samer Afach
wrote:
> 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
>
On 12/22/22 14:23, post...@ptld.com wrote:
On 12-22-2022 2:18 pm, mailm...@ionos.gr wrote:
sorry to have to burst your bubble, but postfix does not have documentation
at least not in the way we call documentation these days
maybe you'd call them "notes" or a "reference guide" but not real
On Thu, Dec 22, 2022 at 02:23:53PM -0500, post...@ptld.com wrote:
> > On 12-22-2022 2:18 pm, mailm...@ionos.gr wrote:
> > sorry to have to burst your bubble, but postfix does not have documentation
> >
> > at least not in the way we call documentation these days
> > maybe you'd call them "notes"
On Thu, Dec 22, 2022 at 09:18:07PM +0200, mailm...@ionos.gr wrote:
> On Thu, 22 Dec 2022 19:05:47 +0100 Matthias Andree
> wrote:
>
> > Postfix has been around for a quarter century, and it has always been
> > *the* example of good design, documentation and compatibility with
> > predecessor
On 12-22-2022 2:18 pm, mailm...@ionos.gr wrote:
sorry to have to burst your bubble, but postfix does not have documentation
at least not in the way we call documentation these days
maybe you'd call them "notes" or a "reference guide" but not real documentation
it is helpful to people who
sorry to have to burst your bubble, but postfix does not have documentation
at least not in the way we call documentation these days
maybe you'd call them "notes" or a "reference guide" but not real documentation
it is helpful to people who already know everything, but not helpful to people
Dnia 22.12.2022 o godz. 19:26:26 Samer Afach pisze:
> My plan is to completely
> cut off relaying by setting mynetworks to localhost and
> mynetworks_style to host,
BTW. You only need mynetworks_style if you don't set mynetworks explicitly.
If you do set it explicitly, mynetworks_style is just
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
Actually I would appreciate advice on how to do this on an internal environment.
google's your friend on this one
https://www.google.com/search?q=postfix+docker+testing
first link,
Samer Afach:
> 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
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
It's good that you're willing to learn, but perhaps you can do some
experiments on a "internal" environment before exposing it to the
full internet.
Wietse
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
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
If possible, could you please explain how to limit port 25 to receive only?
I use port 587 (submission) for sending mail.
thank you.
On Wed, 21 Dec 2022 11:47:16 -0500 Demi Marie Obenour
wrote:
> An alternative, which I prefer, is to require all submission to be on port
> 465 (over TLS)
On 12/21/22 06:02, Jaroslaw Rafa wrote:
> Dnia 21.12.2022 o godz. 13:21:06 Samer Afach pisze:
>> Thank you for the explanation. I will follow up on this and
>> hopefully I'll find a way to solve this problem properly without
>> obfuscation of incoming IP addresses. Seems like, worst case
>>
Dnia 21.12.2022 o godz. 13:21:06 Samer Afach pisze:
> Thank you for the explanation. I will follow up on this and
> hopefully I'll find a way to solve this problem properly without
> obfuscation of incoming IP addresses. Seems like, worst case
> scenario, I just have to disable relaying of emails
Thank you for the explanation. I will follow up on this and hopefully
I'll find a way to solve this problem properly without obfuscation of
incoming IP addresses. Seems like, worst case scenario, I just have to
disable relaying of emails altogether and that'll solve the problem, at
least until
haproxy in HTTP mode can add the necessary X-Forwarded-For header and backends
like Apache can use the mod_remoteip.so module with the RemoteIPHeader
parameter to handle the new header.
haproxy in TCP mode can't do that[1], thus haproxy has written a "proxy
protocol v2"[2] that does that,
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. I would really appreciate more details in
some of your comments?
"why not all public domains in virtual_*?"
What does that
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.30.0.1,
which, if I understand correctly, is the NAT bridge address of
docker,
Dear Peter:
Thank you. In fact, it's a coincidence I have it enabled like this
because back then, I had finished the configuration and left it like
this for some time. Unfortunately, I can't change it now because the
happen happened, and now I can't turn my email
Samer Afach skrev den 2022-12-21 05:45:
Thank you, Phil. Here we go. Here's postconf -n:
I hope this helps in better identifying how the spammer was able to
use my server to send a spam email.
```
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
On 21 Dec 2022, at 08:52, Peter wrote:
>
> On 21/12/22 20: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
On 21/12/22 20: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 because
they're like GBs in size. Just the
The most common issue when using a proxy/load balancer like haproxy, is that
the remote/foreign connections are being forwarded with the IP address of the
haproxy machine. Thus, they all appear as "local", which makes postfix think
they are "mynetworks" and as a result, postfix becomes a open
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 because
they're like GBs in size. Just the grep on that email address is like
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:
>
> Thank you, Phil. Here we go. Here's postconf -n:
>
>
> I hope this helps in better identifying how the spammer was able to use my
Thank you, Phil. Here we go. Here's postconf -n:
I hope this helps in better identifying how the spammer was able to use
my server to send a spam email.
```
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
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.
--
Phil Stracchino
Babylon Communications
ph...@caerllewys.net
p...@co.ordinate.org
Landline:
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
75 matches
Mail list logo
