On 2024-12-17 Tomasz Pala via Postfix-users wrote:
> On 2024-12-17 07:32, Michael Tokarev via Postfix-users wrote:
>>> But /dev/log in systemd is datagram socket...
>>
>> Hm. Is this yet another myth we're facing here?
>
> Well, there were lots of anti-systemd in the old days, most of them
> were
On 2024-12-17 07:32, Michael Tokarev via Postfix-users wrote:
>
> Isn't the only reason maldrop is setgid is to be able to access
> /var/mail/$USER ?
> Which is a sort of legacy these days too, and is solved entirely by
> switching to ~/Maildir/ or other means to store email?
Nope, it's about ac
15.12.2024 16:44, Tomasz Pala via Postfix-users wrote:
..
In case of postfix, having magnitude of options, hardened by-default
service, or at least hardening comments ("You might uncomment this if
not using that") would be PITA for sure - but every journey starts from
the first step.
I'd love t
On 2024-12-16 10:18, Michael Tokarev via Postfix-users wrote:
>
> service or to the service which did the submission. Neither of the two
> is right or wrong in all cases, though I'd say the initial submission
> belongs more to the submitting service than to the accepting service, -
> at least tha
On 2024-12-16 04:05, Wietse Venema via Postfix-users wrote:
>>
>> # journalctl -o json-pretty --since -2m
>
> This assues that one already knows when some event of interest
> happened.
I'm not sure what do you mean - I gave you examples for querying
journal, you don't have to use any of these sel
16.12.2024 06:05, Wietse Venema via Postfix-users wrote:
Tomasz Pala via Postfix-users:
Again, what about the logging from NON-DAEMON Postfix processes
such as sendmail, postdrop, postqueue, and so on?
They belong to their calling service. Therefore if I run sendmail from
the shell, it belongs
Tomasz Pala via Postfix-users:
> > Again, what about the logging from NON-DAEMON Postfix processes
> > such as sendmail, postdrop, postqueue, and so on?
>
> They belong to their calling service. Therefore if I run sendmail from
> the shell, it belongs to my user's slice. If postdrop is run from
>
On 2024-12-16 01:16, Wietse Venema via Postfix-users wrote:
>>
>> All the processes of a service share single CGroup, so there's no ambiguity.
>
> You read half my question and stopped mid-way. Please extend
> your attention san.
Actually I've answered it all, but might elaborate.
> Again, what
Tomasz Pala via Postfix-users:
> On 2024-12-15 23:28, Wietse Venema via Postfix-users wrote:
> >>
> >> System-wide "defaults to 1 messages in 30s" and "is applied per-
> >> service", so this can be easily resolved by providing postfix.service
> >> with:
> >>
> >> LogRateLimitIntervalSec=0
> >
On 2024-12-16 00:23, Tomasz Pala via Postfix-users wrote:
>
> All the processes of a service share single CGroup, so there's no ambiguity.
Catched in several seconds intervals:
host-server ~# machinectl shell mail-server
mail-server ~# systemd-cgls -u postfix
Unit postfix.service (/system.slice/
On 2024-12-15 23:28, Wietse Venema via Postfix-users wrote:
>>
>> System-wide "defaults to 1 messages in 30s" and "is applied per-
>> service", so this can be easily resolved by providing postfix.service
>> with:
>>
>> LogRateLimitIntervalSec=0
>
> How would it know that a message sent with th
Tomasz Pala via Postfix-users:
> On 2024-12-15 09:44, Viktor Dukhovni via Postfix-users wrote:
> >
> > With systemd logging, logs are by default lossy (rate-limits too tight
> > and many users don't notice until it is too late). Also logging is
>
> System-wide "defaults to 1 messages in 30s"
On 2024-12-15 21:57, Gerald Galster via Postfix-users wrote:
>
> By default journald keeps about 4 GB of logs, which will only retain a
> few hours on a busy server. One might try to overcome that by setting
[...]
> when you discover some needed log data is not available anymore ...
>
> Storing l
>> With systemd logging, logs are by default lossy (rate-limits too tight
>> and many users don't notice until it is too late). Also logging is
>
> System-wide "defaults to 1 messages in 30s" and "is applied per-
> service", so this can be easily resolved by providing postfix.service
> with
On 2024-12-15 13:43, Wietse Venema via Postfix-users wrote:
>
> Oh, it is wonderful for laptops. On a busy server, it is known to
> discard events and to use more resources. No-one carea about the
> resources, with 16-core CPUs and SSDs.
In case anyone's interested - since v245 there are long awa
15.12.2024 14:33, Viktor Dukhovni via Postfix-users wrote:
On Sun, Dec 15, 2024 at 11:34:54AM +0100, Tomasz Pala via Postfix-users wrote:
System-wide "defaults to 1 messages in 30s" and "is applied per-
service", so this can be easily resolved by providing postfix.service
with:
LogRateLimi
On 2024-12-15 12:33, Viktor Dukhovni via Postfix-users wrote:
>
>> LogRateLimitIntervalSec=0
>
> Nice in theory, but neither Wietse nor I distribute systemd service
> definition files,
Why is that? Service units are best provided upstream.
In case of postfix, having magnitude of options, harden
Michael Tokarev via Postfix-users:
> 15.12.2024 03:07, Wietse Venema via Postfix-users wrote:
> > Michael Tokarev via Postfix-users:
> ...
> >> Today systemd plays major role in linux, and linux plays major role in the
> >> IT world. And while some its ideas are questionable or may look weird,
>
On Sun, Dec 15, 2024 at 11:34:54AM +0100, Tomasz Pala via Postfix-users wrote:
> System-wide "defaults to 1 messages in 30s" and "is applied per-
> service", so this can be easily resolved by providing postfix.service
> with:
>
> LogRateLimitIntervalSec=0
Nice in theory, but neither Wietse n
On 15/12/24 23:34, Tomasz Pala via Postfix-users wrote:
On 2024-12-15 09:44, Viktor Dukhovni via Postfix-users wrote:
With systemd logging, logs are by default lossy (rate-limits too tight
and many users don't notice until it is too late). Also logging is
System-wide "defaults to 1 messa
On 2024-12-15 09:44, Viktor Dukhovni via Postfix-users wrote:
>
> With systemd logging, logs are by default lossy (rate-limits too tight
> and many users don't notice until it is too late). Also logging is
System-wide "defaults to 1 messages in 30s" and "is applied per-
service", so this can
On Sun, Dec 15, 2024 at 11:16:16AM +0300, Michael Tokarev via Postfix-users
wrote:
> What was so unreliable in there?
On Sun, Dec 15, 2024 at 09:29:48AM +0100, Tomasz Pala via Postfix-users wrote:
> On 2024-12-15 01:07, Wietse Venema via Postfix-users wrote:
> Would you mind elaborating this a
15.12.2024 03:07, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
...
Today systemd plays major role in linux, and linux plays major role in the
IT world. And while some its ideas are questionable or may look weird, some
are interesting. And logging is one of them: i
* Wietse Venema via Postfix-users :
> Tomas Habarta via Postfix-users:
> > Ralf, looking at the log on one of the servers (Postfix 3.9), I can see
> > this:
> >
> > ... smtpd[435179]: NOQUEUE: hold: RCPT from xx[a.b.c.d]:
> > : Sender address triggers HOLD action;
> > from= to= proto=ESMTP helo
On Tue, Oct 08, 2024 at 02:03:23PM +0200, Ralf Hildebrandt via Postfix-users
wrote:
> Just a minor issue: When a access(5) maps is causing a mail to be
> held, I don't see any log line indicating this.
>
> Yes, the mail is on hold, but when I want to check WHY the mail was
> put on hold.
The fi
Tomas Habarta via Postfix-users:
> Ralf, looking at the log on one of the servers (Postfix 3.9), I can see this:
>
> ... smtpd[435179]: NOQUEUE: hold: RCPT from xx[a.b.c.d]: :
> Sender address triggers HOLD action; from=
> to= proto=ESMTP helo=
>
> You do not have anything similar at all or you
Ralf, looking at the log on one of the servers (Postfix 3.9), I can see this:
... smtpd[435179]: NOQUEUE: hold: RCPT from xx[a.b.c.d]: :
Sender address triggers HOLD action; from=
to= proto=ESMTP helo=
You do not have anything similar at all or you find that insufficient?
-th
On Tue, Oct 08
On 09.12.23 13:53, Doug Hardie via Postfix-users wrote:
I am using postfix with postsrsd. Is there a way for postfix to log the
from address as originally received? The only addresses I find in
postfix's log are the converted addresses from postsrsd. Both addresses
are logged by postsrsd, bu
Doug Hardie via Postfix-users:
> I am using postfix with postsrsd. Is there a way for postfix to
> log the from address as originally received? The only addresses
> I find in postfix's log are the converted addresses from postsrsd.
> Both addresses are logged by postsrsd, but there is no way to t
Viktor Dukhovni via Postfix-users:
> On Tue, Oct 24, 2023 at 12:52:37PM +0200, Paul Menzel via Postfix-users wrote:
>
> > Jozsef Kadlecsik submitted a patch, and it was accepted and is going to be
> > available in the 3.9 release [1].
> >
> > > 20231006
> > >
> > > Cleanup: attempt to log the
On Tue, Oct 24, 2023 at 07:05:13PM +0200, Eric Doutreleau wrote:
> then i have to check in the cyrus-sasl side
Cyrus SASL is just a library. It isn't its job to make independent
decisions about what to log. It may have a "debug level" knob that
Postfix could tweak, but running in "debug mode" i
thanks for the reply
then i have to check in the cyrus-sasl side
Le 24/10/2023 à 19:01, Viktor Dukhovni via Postfix-users a écrit :
On Tue, Oct 24, 2023 at 12:52:37PM +0200, Paul Menzel via Postfix-users wrote:
Jozsef Kadlecsik submitted a patch, and it was accepted and is going to be
availab
On Tue, Oct 24, 2023 at 12:52:37PM +0200, Paul Menzel via Postfix-users wrote:
> Jozsef Kadlecsik submitted a patch, and it was accepted and is going to be
> available in the 3.9 release [1].
>
> > 20231006
> >
> > Cleanup: attempt to log the SASL username after authentication
> > failur
Dear Eric,
Am 24.10.23 um 11:32 schrieb Eric Doutreleau via Postfix-users:
i m using on my server postfix-3.5.8 and cyrus-sasl-2.1.27
I m using fail2ban too to prevent brute force attack.
my problem is that when a connection failed because of wrong password i
don't know what account is targ
Dnia 24.10.2023 o godz. 11:32:58 Eric Doutreleau via Postfix-users pisze:
> Oct 5 11:07:52 hermes postfix/smtpd[277411]: warning:
> unknown[122.179.129.110]: SASL LOGIN authentication failed:
> authentication failure
>
> There s no username logged.
>
> Is there a way to log this username?
Cyrus
But it seems that all the useful information is already shown in the
dovecot log line (unless we want to differentiate SASL vs IMAP auth
failures for some reason).
Eugene
On 17.05.2023 14:06, Wietse Venema via Postfix-users wrote:
Matus UHLAR - fantomas via Postfix-users:
[ Charset ISO-8859-2
Matus UHLAR - fantomas via Postfix-users:
[ Charset ISO-8859-2 converted... ]
> >On 2023-05-16 at 12:19:03 UTC-0400 (Tue, 16 May 2023 18:19:03 +0200)
> >V?ctor Rubiella Monfort via Postfix-users
> >is rumored to have said:
> >>For example for imap/pop login failures dovecot log email account
> >>
On 2023-05-16 at 12:19:03 UTC-0400 (Tue, 16 May 2023 18:19:03 +0200)
Víctor Rubiella Monfort via Postfix-users
is rumored to have said:
For example for imap/pop login failures dovecot log email account
that produces the failure.
On 16.05.23 13:57, Bill Cole via Postfix-users wrote:
If you are
On 17/05/23 00:14, mailmary--- via Postfix-users wrote:
I am talking about the authentication email, not MAIL FROM or RCPT TO.
There is no "authentication email". There is a login username which can
be just about anything and in your case likely just happens to match the
user's email addres
On 2023-05-16 at 12:19:03 UTC-0400 (Tue, 16 May 2023 18:19:03 +0200)
Víctor Rubiella Monfort via Postfix-users
is rumored to have said:
For example for imap/pop login failures dovecot log email account that
produces the failure.
If you are using Dovecot for SASL and have auth_verbose enabled
On Tue, May 16, 2023 at 07:32:55PM +0300, Eugene R via Postfix-users wrote:
> Am I correct that the string in question should normally contain the SASL
> response? While the "Password:" is apparently some interactive prompt,
> indicating that something might be wrong with the connection or
> config
Hello,
Am I correct that the string in question should normally contain the
SASL response? While the "Password:" is apparently some interactive
prompt, indicating that something might be wrong with the connection or
configuration?
Eugene
On 16.05.2023 17:06, Wietse Venema via Postfix-users
Hi,
But what about show user login? Currently we have issues when fail2ban
blocks IPS for a high number or failed logins, but is a customer with
several mail accounts and he don't know which bad-configured account is
causing the ban.
Would be so healpfull shows the sasl_username that produce
mailmary--- via Postfix-users skrev den 2023-05-16 14:14:
so why not report the email, instead of a base64 string?
how usefull is decode of base64 here ?
its what happens next it more usefull to log
https://github.com/PowerDNS/weakforced
___
Postfi
Wietse Venema via Postfix-users skrev den 2023-05-16 13:52:
That is not the case.
i know my weakforced is not perfekt but i see all detail before reject,
even if postfix dont log it
https://github.com/PowerDNS/weakforced
___
Postfix-users mailing
mailmary--- via Postfix-users skrev den 2023-05-16 11:50:
Isn't the above useless? Should it say something like:
SASL LOGIN authentication failed: failed@email.address
PS:
I know that I can add -v to the smtpd submission process to get
thousands of debug lines and among them is the user/email
mailmary--- via Postfix-users:
>
> In all honesty, the current situation of logging the base64 string
> "UGFzc3dvcmQ6" does not help us.
>
> Maybe we could reconsider, and actually log the data (raw or base64-decoded)?
Absolutely not. As a matter of security principle, one does not
log the cont
In all honesty, the current situation of logging the base64 string
"UGFzc3dvcmQ6" does not help us.
Maybe we could reconsider, and actually log the data (raw or base64-decoded)?
On Tue, 16 May 2023 09:30:44 -0400 (EDT) Wietse Venema via Postfix-users
wrote:
> mailmary--- via Postfix-user
mailmary--- via Postfix-users:
>
> I am talking about the authentication email, not MAIL FROM or RCPT TO.
>
> hmm, when using the -v parameter, just above the "SASL LOGIN
> authentication failed: UGFzc3dvcmQ6" log entry, I can clearly see
> the email/password
>
> thus postfix knows the email addr
I am talking about the authentication email, not MAIL FROM or RCPT TO.
hmm, when using the -v parameter, just above the "SASL LOGIN authentication
failed: UGFzc3dvcmQ6" log entry, I can clearly see the email/password
thus postfix knows the email address being authenticated BEFORE the error
me
mailmary--- via Postfix-users:
>
> Out of curiosity, why does postfix display the base64 encoded "Password:"
> string on failed authentication, instead of the user/email that actually
> failed?
>
> eg:
> warning: unknown[59.2.250.144]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
...
>
> Isn
How embarrassing. You're right.Sorry for the noise.
>
> On Oct 25, 2022 at 6:32 PM, Wietse Venemawrote:
>
>
> James Pifer:
> > I've setup a postfix server as a closed relay to only deliver/forward
> > email for my domain. I believe I have everything work
James Pifer:
> I've setup a postfix server as a closed relay to only deliver/forward
> email for my domain. I believe I have everything working as desired,
> except for what is getting logged.
>
> If I connect to postfix with a portable mail client on my local network
> and send a message throu
> "Simon" == Simon Wilson writes:
John> More details would help us help you.
John> John
Simon> I worked it out. journald.conf was set to MaxLevelStore=notice,
Simon> so it wasn't just postfix not logging, just that was the
Simon> symptom picked up.
Simon> I really was missing something
- Message from John Stoffel -
Date: Sun, 28 Nov 2021 22:58:01 -0500
From: John Stoffel
Subject: Re: Logging silence
To: si...@simonandkate.net
Cc: John Stoffel , postfix-users@postfix.org
"Simon" == Simon Wilson writes:
Simon> - Message from
>>>>> "Simon" == Simon Wilson writes:
Simon> - Message from John Stoffel -
Simon>Date: Sun, 28 Nov 2021 21:37:12 -0500
Simon>From: John Stoffel
Simon> Subject: Re: Logging silence
Simon> To: si...@simonandkate.net
Simon>
- Message from John Stoffel -
Date: Sun, 28 Nov 2021 21:37:12 -0500
From: John Stoffel
Subject: Re: Logging silence
To: si...@simonandkate.net
Cc: postfix-users@postfix.org
"Simon" == Simon Wilson writes:
Simon> I feel like I'm missing someth
> "Simon" == Simon Wilson writes:
Simon> I feel like I'm missing something really obvious here... :(
Simon> Multiple RedHat8 servers, Postfix configured on all of them for
Simon> internal network mail server (primarily server log updates,
Simon> etc. to admin).
Have you restarted syslog (or
On Wed, Sep 22, 2021 at 10:15:50AM +0200, Sven Schwedas
wrote:
> On 22.09.21 04:26, Alex wrote:
> > Yes, thanks. I realize I can do that - it's the
> > "your_script_that_saves_to_sql" part that would be very helpful :-)
>
> Not sure if there's a one-size-fits-all script that works in all setups
On 22.09.21 04:26, Alex wrote:
Yes, thanks. I realize I can do that - it's the
"your_script_that_saves_to_sql" part that would be very helpful :-)
Not sure if there's a one-size-fits-all script that works in all setups,
it's going to be highly individualized.
> There's also great difficulty
On Tue, Sep 21, 2021 at 10:30:54PM -0400, Alex wrote:
> Hi,
>
> > Why you shouldn’t log into db
> >
> > https://medium.com/@marton.waszlavik/why-you-shouldnt-log-into-db-e700c2cb0c8c
> >
> > I'm not suggesting that this person is correct, just
> > mentioning it. After all, there are many su
On Wed, Sep 22, 2021 at 12:24:25PM +1000, raf wrote:
> On Tue, Sep 21, 2021 at 08:49:24PM -0400, Alex wrote:
>
> > Hi,
> >
> > I'm interested in having postfix log directly to a mariadb or mongodb
> > database so I can then query it for different info like sender,
> > recipient and subject, et
Hi,
> Why you shouldn’t log into db
>
> https://medium.com/@marton.waszlavik/why-you-shouldnt-log-into-db-e700c2cb0c8c
>
> I'm not suggesting that this person is correct, just
> mentioning it. After all, there are many successful
> companies with products that put staggering quantities
> of l
Hi,
> > I'm interested in having postfix log directly to a mariadb or mongodb
> > database so I can then query it for different info like sender,
> > recipient and subject, etc. Does anyone know the best way to go about
> > doing this?
>
> I don't know if this is the best way, but one option is to
On Tue, Sep 21, 2021 at 08:49:24PM -0400, Alex wrote:
> Hi,
>
> I'm interested in having postfix log directly to a mariadb or mongodb
> database so I can then query it for different info like sender,
> recipient and subject, etc. Does anyone know the best way to go about
> doing this?
By defaul
I'm interested in having postfix log directly to a mariadb or mongodb
database so I can then query it for different info like sender,
recipient and subject, etc. Does anyone know the best way to go about
doing this?
I don't know if this is the best way, but one option is to send all mail
logs f
On Thu, Aug 19, 2021 at 09:27:10AM -0400, Wietse Venema
wrote:
> raf:
> > I take it that milters must work too, but they sound
> > like much more effort. You need to write a whole other
> > program (securely).
>
> No. You write little functions in a common language (python, perl,
> java, rust,
raf:
> I take it that milters must work too, but they sound
> like much more effort. You need to write a whole other
> program (securely).
No. You write little functions in a common language (python, perl,
java, rust, haskell?, php, C) and leave the rest up to a code
library.
Wietse
On Wed, Aug 18, 2021 at 12:07:07PM -0700, Ron Garret wrote:
> On Aug 18, 2021, at 11:55 AM, Viktor Dukhovni
> wrote:
>
> > If you want different processing for inbound and outbound mail,
> > use separate Postfix instances configured appropriately to the
> > task at hand.
>
> There is a useful
On Wed, Aug 18, 2021 at 12:27:36PM -0700, Ron Garret wrote:
> > Milters are primarily for content filtering,
>
> Sure, but...
>
> > they don't or shouldn’t affect address rewriting and message routing.
>
> That doesn’t make sense to me. One of the main uses of a milter is to
> sequester mail w
On Aug 18, 2021, at 12:13 PM, Viktor Dukhovni
wrote:
>> On 18 Aug 2021, at 3:07 pm, Ron Garret wrote:
>>
>>> If you want different processing for inbound and outbound mail,
>>> use separate Postfix instances configured appropriately to the
>>> task at hand.
>>
>> There is a useful distincti
> On 18 Aug 2021, at 3:07 pm, Ron Garret wrote:
>
>> If you want different processing for inbound and outbound mail,
>> use separate Postfix instances configured appropriately to the
>> task at hand.
>
> There is a useful distinction to be made between mail that is injected into
> the system by
> On 18 Aug 2021, at 3:01 pm, post...@ptld.com wrote:
>
>> A useful rubric to keep in mind is:
>> * There's no such thing as outbound mail,
>>all mail comes in, and then it goes out...
>> Any notion of incoming or outgoing is a mental model you overlay on
>> your use of the Postfix MTA, the a
On Aug 18, 2021, at 11:55 AM, Viktor Dukhovni
wrote:
> If you want different processing for inbound and outbound mail,
> use separate Postfix instances configured appropriately to the
> task at hand.
There is a useful distinction to be made between mail that is injected into the
system by an
A useful rubric to keep in mind is:
* There's no such thing as outbound mail,
all mail comes in, and then it goes out...
Any notion of incoming or outgoing is a mental model you overlay on
your use of the Postfix MTA, the actual MTA is just a message switch.
The expansion of virtual alias
> On 18 Aug 2021, at 2:50 pm, post...@ptld.com wrote:
>
> It is an all or nothing situation? To not "expand" that means not having
> alias lookup at all even for incoming messages? The fact i have virtual alias
> lookup for incoming that means postfix will by default use that for outgoing?
> No
Don't expand the alias.
I don't understand this. As far as i know, *IM* not expanding the
alias.
Is this a setting in postfix? Is this a default behavior?
You are expanding the alias, by configuring a virtual(5) alias table
entry with an expansion for the alias. To not expand the alias, use
> On 18 Aug 2021, at 2:41 pm, post...@ptld.com wrote:
>
>> Don't expand the alias.
>
> I don't understand this. As far as i know, *IM* not expanding the alias.
> Is this a setting in postfix? Is this a default behavior?
You are expanding the alias, by configuring a virtual(5) alias table
entry w
Is there anyway to prevent this behavior? Have the third server just
send the email to who it was told to send it to, the alias address.
Don't expand the alias.
I don't understand this. As far as i know, *IM* not expanding the alias.
Is this a setting in postfix? Is this a default behavior?
post...@ptld.com:
> > Im confused by this situation. Two separate independent servers both
> > running same version of postfix and both setup the same way with
> > virtual users and alias address stored in SQL.
>
> Okay, i think i figured out what is going on. On the second server that
> im sendi
post...@ptld.com:
> Im confused by this situation. Two separate independent servers both
> running same version of postfix and both setup the same way with virtual
> users and alias address stored in SQL.
>
> main.cf:
> virtual_transport = lmtp:unix:private/dovecot-lmtp
> virtual_mai
Im confused by this situation. Two separate independent servers both
running same version of postfix and both setup the same way with
virtual users and alias address stored in SQL.
Okay, i think i figured out what is going on. On the second server that
im sending email to, im sending from a thi
Wietse Venema:
A. Schulze:
Is there a recommended/any way to log messages from a script via postfix?
Not at this time. Making the postlog command setgid requires a security
analysis and that may require some code restructuring before this can
be done without opening up a security hole.
H
A. Schulze:
> Hello,
>
> I've to rebuild a service: messages to an address are delivered via postfix
> pipe to a script.
> This script use syslog to write it's messages. That worked well for years.
>
> Now, postfix run in a different way, supervised via "postfix start-fg"
> (docker)
> Essential
On Wed, Aug 04, 2021 at 04:37:38PM -0400, post...@ptld.com wrote:
> > This message never entered the queue, the client sent "QUIT" without
> > sending any data. The nascent queue file was deleted by cleanup(8),
> > when smtpd(8) abandoned the transaction.
>
> Oh okay, so it is possible for it to
This message never entered the queue, the client sent "QUIT" without
sending any data. The nascent queue file was deleted by cleanup(8),
when smtpd(8) abandoned the transaction.
Oh okay, so it is possible for it to assign a queue ID and log it
without sending an actual message to the queue?
A
Never? That would be most likely lost logging due to systemd or
rsyslog rate limits, or naive logfile analysis that misses that
that the logfile is rotated, so that the 'deleted' record is written
to different file than the one you're looking at.
I do not think that is the case in this instance.
post...@ptld.com:
> Usually when postfix gets far enough along in a transaction it creates a
> queue ID, then at the end around disconnect it logs removing from queue.
>
>postfix/smtpd[6147]: 4Gg1J52gV6z4l3g5:
> client=camomile.cloud9.net[168.100.1.3]
>...
>postfix/qmgr[2409]: 4Gg1J5
On Wed, Aug 04, 2021 at 03:44:03PM -0400, post...@ptld.com wrote:
> Usually when postfix gets far enough along in a transaction it creates a
> queue ID, then at the end around disconnect it logs removing from queue.
The "qmgr: removed" message is logged once all the recipients of a
message that
On Sun, May 30, 2021 at 12:04:41PM -0400, Bill Cole wrote:
> It's named collate.pl, included in the Postfix source distribution:
>
> sc1:bill$ cat postfix-3.6.0/auxiliary/collate/README
> This script, by Viktor Dukhovni, untangles a Postfix logfile and
> groups the records one "
On 2021-05-30 at 09:32:03 UTC-0400 (Sun, 30 May 2021 15:32:03 +0200)
Matus UHLAR - fantomas
is rumored to have said:
On 05-29-2021 1:16 pm, Shawn Heisey wrote:
Adding to the reply from Wietse, which I have to agree with:
On 29.05.21 16:40, post...@ptld.com wrote:
I was just assuming that a c
On 05-29-2021 1:16 pm, Shawn Heisey wrote:
Adding to the reply from Wietse, which I have to agree with:
On 29.05.21 16:40, post...@ptld.com wrote:
I was just assuming that a connection happens first before postfix
could know if the PTR resolves or not.
Otherwise how does postfix know a client
On 05-29-2021 1:16 pm, Shawn Heisey wrote:
Adding to the reply from Wietse, which I have to agree with:
I was just assuming that a connection happens first before postfix could
know if the PTR resolves or not.
Otherwise how does postfix know a client hostname needs to be checked if
it has ne
On 5/28/2021 6:24 PM, post...@ptld.com wrote:
Without recompiling postfix, is there a way to get the PTR hostname
warning to come after the connect message in the logs?
Adding to the reply from Wietse, which I have to agree with:
On my Ubuntu 18 mail server, everything that postfix sends to sy
post...@ptld.com:
> Without recompiling postfix, is there a way to get the PTR hostname
> warning to come after the connect message in the logs?
That would be wrong.
As a matter or principle, Postfix logs a warning for a bad condition
(for example client name unavailable), before doing somethin
On Sat, Apr 17, 2021, Wietse Venema wrote:
> Francesc Pe?alvez:
> > Is it possible to identify which password smtp is trying to use? if so I
> > would like to know how
This seems to be a common request hence several people submitted
patches for sendmail to identify at least the account:
8.16.1/
On Wed, 20 Jan 2021 10:33:37 -0500 (EST)
Wietse Venema wrote:
[snip]
>
> With rsyslogd.conf you can route based on content.
>
> :msg, contains, "SASL LOGIN" /var/log/whatever
> :msg, contains, "SASL LOGIN" ~
>
> This is based on information from the web, which is often incorrect.
Ok. Thank
Jim Seymour:
> Hi All,
>
> Each of the various servers I admin occasionally get inundated with
> things like
>
> Jan 13 07:33:06 jimsun postfix/submission/smtpd[25328]: warning:
> unknown[59.95.95.239]: SASL LOGIN authentication failed:
> UGFzc3dvcmQ6
This warning is produced by Post
On 2 Oct 2020, at 21:19, Matt Zagrabelny wrote:
How do I log envelope fields for received mail?
Postfix logs the envelope sender and recipients by default. For example,
your message generated these 2 lines in my log:
Oct 2 21:19:27 bigsky postfix/qmgr[45059]: 4C38Cc621Yz4rbKG:
from=, size
Quite right. My mistake. The root cause in this case was musl libc in the
Alpine Linux 3.9 container image, whose syslog call uses dgram only, unlike
glibc, which will attempt stream as well. Thanks for pointing me in the
right direction.
FWIW, the new CHUNKING support (BDAT command) in Postfix
1 - 100 of 232 matches
Mail list logo
