Wietse Venema writes:
Unless I am mistaken, this implements the same functionality as the
pipemap table. It queries tables in sequence, not in parallel.
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Thanks,
Roel
Add support for
Hello there again Michael,
I think you nailed my issue.
Let me quote a little from documentation of GTUBE for clearance. It stands
for Generic Test for Unsolicited Bulk Email. /quote,/ It's been agreed upon
a single string of characters that should always set off any spam detectors.
The GTUBE
Am 12.09.2014 um 09:21 schrieb Den:
Hello there again Michael,
I think you nailed my issue.
Let me quote a little from documentation of GTUBE for clearance. It stands
for Generic Test for Unsolicited Bulk Email. /quote,/ It's been agreed upon
a single string of characters that should
in context of the spam detector you need to name it
GTUBE not supported by postfix filters makes no sense without naming the
filter
Right. It's spamassassin. Thanks.
don't do that - depending on...
I am not sure I follow. Don't do what? I am saying here that my header
checks do not work and
Am 12.09.2014 um 10:13 schrieb Den:
in context of the spam detector you need to name it
GTUBE not supported by postfix filters makes no sense without naming the
filter
Right. It's spamassassin. Thanks.
don't do that - depending on...
I am not sure I follow. Don't do what?
run the
Hi Viktor,
Am 11.09.2014 um 16:04 schrieb Viktor Dukhovni:
Your PCAP files should demonstrate repeated retransmission of data,
are the ACKs you're sending confirming receipt of packets that are
sent repeatedly? In that case your ACKs are getting lost? Is
there a sequence number gap in the
Wietse:
You can expose the on-the-wire form with a header_checks rule:
/^Subject:/ WARN
That will log each header.
Wietse
Could you please, elaborate a little further how to put it to work in
practice? Looks like it works successively and any rule that goes after
/^Subject:/ WARN
Hi Wietse,
Am 11.09.2014 um 17:10 schrieb Wietse Venema:
That increases my suspicion of a data-dependent error - some marginal
cable/switch/router, perhaps some middle box with a memory bit error
that requires a power cycle to clear the problem. If the problem is
caused by crosstalk defect,
Hi Hannes,
Am 11.09.2014 um 20:48 schrieb Hannes Erven:
I remember a possibly similar situation back in 2008... the culprit was a
not-fully-up-to-date Cisco ASA firewall that corrupted TCP SACK fields and
hence had the remote site send RSET.
Anyways on our end the connection seemed to
Hi Mark,
Am 11.09.2014 um 22:59 schrieb L. Mark Stone:
Any chance there is a UTM device in the email stream?
Possible, but I wouldn't know. This is a rented rootserver in some data center.
I don't know their topology, and they probably wouldn't tell me even if I asked.
We see lots of these
Hi Matthias, Postfix-Users,
(resend, had sent from wrong address and was silently being dropped by
majordomo)
On 1 Sep 2014, at 4:51 pm, Matthias Andree matthias.and...@gmx.de wrote:
I’m using sender_canonical_maps to ensure that my envelope addresses comply
with SPF policies and also allow
run the spamfilter after queue
http://www.postfix.org/MILTER_README.html
Thanks. Will double-check on that. Chances also are that I missed something
too or I might as well have to try to switch to these milters as running SA
daemonized doesn't work. I posted my main.cf and my master.cf a bit
Am 12.09.2014 um 11:29 schrieb Den:
run the spamfilter after queue
http://www.postfix.org/MILTER_README.html
Thanks. Will double-check on that. Chances also are that I missed something
too or I might as well have to try to switch to these milters as running SA
daemonized doesn't work. I
you have 3 processes as part of the game:
* spamd running as daemon and listening on TCP
* spamass-milter running as deamon and listening on a unix socket
* postfix talks to spamass-milter via the socket
* spamass-milter takls to spamd via TCP
* spamd has prefroking childs for the scanning
*
Den:
/^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
PLease look for warnings like the following in your maillog file:
postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line 1:
unknown regexp option D: skipping this rule
Wietse
Wietse:
/^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
Please look for warnings like the following in your maillog file:
postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line
1: unknown regexp option D: skipping this rule
Wietse
Thank you. I will try it and go on with
Am 12.09.2014 um 14:23 schrieb Den:
/^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
/^Subject:/WARN
that is without having anything before discard*spam*. Is that correct?
I also begin to think that there is a regexp issue somewhere. Is it actually
possible
Den:
Does it work successively as PHP does?
Postfix works as documented in regexp_table(5) and pcre_table(5),
i.e. each query stops at the first matching rule.
Postfix also works as documented in header_checks(5), i.e. DISCARD
causes Postfix to ignore the remainder of the message.
Then my
li...@rhsoft.net
no but the regexp is entirely wrong
the subject starts with [SPAM] so no need for .*
{5} - what is that supposed to do?
avoid a * in the action for safety
/^Subject: \[SPAM.*/ DISCARD SPAM
Strongly disagree. Regexp is 100% correct because:
1. postmap -q
Am 12.09.2014 um 14:53 schrieb Den:
li...@rhsoft.net
no but the regexp is entirely wrong
the subject starts with [SPAM] so no need for .*
{5} - what is that supposed to do?
avoid a * in the action for safety
/^Subject: \[SPAM.*/ DISCARD SPAM
Strongly disagree. Regexp is 100% correct
On Mon, Sep 01, 2014 at 02:57:51PM +1000, Valdemar Jakobsen wrote:
The problem I am having is that any mail that is submitted locally
on the gateway mail servers (Ubuntu, /usr/bin/mail - tested all 3
packages providing /usr/bin/mail) behaves as if sender_canonical_classes
is not configured
Viktor Dukhovni:
# /etc/postfix/sender_canonical.regexp (excerpt)
# rewrite all addresses to any variant of (*.|)mydomain.com(|.*) to
realuser+user%internal_f...@mydomain.com
/^(.*)@(.+\.mydomain\.com(\.[^\.]*)?)$/
realuser+${1}%${2}@mydomain.com
Boldly claiming your domain
On Thu, Sep 11, 2014 at 10:09:34PM -0400, D'Arcy J.M. Cain wrote:
On Thu, 11 Sep 2014 16:38:45 -0500
Noel Jones njo...@megan.vbhcs.org wrote:
Is it possible that mail arriving locally is bypassing the
milter?
postconf -n attached. I only removed the tls lines.
Does
On Fri, Sep 12, 2014 at 10:36:51AM +0200, Sean Durkin wrote:
If it's a middle box somewhere along the way, that's even worse.
Even more different people potentially involved...
I would rent a backup MX server (deploy identical anti-spam policies,
and lists of valid recipients, ...) at a
quote author=li...@rhsoft.net
SA default is
rewrite_header Subject [SPAM]
why don't you just stick with defaults and after all...
Postfix version 2.9.6. My SA 3.3.2 (2011-06-06) default says rewrite_header
Subject *SPAM* and I do stick to its defaults.
On the other hand there is
On Fri, Sep 12, 2014 at 08:41:28AM +0200, Roel van Meer wrote:
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Have not read the patch in detail. Quick note though, in databases
JOIN is rather different from UNION. The pipemap is a JOIN,
On 9/12/2014 9:17 AM, /dev/rob0 wrote:
On Thu, Sep 11, 2014 at 10:09:34PM -0400, D'Arcy J.M. Cain wrote:
On Thu, 11 Sep 2014 16:38:45 -0500
Noel Jones njo...@megan.vbhcs.org wrote:
Is it possible that mail arriving locally is bypassing the
milter?
postconf -n attached. I only removed the
Viktor Dukhovni:
On Fri, Sep 12, 2014 at 08:41:28AM +0200, Roel van Meer wrote:
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Have not read the patch in detail. Quick note though, in databases
JOIN is rather different from UNION.
On Fri, Sep 12, 2014 at 11:36:18AM -0400, Wietse Venema wrote:
Viktor Dukhovni:
On Fri, Sep 12, 2014 at 08:41:28AM +0200, Roel van Meer wrote:
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Have not read the patch in detail.
On Fri, 12 Sep 2014 09:17:19 -0500
/dev/rob0 r...@gmx.co.uk wrote:
On Thu, Sep 11, 2014 at 10:09:34PM -0400, D'Arcy J.M. Cain wrote:
On Thu, 11 Sep 2014 16:38:45 -0500
Is there something specific I should be looking at. I did check
I was thinking, as I bet Noel was also:
Viktor Dukhovni:
On Fri, Sep 12, 2014 at 11:36:18AM -0400, Wietse Venema wrote:
Viktor Dukhovni:
On Fri, Sep 12, 2014 at 08:41:28AM +0200, Roel van Meer wrote:
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Have not
On Sep 5, 2014, at 2:36 PM, Edwin Marqe edwinma...@gmail.com wrote:
Hi,
I've been doing some tests recently regarding to the EHLO command, and
I was wondering whether the below detailed behavior is the expected
one or not.
I have this in my Postfix config:
smtpd_helo_restrictions =
Am 12.09.2014 um 21:49 schrieb Philip Prindeville:
However, any time I connect via telnet to this server and specify
*any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions
won't trigger.
This is both legal and reasonable.
If you’re a DHCP’d host running inside a NATting
Hello there Postfix experts!
I was just wondering what exactly does the line below do? Could anybody
comment / advise, please? It does not actually check and *confirm* that the
code, syntax, etc. of any regexp present in /filter/ (example) is 100%
correct does it?
postmap -q
34 matches
Mail list logo
