Gino Ferguson via Postfix-users:
> Hi All,
>
> We are relaying emails to Microsoft SMTP servers with basic
> authentication but Microsoft is sunsetting this form of auth and
> they push everyone to oAuth.
>
> I'm curious what do you use for oAuth? I've found a gi
Hi All,
We are relaying emails to Microsoft SMTP servers with basic authentication but
Microsoft is sunsetting this form of auth and they push everyone to oAuth.
I'm curious what do you use for oAuth? I've found a github project and I'm
about to give it a try very soon but
Thanks Victor (& everyone else who chimed in).
I'm going to sit down with management on Monday and see if I can explain
all this to them so as to get a consensus decision on what they'd like
to do.
Cheers
Dulux-Oz
On 26/1/25 12:50, Viktor Dukhovni via Postfix-users wrote:
On Sun, Jan 26, 2
On Sun, Jan 26, 2025 at 12:11:21AM +1100, duluxoz via Postfix-users wrote:
> ... so no, there's no separate "mail-hub" / "edge-mail-gateway" set-up
> - its all the one box with the haproxy box sitting in-front.
Understood, that makes the consolidated edge/hub/submission/... server
somewhat more c
On 2025-01-25 14:46, Tomasz Pala via Postfix-users wrote:
> As the internal and external are separate accounts (if I understand
> correctly) this still seems to be the job for submission stage.
Since you care about header addresses and want to prevent users from accidental
use of them for Internet
On 2025-01-25 13:27, duluxoz via Postfix-users wrote:
> alerts/reports (to the sys-ops) and by users for internal organisation
> communication. Those users that require external email access also have
> an email account in an externally-facing domain, and usually use the
> appropriate domain when s
On 2025-01-25 10:30, Viktor Dukhovni via Postfix-users wrote:
>
> This does not do what you think it does, because the classification of
> addresses into address classes happens in the trivial-rewrite service,
> not in smtpd(8). Best to not jump-in and reply with "I would try", if
> you don't act
Well, the organisation is only small (-ish) - call it SME-sized - so
there's only a single email-stack server (postfix, dovecot, clamav,
etc), a separate webserver (hosting both internally and
externally-facing websites, including roundcube hosting all the email
domains), a haproxy "gateway/bas
So, the internal email domain is used by both servers sending in email
alerts/reports (to the sys-ops) and by users for internal organisation
communication. Those users that require external email access also have
an email account in an externally-facing domain, and usually use the
appropriate
On Sat, Jan 25, 2025 at 11:27:13PM +1100, duluxoz via Postfix-users wrote:
> So, the internal email domain is used by both servers sending in email
> alerts/reports (to the sys-ops) and by users for internal organisation
> communication. Those users that require external email access also have an
On Sat, Jan 25, 2025 at 10:06:36AM +0100, Tomasz Pala via Postfix-users wrote:
> > Emails are permitted to be sent between all three domains.
>
> I would try:
>
> master.cf:
> smtpd [...]
> -o virtual_mailbox_domains=example.com,example.org
This does not do what you think it does, because
If that doesn't work - different approach, using only restrictions, e.g.
smtpd_recipient_restrictions = permit_mynetworks [...]
reject_unauth_destination
check_recipient_access hash:/etc/$config_directory/my_domains
my_domains:
example.internal521 Unauthorized
- do no acc
On 2025-01-25 09:53, duluxoz via Postfix-users wrote:
>
> Emails are permitted to be sent between all three domains.
I would try:
master.cf:
smtpd [...]
-o virtual_mailbox_domains=example.com,example.org
main.cf:
virtual_mailbox_domains=example.com,example.org,example.internal
- this w
Hi All,
I'm not sure how to go about doing this (what I'm about to describe
below) so I'm hoping someone here can point me in the right direction.
My postfix box hosts multiple email domains, including one which is
fully internal to our network (ie does not receive nor send emails out
onto t
On Sat, Nov 02, 2024 at 06:53:56PM -0400, Wietse Venema via Postfix-users wrote:
> example.com relay:[inside-gateway.example.com]:port
>
> The port can be numeric (465, 587) or symbolic (smtps, submissions,
> submission).
With port 465 (a.k.a. "smtps"), don't forget to use a dedicated clon
Kenneth Porter via Postfix-users:
> How would I configure a firewall server to forward to an internal server
> over an authenticated submission connection? The examples I'm reading
> seem to show an unauthenticated connection to port 25. I expect I'd use
> a custom internal user for this.
>
> R
How would I configure a firewall server to forward to an internal server
over an authenticated submission connection? The examples I'm reading
seem to show an unauthenticated connection to port 25. I expect I'd use
a custom internal user for this.
Reference:
https://www.postfix.org/STANDARD_C
o add the Microsoft365 sending IP CIDR Ranges to the
> smtpd_recipient_restrictions by using "check_client_access
> cidr:/etc/postfix/microsoft365_cidr"
> The postfix server now is accepting the mail, but when relaying it to the
> internet the reciving server says: " 550 5.7.26 Message rejec
dr:/etc/postfix/microsoft365_cidr"
The postfix server now is accepting the mail, but when relaying it to the
internet the reciving server says: " 550 5.7.26 Message rejected per DMARC
policy by contonso.com"
I suppose this is either because the the originating server was not listed
in the
Dnia 31.08.2023 o godz. 02:57:57 Viktor Dukhovni via Postfix-users pisze:
> > In my case, I have a catch-all virtual domain that is configured in
> > virtual_alias_maps as follows:
> >
> > example.org anything
> > @example.org username
>
> As already explained, catch-alls are a bad idea, requirin
Thank you, Viktor!
After adding "virtual_alias_domains=domain2.tld" it works as expected.
Sincerely,
Danil Smirnov
On Thu, Aug 31, 2023 at 9:58 AM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
> On Thu, Aug 31, 2023 at 07:53:03AM +0200, Jaroslaw Rafa via Postfix-users
>
On Thu, Aug 31, 2023 at 07:53:03AM +0200, Jaroslaw Rafa via Postfix-users wrote:
> Did you also add the entry for "domain2.tld" itself (without "@" at the
> beginning) to virtual_alias_maps, so that Postfix knows that it should
> handle mail for this domain?
That's a deprecated backward's compati
Dnia 30.08.2023 o godz. 22:30:02 Danil Smirnov via Postfix-users pisze:
>
> I tried this first - I've added "@domain2.tld @domain1.tld" to my
> virtual_alias_maps
> source file but I got this error:
>
> Aug 30 19:20:39 some postfix/smtpd[141]: NOQUEUE: reject: RCPT from
> mailhost[mailhost IP]: 4
Danil Smirnov via Postfix-users:
> Hi Wietse,
>
> Thank you for your response!
>
> On Wed, Aug 30, 2023 at 8:07?PM Wietse Venema via Postfix-users <
> postfix-users@postfix.org> wrote:
>
> > This is one of the purposes of virtual_alias_maps.
> >
>
> I tried this first - I've added "@domain2.tld
Hi Wietse,
Thank you for your response!
On Wed, Aug 30, 2023 at 8:07 PM Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
> This is one of the purposes of virtual_alias_maps.
>
I tried this first - I've added "@domain2.tld @domain1.tld" to my
virtual_alias_maps
source file but
Danil Smirnov via Postfix-users skrev den 2023-08-30 18:32:
I've tried some approaches with no luck, this seems rather tricky. Is
it possible to achieve this at all without using the second Postfix
server?
virtual_alias:
f...@example.org f...@example.net
postmap this file
basicly what you w
Danil Smirnov via Postfix-users:
> Hi,
>
> I have a Postfix server that serves domain1.tld
> using transport_maps, local_recipient_maps, and relay_domains parameters in
> order to relay all incoming emails to the local LMPT listener.
>
> Now I want to receive emails @domain2.tld in the same Postf
Hi,
I have a Postfix server that serves domain1.tld
using transport_maps, local_recipient_maps, and relay_domains parameters in
order to relay all incoming emails to the local LMPT listener.
Now I want to receive emails @domain2.tld in the same Postfix server and
rewrite them all to domain1.tld B
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, re-transm
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 som
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 li
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 getting
(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 re
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 addre
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:
> >
> > https://github.com/trusteddomainproject/Ope
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 h
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.
Probabl
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 f
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 entir
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 matters
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
@example.com --server
>> mail.example.com:25
>> --tls
>> swaks --to a...@example.com --from=b...@example.com --server
>> mail.example.com:25
>>
>> I was consistently getting the result "Access denied" in swaks, which I hope
>> means that
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:
Dni
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 t
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 i
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 communicati
er mail.example.com:25
I was consistently getting the result "Access denied" in swaks, which I
hope means that no relaying is possible anymore. Meanwhile, I succeeded
in sending messages with Thunderbird with proper authentication.
Email relaying was only possible when sending emails
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
mon
ail.example.com:25
--tls
swaks --to a...@example.com --from=b...@example.com --server mail.example.com:25
I was consistently getting the result "Access denied" in swaks, which I hope
means that no relaying is possible anymore. Meanwhile, I succeeded in
sending messages with Thunderbird with
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 launch
er
> mail.example.com:25
>
> I was consistently getting the result "Access denied" in swaks, which I hope
> means that no relaying is possible anymore. Meanwhile, I succeeded in
> sending messages with Thunderbird with proper authentication.
>
> Email relaying was o
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, and
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
>applications
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
> wo
>
> I was consistently getting the result "Access denied" in swaks, which I
> hope means that no relaying is possible anymore. Meanwhile, I succeeded
> in sending messages with Thunderbird with proper authentication.
>
> Email relaying was only possible when sending
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
https://
le.com --from=b...@example.com --server
mail.example.com:25 --tls
swaks --to a...@example.com --from=b...@example.com --server mail.example.com:25
I was consistently getting the result "Access denied" in swaks, which I
hope means that no relaying is possible anymore. Meanwhile, I succe
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,
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
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 bei
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 Afach
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:
Go
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 other
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
p...@
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 empat
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 is
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 don't
ess 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 primar
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 docume
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 ver
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 already
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
w
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
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
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,
https://fabianlee.org/2019/10/23/docker-running-a-postfix-container-for-testing-mail-during-dev
mpletely cut off
> relaying by setting mynetworks to localhost and mynetworks_style to
> host, then only launch the containers for short periods of time while I
> do the experiments. The containers will be running in foreground, which
> means I'll be seeing what's going on
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 incomin
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
es. Seems like, worst case
>> scenario, I just have to disable relaying of emails altogether and
>> that'll solve the problem, at least until a better solution is
>> available.
>
> Do any other containers on your machine relay mail through your Postfix?
>
> If no, you ca
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 r
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
l
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
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
750
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
1 - 100 of 606 matches
Mail list logo
