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 s
>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 wor
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 w
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 t
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:/
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 defec
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 st
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 e
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 wrote:
>> I’m using sender_canonical_maps to ensure that my envelope addresses comply
>> with SPF policies and also allow for a valid bounce
>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 ear
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 wor
>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
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
> poss
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 be
>"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 "/^Subject:.
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. Regex
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
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 wrote:
> > > Is it possible that mail arriving locally is bypassing the
> > > milter?
> > >
> > > postconf -n attached. I only removed the tls lines.
> > >
> >
> > Does reviewin
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 diffe
>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
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 wrote:
Is it possible that mail arriving locally is bypassing the
milter?
postconf -n attached. I only removed the tl
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 f
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 pa
On Fri, 12 Sep 2014 09:17:19 -0500
/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
> > Is there something specific I should be looking at. I did check
>
> I was thinking, as I bet Noel was also:
>
> http://www.postfix.o
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
On Sep 5, 2014, at 2:36 PM, Edwin Marqe 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 =
>permit_m
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 NATtin
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 "/^Subject:.*\*{5}SP
On Fri, Sep 12, 2014 at 10:12:38PM -0700, Den wrote:
> 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?
>
34 matches
Mail list logo
