On 12.10.21 08:17, Carl Brewer wrote:
I'm trying to sort out a spamassassin issue, using spamass-milter,
submitted email is failing SPF checks, as spamassassin is seeing the
IP address of the mail client and - it fails SPF as you'd expect.
I think this is due to a mis-configura
On 2021-10-12 23:20, Kevin A. McGrail wrote:
On 10/11/2021 6:28 PM, Carl Brewer wrote:
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
Carl, I noticed this and wanted to mention if you are using
something like Google's quad8 for your resolver? If so, install
On 10/11/2021 6:28 PM, Carl Brewer wrote:
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
Carl, I noticed this and wanted to mention if you are using something
like Google's quad8 for your resolver? If so, install a caching
lo
On 12/10/2021 10:36 am, Benny Pedersen wrote:
On 2021-10-12 01:14, Carl Brewer wrote:
On 12/10/2021 9:56 am, Benny Pedersen wrote:
Carl: add -o smtpd_milters= to submission service in master.cf to
turn of sasl users in spamas-milter
Thank you, that's done it.
Is it possible to selectively en
On 2021-10-12 01:14, Carl Brewer wrote:
On 12/10/2021 9:56 am, Benny Pedersen wrote:
Carl: add -o smtpd_milters= to submission service in master.cf to turn
of sasl users in spamas-milter
Thank you, that's done it.
Is it possible to selectively enable some milters? ie: clamav?
yes, just add
On 12/10/2021 9:56 am, Benny Pedersen wrote:
Carl: add -o smtpd_milters= to submission service in master.cf to turn
of sasl users in spamas-milter
Thank you, that's done it.
Is it possible to selectively enable some milters? ie: clamav?
Carl
On 2021-10-12 00:06, Kevin A. McGrail wrote:
On 10/11/2021 5:32 PM, Carl Brewer wrote:
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL
was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
Carl, I noticed this and wanted to
On 12/10/2021 9:06 am, Kevin A. McGrail wrote:
On 10/11/2021 5:32 PM, Carl Brewer wrote:
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
On 10/11/2021 5:32 PM, Carl Brewer wrote:
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
Carl, I noticed this an
On 12/10/2021 8:17 am, Carl Brewer wrote:
This is what's in the SMTP header when it fails : ('s added by me)
The IP address of the mail client's PC is failing the SPF check, as I
would expect it to. I don't know what I've done wrong that's making it
get looked at though? This is authen
Hi,
I'm trying to sort out a spamassassin issue, using spamass-milter,
submitted email is failing SPF checks, as spamassassin is seeing the IP
address of the mail client and - it fails SPF as you'd expect.
I think this is due to a mis-configuration of my setup of the SMTP
submis
On 10/29/20 9:30 AM, @lbutlr wrote:
but otherwise point 1 is a real sticking point as things outside the normal ports channel
tend to fall off the "hey, I need to check that for updates" train far too
easily.
sure.
i've not dealt with *bsd packaging for a _very_ long time, so have no sense f
On 29 Oct 2020, at 09:45, PGNet Dev wrote:
> otoh, spamassassin-milter's dev is here/active, on list.
> and has been _very_ helpful responsive to date.
All good points, but
1) It's not in FreeBSD ports which means I have to take special and specific
steps to keep it up-to-date
2) It means deali
On 10/29/20 7:33 AM, @lbutlr wrote:
Thank you, I will take a look at that. Spamass-milter is supposed to do this
with the -a flag which is missing from the config for some reason above, so I
will first add that flag and see if it works. Curious that it is coming up
infrequently, however
On 29 Oct 2020, at 08:02, PGNet Dev wrote:
> On 10/29/20 6:51 AM, @lbutlr wrote:
>> Recently the behavior of spamass-milter or the underlying spamassasin has
>> changed such that the originating IP for secured submission email is being
>> tagged for PBL/Dynamic scores. Thi
On 10/29/20 6:51 AM, @lbutlr wrote:
Recently the behavior of spamass-milter or the underlying spamassasin has
changed such that the originating IP for secured submission email is being
tagged for PBL/Dynamic scores. This does;t happen often, but since all mail is
only accepted via TLSv1.2
Recently the behavior of spamass-milter or the underlying spamassasin has
changed such that the originating IP for secured submission email is being
tagged for PBL/Dynamic scores. This does;t happen often, but since all mail is
only accepted via TLSv1.2 this should not be happening.
The
d
store the databases. So I look at /etc/default/spamass-milter, where the
OPTIONS line looks like this:
OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I --
--socket /var/spool/postfix/spamassassin/spamd.sock"
My understanding is that everything after the "--" gets passed right to
On 12 Feb 2015, at 16:08 , Noel Jones wrote:
> On 2/12/2015 4:56 PM, LuKreme wrote:
>> On 12 Feb 2015, at 13:42 , Noel Jones wrote:
>>> spamass-milter uses the standard spamassassin spamc/spamd interface.
>>> I believe you can enable additional spamass-milter logging
On 2/12/2015 4:56 PM, LuKreme wrote:
> On 12 Feb 2015, at 13:42 , Noel Jones wrote:
>> spamass-milter uses the standard spamassassin spamc/spamd interface.
>> I believe you can enable additional spamass-milter logging on its
>> startup command line.
>>
>> There
Am 12.02.2015 um 23:56 schrieb LuKreme:
On 12 Feb 2015, at 13:42 , Noel Jones wrote:
spamass-milter uses the standard spamassassin spamc/spamd interface.
I believe you can enable additional spamass-milter logging on its
startup command line.
There are startup flags you can add to spamass
On 12 Feb 2015, at 13:42 , Noel Jones wrote:
> spamass-milter uses the standard spamassassin spamc/spamd interface.
> I believe you can enable additional spamass-milter logging on its
> startup command line.
>
> There are startup flags you can add to spamass-milter to rejec
I reject incoming messages based on their
score (for example, say I wanted to reject all spam scoring 9.0 or higher)?
/usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g
sa-milt -r 8.0 -- -s 5242880 --port=10028
the "-r 8.0" is the reject score
params after -- are
> Two questions. Wouldn't the log show the milter instead of spamd?
spamass-milter is merely a protocol adapter. The real work
is done elsewhere. http://linux.die.net/man/1/spamass-milter
> And now that this is working, how do I reject incoming messages
> based on their score (fo
spamd
> child (perl)
> root 52035 0.0 0.5 30704 9608 ?? Is4Feb15 0:10.49
> /usr/local/sbin/spamass-milter -f -p /var/run/spamass-milter.sock
>
> And messages are getting tagged as spam.
>
> Feb 12 13:17:10 mail spamd[32769]: prefork: child states: II
/spamass-milter -f -p /var/run/spamass-milter.sock
And messages are getting tagged as spam.
Feb 12 13:17:10 mail spamd[32769]: prefork: child states: II
Feb 12 13:17:10 mail spamd[32770]: spamd: connection from localhost [::1]:35582
to port 783, fd 6
Feb 12 13:17:10 mail spamd[32770]: spamd
Am 19.03.2013 18:37, schrieb The Doctor:
>
>
> Try spamass-milter on Postfix 2.10
>
> Using http://www.malgouyres.fr/linux/spamass-milter_postfix_en.html
>
> and got
>
> Mar 19 11:25:16 doctor spamass-milter[23742]: Could not retrieve sendmail
>
Try spamass-milter on Postfix 2.10
Using http://www.malgouyres.fr/linux/spamass-milter_postfix_en.html
and got
Mar 19 11:25:16 doctor spamass-milter[23742]: Could not retrieve sendmail macro
"i"!. Please add it to confMILTER_MACROS_ENVFROM for better spamassassin
results
Mar 1
Victor Duchovni:
> On Tue, Jan 25, 2011 at 11:48:04AM -0500, Jerry wrote:
>
> > Using Postfix (2.8-20101108) from the FreeBSD ports system, I still
> > receive this warning:
>
> 2.8-20101108 is not 2.8.0. The biopair layer was removed later in the
> development cycle.
I removed the biopair layer
On Tue, Jan 25, 2011 at 11:48:04AM -0500, Jerry wrote:
> Using Postfix (2.8-20101108) from the FreeBSD ports system, I still
> receive this warning:
2.8-20101108 is not 2.8.0. The biopair layer was removed later in the
development cycle.
> Jan 25 11:37:36 scorpio postfix/smtp[20514]: warning:
>
On Tue, 25 Jan 2011 09:33:00 -0500 (EST)
Wietse Venema articulated:
> J4:
> > Jan 25 13:54:20 logout postfix/smtpd[21183]: warning:
> > network_biopair_interop: error writing 53 bytes to the network:
> > Broken pipe
>
> The remote host disconnected before the Postfix SMTP server sent
> its res
Am 25.01.2011 15:33, schrieb Wietse Venema:
With Postfix 2.8 I removed the network_biopair_interop
layer, so it won't report network_biopair_interop errors anymore.
thanks, Wietse.
Postfix 2.8 I removed the network_biopair_interop
> layer, so it won't report network_biopair_interop errors anymore.
>
>> MILTER QUESTION
>> 2) The spamass-milter used to fire during the SMTP session, yet
>> checking the logs, I see that it does not anymore (grep -i
won't report network_biopair_interop errors anymore.
> MILTER QUESTION
> 2) The spamass-milter used to fire during the SMTP session, yet
> checking the logs, I see that it does not anymore (grep -i milter
> /var/loh/mail.* gives nothing).
That could be a spamass-milter question. Pos
error message and know what action should be
taken (if any).
MILTER QUESTION
2) The spamass-milter used to fire during the SMTP session, yet
checking the logs, I see that it does not anymore (grep -i milter
/var/loh/mail.* gives nothing).
The main.cf has :
milter_default_action = tempfail
Wolfgang Zeikat:
> Wietse Venema wrote:
>
> >> Is it possible to exclude mails from
> >> smtpd_milters = unix:/var/run/spamass.sock?
> >
> > There is no such option.
>
> OK. Thank you for the bad news ;)
It is not a good idea to simply turn off Milters in the middle of
an SMTP session, because
Wietse Venema wrote:
Is it possible to exclude mails from
smtpd_milters = unix:/var/run/spamass.sock?
There is no such option.
OK. Thank you for the bad news ;)
Would we have that option if we use an
smtpd_proxy_filter,
i.e. spampd?
Regards,
wolfgang
Wolfgang Zeikat:
> We are experimenting with spamass-milter to check mails and reject them
> if a configured spamassassin score is reached. That part works, but the
> milter is (of course) applied to all mails after our
> smtpd_recipient_restrictions lookups return OK for the re
We are experimenting with spamass-milter to check mails and reject them
if a configured spamassassin score is reached. That part works, but the
milter is (of course) applied to all mails after our
smtpd_recipient_restrictions lookups return OK for the recipient, i.e.
also postmaster@ for whom
39 matches
Mail list logo