Thursday, March 7, 2024, 3:58:26 PM, Viktor Dukhovni via Postfix-users wrote:
> On Thu, Mar 07, 2024 at 01:06:53PM +1100, Phil Biggs via Postfix-users wrote:
>> Today I noticed that, occasionally, I see a syslog message stating "blocked
>> using zen.spamhaus..." but no matching "DNSBL rank ..."
On Thu, Mar 07, 2024 at 01:06:53PM +1100, Phil Biggs via Postfix-users wrote:
> Today I noticed that, occasionally, I see a syslog message stating "blocked
> using zen.spamhaus..." but no matching "DNSBL rank ..." message.
>
> A couple of examples from the past two days:
>
> postfix/postscreen
Today I noticed that, occasionally, I see a syslog message stating "blocked
using zen.spamhaus..." but no matching "DNSBL rank ..." message.
A couple of examples from the past two days:
postfix/postscreen 84893 - - CONNECT from [43.157.61.211]:30092 to
[192.168.11.2]:25
postfix/dnsblog 84894
> On 23 May 2018, at 13:41, Viktor Dukhovni wrote:
>
>
>
>> On May 23, 2018, at 4:10 PM, Doug Hardie wrote:
>>
>> incoming_smtpd_restrictions =
>> check_policy_service inet:127.0.0.1:10040,
>> reject_invalid_hostname,
>> reject_non_fqdn_sender,
>> reject_non_fqdn_recip
> On May 23, 2018, at 4:10 PM, Doug Hardie wrote:
>
> incoming_smtpd_restrictions =
>check_policy_service inet:127.0.0.1:10040,
>reject_invalid_hostname,
>reject_non_fqdn_sender,
>reject_non_fqdn_recipient,
>reject_unknown_sender_domain,
>reject_u
> On 23 May 2018, at 13:17, Viktor Dukhovni wrote:
>
>
>
>> On May 23, 2018, at 4:10 PM, Doug Hardie wrote:
>>
>> I would think that cache would be cleared with a restart.
>
> No. The verification cache survives restart. This is intentional.
There sure is a lot to learn about postfix...
> On May 23, 2018, at 4:10 PM, Doug Hardie wrote:
>
> I would think that cache would be cleared with a restart.
No. The verification cache survives restart. This is intentional.
> Vmail_alias is dated 28 Apr. That's almost 2 months ago.
In this version of the multiverse Apr/28 is 3.5 week
> On 23 May 2018, at 11:43, Viktor Dukhovni wrote:
>
>
>
>> On May 23, 2018, at 2:23 PM, Doug Hardie wrote:
>>
>> It is a non-existent address and is fine. It's just surprising that one of
>> the non-existent addresses gets a different log message. The only thing I
>> can think of is that
> On May 23, 2018, at 2:23 PM, Doug Hardie wrote:
>
> It is a non-existent address and is fine. It's just surprising that one of
> the non-existent addresses gets a different log message. The only thing I
> can think of is that the originator has a non-printing character somewhere in
> the
> On 23 May 2018, at 09:24, /dev/rob0 wrote:
>
> On Wed, May 23, 2018 at 08:39:08AM -0700, Doug Hardie wrote:
>> I am running a mail server that has a few local recipients and a
>> bunch of forwarded recipients for one domain. All is working
>> properly. However,
On Wed, May 23, 2018 at 08:39:08AM -0700, Doug Hardie wrote:
> I am running a mail server that has a few local recipients and a
> bunch of forwarded recipients for one domain. All is working
> properly. However, there are some log messages that I find
> confusing. The server r
Doug Hardie:
> I am running a mail server that has a few local recipients and a bunch of
> forwarded recipients for one domain. All is working properly. However,
> there are some log messages that I find confusing. The server receives many
> messages delivery attempts where the
I am running a mail server that has a few local recipients and a bunch of
forwarded recipients for one domain. All is working properly. However, there
are some log messages that I find confusing. The server receives many messages
delivery attempts where the user is not included in the
Hello,
opensuse v42.2
linux 4.4.62-18.6-default x86_64
postfix 2.11.8-1.4
We recently upgraded our system from opensuse 42.1 to 42.2. Ther
errors shown below are new with the current version of postfix (I do not
recall the older version number).
LDAP is not running on this system althoug
@ lbutlr:
> On 12/4/16 8:17 AM, Wietse Venema wrote:
> > @ lbutlr:
> >> On 12/3/16 2:57 PM, Wietse Venema wrote:
> >>> Proof of concept:
> >>>
> >>> MAIL FROM<" >>> type='text/javascript'>alert('xss');"@example.com>
> >>
> >> That result in "501 5.5.4 Syntax: MAIL FROM:"
> >
> > OK, so insert a t
On 12/4/16 8:17 AM, Wietse Venema wrote:
@ lbutlr:
On 12/3/16 2:57 PM, Wietse Venema wrote:
Proof of concept:
MAIL FROM<"alert('xss');"@example.com>
That result in "501 5.5.4 Syntax: MAIL FROM:"
OK, so insert a the missing ':'
MAIL FROM:"alert('xss');"@example.com>
250 2.1.0 Ok
Fair e
@ lbutlr:
> On 12/3/16 2:57 PM, Wietse Venema wrote:
> > Proof of concept:
> >
> > MAIL FROM<" > type='text/javascript'>alert('xss');"@example.com>
>
> That result in "501 5.5.4 Syntax: MAIL FROM:"
OK, so insert a the missing ':'
MAIL FROM:"alert('xss');"@example.com>
250 2.1.0 Ok
Instead of
On 2016-12-02 15:10, Michael Munger wrote:
This is a great idea. This is a spam filter that is integrated into a
CRM system, so I needed to parse and dump the information so it could
be
sucked up later.
Here's what I ultimately created. It still needs some work (mainly
because it re-reads the
> On Dec 4, 2016, at 12:58 AM, @lbutlr wrote:
>
>> MAIL FROM<"> type='text/javascript'>alert('xss');"@example.com>
>
> That result in "501 5.5.4 Syntax: MAIL FROM:"
There's a missing ":" after FROM. In any case, even if a particular
exploit mechanism fails, or even all attacks happen to fail,
On 12/3/16 2:57 PM, Wietse Venema wrote:
Proof of concept:
MAIL FROM<"alert('xss');"@example.com>
That result in "501 5.5.4 Syntax: MAIL FROM:"
Wietse Venema:
> @ lbutlr:
> > > Careful with that. To easy to create a script injection vector. Bash is
> > > not
> > > a good language in which to construct safely quoted remote content for
> > > injection
> > > into a suitable HTML skeleton.
> >
> > Injection from where? the script is only
@ lbutlr:
> > Careful with that. To easy to create a script injection vector. Bash is
> > not
> > a good language in which to construct safely quoted remote content for
> > injection
> > into a suitable HTML skeleton.
>
> Injection from where? the script is only accessible to the root user on
On 12/3/16 9:53 AM, Bastian Blank wrote:
On Sat, Dec 03, 2016 at 09:44:03AM -0700, @lbutlr wrote:
Injection from where? the script is only accessible to the root user
on the mail server and only checks /var/log/maillog (or the log
specified at the top of the script). There's no remote content
in
On Sat, Dec 03, 2016 at 09:44:03AM -0700, @lbutlr wrote:
> Injection from where? the script is only accessible to the root user
> on the mail server and only checks /var/log/maillog (or the log
> specified at the top of the script). There's no remote content
> involved.
The contents of the log are
On 12/3/16 1:48 AM, Viktor Dukhovni wrote:
On Dec 2, 2016, at 1:30 AM, @lbutlr wrote:
I have a bash script that does it, and when a user wants this, I simply set up
a crontab for them. Usually after a week or so they want it turned off. The
script sends them a lightly styled HTML table in t
Viktor Dukhovni:
>
> > On Dec 2, 2016, at 1:30 AM, @lbutlr wrote:
> >
> > I have a bash script that does it, and when a user wants this, I simply set
> > up a crontab for them. Usually after a week or so they want it turned off.
> > The script sends them a lightly styled HTML table in the emai
> On Dec 2, 2016, at 1:30 AM, @lbutlr wrote:
>
> I have a bash script that does it, and when a user wants this, I simply set
> up a crontab for them. Usually after a week or so they want it turned off.
> The script sends them a lightly styled HTML table in the email.
>
> The heart of the scri
This is a great idea. This is a spam filter that is integrated into a
CRM system, so I needed to parse and dump the information so it could be
sucked up later.
Here's what I ultimately created. It still needs some work (mainly
because it re-reads the whole file every time, and I should use
timesta
On 11/30/16 2:35 PM, Michael Munger wrote:
I am writing a log parser so that when users complain "so and so sent me
an email and I didn't get it" I can query the logs and find this with
ease. Ultimately, I want ot make this self service through a web page.
I went a different way. Users can chose
On 12/01/2016 09:37 AM, Wietse Venema wrote:
And I have made a note to log the sender when rejecting the (MAIL
FROM) SIZE parameter.
Wow. Wasn't expecting that! Thank you, sir.
Michael Munger:
> Bill:
>
> Thank you for both items. I shall pour over them.
And I have made a note to log the sender when rejecting the (MAIL
FROM) SIZE parameter.
Wietse
Bill:
Thank you for both items. I shall pour over them.
On 11/30/2016 11:49 PM, Bill Cole wrote:
On 30 Nov 2016, at 20:20, Michael Munger wrote:
First, there can be no TO address before the client sends MAIL FROM.
Second, the size check is done before checking the sender address,
presumably b
On 30 Nov 2016, at 20:20, Michael Munger wrote:
First, there can be no TO address before the client sends MAIL FROM.
Second, the size check is done before checking the sender address,
presumably because it is more efficient that way. But I guess some
code could be swapped around.
My mistake. I
> First, there can be no TO address before the client sends MAIL FROM.
> Second, the size check is done before checking the sender address,
> presumably because it is more efficient that way. But I guess some
> code could be swapped around.
My mistake. I thought:
552 5.3.4 Message size exceeds fi
Michael Munger:
> I am writing a log parser so that when users complain "so and so sent me
> an email and I didn't get it" I can query the logs and find this with
> ease. Ultimately, I want ot make this self service through a web page.
>
> In a transaction like this:
>
> 119970-Nov 29 13:56:12 mc
I am writing a log parser so that when users complain "so and so sent me
an email and I didn't get it" I can query the logs and find this with
ease. Ultimately, I want ot make this self service through a web page.
In a transaction like this:
119970-Nov 29 13:56:12 mcdb2 postfix/smtpd[12371]: disc
Per Jessen:
[ Charset UTF-8 unsupported, converting... ]
> Wietse Venema wrote:
>
> >> Whilst on the subject of connection caching, I assume postfix will
> >> (have
> >> to) do a RSET between each reuse of a connection? (just a sanity
> >> check on my part).
> >
> > Of course. See http://www.pos
Wietse Venema wrote:
>> Whilst on the subject of connection caching, I assume postfix will
>> (have
>> to) do a RSET between each reuse of a connection? (just a sanity
>> check on my part).
>
> Of course. See http://www.postfix.org/CONNECTION_CACHE_README.html
>
> Wietse
One more question then
Per Jessen:
> Wietse Venema wrote:
>
> > When Postfix reuses an SMTP connection, it may actually be reused
> > in a different SMTP client process. This maximizes reuse and
> > minimizes the time that a connection sits idle.
> >
> > This is different from Sendmail or Exim, where a connection can b
Wietse Venema wrote:
> When Postfix reuses an SMTP connection, it may actually be reused
> in a different SMTP client process. This maximizes reuse and
> minimizes the time that a connection sits idle.
>
> This is different from Sendmail or Exim, where a connection can be
> reused only in the pro
When Postfix reuses an SMTP connection, it may actually be reused
in a different SMTP client process. This maximizes reuse and
minimizes the time that a connection sits idle.
This is different from Sendmail or Exim, where a connection can be
reused only in the process that creates that connection.
Ralf Hildebrandt wrote:
> Odd, it works here:
>
> # fgrep "postfix/smtp[12851]" /var/log/mail.log| awk '{print $9}'
> delay=0.74,
> conn_use=2,
> conn_use=3,
> delay=0.18,
> conn_use=4,
> conn_use=5,
I've got more:
fgrep "postfix1/smtp[29938]" /var/log/mail | awk '{print
$1" "$2" "$3" "$9}'
Au
* Per Jessen <[EMAIL PROTECTED]>:
> Aug 30 10:49:24 postfix1/smtp[18518]:
> Aug 30 10:49:52 postfix1/smtp[18518]:
> Aug 30 10:49:53 postfix1/smtp[18518]: conn_use=2,
> Aug 30 10:49:54 postfix1/smtp[18518]: conn_use=4,
> Aug 30 10:49:55 postfix1/smtp[18518]: conn_use=6,
> Aug 30 10:49:56 postfix1
Ralf Hildebrandt wrote:
> * Per Jessen <[EMAIL PROTECTED]>:
>> I'm using postfix 2.5.4.
>>
>> When I read the following in the log:
>>
>> postfix1/smtp[18518]: 4AD0517085: to=<[EMAIL PROTECTED]>,
>> relay=myserver[myipaddr]:25, conn_use=4, delay=7.8,
>> delays=7.6/0/0.03/0.08, dsn=2.0.0, status=
* Per Jessen <[EMAIL PROTECTED]>:
> I'm using postfix 2.5.4.
>
> When I read the following in the log:
>
> postfix1/smtp[18518]: 4AD0517085: to=<[EMAIL PROTECTED]>,
> relay=myserver[myipaddr]:25, conn_use=4, delay=7.8,
> delays=7.6/0/0.03/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
> F3
I'm using postfix 2.5.4.
When I read the following in the log:
postfix1/smtp[18518]: 4AD0517085: to=<[EMAIL PROTECTED]>,
relay=myserver[myipaddr]:25, conn_use=4, delay=7.8,
delays=7.6/0/0.03/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
F3241EDAA)
I tend to think that _one_ email has bee
In message <[EMAIL PROTECTED]>, you wrote:
>Ronald F. Guilmette:
>>
>> I was just perusing the /var/log/messages file on a system I have
>> that's currently running Postfix 2.5.1 and I saw the following messages:
>>
>> Jul 29 19:47:42 roomy postfix/s
Ronald F. Guilmette:
>
> I was just perusing the /var/log/messages file on a system I have
> that's currently running Postfix 2.5.1 and I saw the following messages:
>
> Jul 29 19:47:42 roomy postfix/smtpd[72875]: gethostby*.getanswer: asked for
> "ip200.208-100-19.
In message <[EMAIL PROTECTED]>,
Jorey Bump <[EMAIL PROTECTED]> wrote:
>Ronald F. Guilmette wrote, at 07/30/2008 03:19 PM:
>> I was just perusing the /var/log/messages file on a system I have
>> that's currently running Postfix 2.5.1 and I saw the following messag
Ronald F. Guilmette wrote, at 07/30/2008 03:19 PM:
I was just perusing the /var/log/messages file on a system I have
that's currently running Postfix 2.5.1 and I saw the following messages:
Jul 29 19:47:42 roomy postfix/smtpd[72875]: gethostby*.getanswer: asked for
"ip200.
On Wed, July 30, 2008 3:19 pm, Ronald F. Guilmette wrote:
>
> I was just perusing the /var/log/messages file on a system I have
> that's currently running Postfix 2.5.1 and I saw the following messages:
>
> Jul 29 19:47:42 roomy postfix/smtpd[72875]: gethostby*.getanswer: as
I was just perusing the /var/log/messages file on a system I have
that's currently running Postfix 2.5.1 and I saw the following messages:
Jul 29 19:47:42 roomy postfix/smtpd[72875]: gethostby*.getanswer: asked for
"ip200.208-100-19.vswitch.static.steadfast.net IN A", got type &q
On Sun, Jul 27, 2008 at 09:32:34PM -0400, [EMAIL PROTECTED] wrote:
> What log message should I look for when a message has been deferred
> and Postfix has decided it is undeliverable? (I'm parsing the log and
> need to know how to distinguish this from an actual bounce.) Will the
> log conta
[EMAIL PROTECTED]:
> What log message should I look for when a message has been deferred
> and Postfix has decided it is undeliverable? (I'm parsing the log and
> need to know how to distinguish this from an actual bounce.) Will the
> log contain a 5xx message for that mail?
Look at the "sta
What log message should I look for when a message has been deferred
and Postfix has decided it is undeliverable? (I'm parsing the log and
need to know how to distinguish this from an actual bounce.) Will the
log contain a 5xx message for that mail?
--
55 matches
Mail list logo
