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 incomin
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 k
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 -- thrott
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 ag
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) a
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
>> scenari
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 a
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, but
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 m
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, i
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 s
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
biff
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 share
14 matches
Mail list logo
