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
Demi Marie Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 12/20/22 06:13, Wietse Venema wrote:
> > Fourhundred Thecat:
> >> Hello,
> >>
> >> I had this in my logs:
> >>
> >>postfix/master: warning: process /usr/lib/postfix/sbin/scache pid
> >> 1215
On 12/20/22 06:13, Wietse Venema wrote:
> Fourhundred Thecat:
>> Hello,
>>
>> I had this in my logs:
>>
>>postfix/master: warning: process /usr/lib/postfix/sbin/scache pid
>> 1215 killed by signal 11
>>postfix/master: warning: /usr/lib/postfix/sbin/scache: bad command
>> startup --
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
14 matches
Mail list logo
