On 19.11.15 14:29, Elod G wrote:
So I understand the milter protocol requires the own local received
header to not be present, and Postfix hides it from milters
Am 19.11.2015 um 14:01 schrieb Matus UHLAR - fantomas:
the milter protocol requires mail to be passed as received - without
locally
On Thu, 19 Nov 2015 09:59:57 +0100
Matus UHLAR - fantomas wrote:
> On 18.11.15 22:36, RW wrote:
> >That suggests that the SPF header and the
> >Received header are in the opposite order in the milter copy
> >compared with the final delivered version.
>
> From what I know, the locally added Rece
Am 19.11.2015 um 14:01 schrieb Matus UHLAR - fantomas:
On 19.11.15 14:29, Elod G wrote:
So I understand the milter protocol requires the own local received
header to not be present, and Postfix hides it from milters
the milter protocol requires mail to be passed as received - without
locally
On 11/19/2015 02:01 PM, Matus UHLAR - fantomas wrote:
On 19.11.15 14:29, Elod G wrote:
So I understand the milter protocol requires the own local received
header to not be present, and Postfix hides it from milters
the milter protocol requires mail to be passed as received - without
locally
ad
On 19.11.15 14:29, Elod G wrote:
So I understand the milter protocol requires the own local received
header to not be present, and Postfix hides it from milters
the milter protocol requires mail to be passed as received - without locally
added data (including local Received: header).
. Howeve
I meant to say spamassasin IN a milter architecture. I understand your
point.
On 11/19/2015 14:43, Axb wrote:
> On 11/19/2015 01:29 PM, Elod G wrote:
>> spamassassin as a milter architecture
>
> SpamAssassin is not a milter.
>
> spamass-milter is third party , rather dated.
>
> If you need to han
On 11/19/2015 01:29 PM, Elod G wrote:
spamassassin as a milter architecture
SpamAssassin is not a milter.
spamass-milter is third party , rather dated.
If you need to handle filtering with SA during the SMTP sessions there
are probably more adequate/compatible/supported options.
So I understand the milter protocol requires the own local received
header to not be present, and Postfix hides it from milters. However, SA
considers internal only headers above the first Received. So, the
spamassassin as a milter architecture makes passing internal headers to
SA impossible.
Elod
Am 19.11.2015 um 11:33 schrieb Benny Pedersen:
Reindl Harald skrev den 2015-11-19 11:28:
how is SA playing a whole MTA better than a cached SPF lookup?
irrelvant
no - it is not irrelevant
"if spamc would be supporing smtp it would not depend on problems in
milters" means you implement a
Am 19.11.2015 um 11:30 schrieb Benny Pedersen:
Reindl Harald skrev den 2015-11-19 11:18:
oh yeah let include a complete MTA in spamassassin to solve a
non-existing problem since SPF in SA works out-of-the-box
did you fix all bugs ?, i can still count more then one bug in
bz.apache.org for s
Reindl Harald skrev den 2015-11-19 11:28:
how is SA playing a whole MTA better than a cached SPF lookup?
irrelvant
just saying "yes" is worthless to trolling
you dont care anyway, troll
Reindl Harald skrev den 2015-11-19 11:18:
oh yeah let include a complete MTA in spamassassin to solve a
non-existing problem since SPF in SA works out-of-the-box
did you fix all bugs ?, i can still count more then one bug in
bz.apache.org for spf
you gain nothing with SA speaking SMTP exce
Am 19.11.2015 um 11:27 schrieb Benny Pedersen:
Matus UHLAR - fantomas skrev den 2015-11-19 11:11:
is that really better than having spamassassin do another SPF lookup?
yes
how is SA playing a whole MTA better than a cached SPF lookup?
just saying "yes" is worthless to trolling
signatur
Am 19.11.2015 um 11:25 schrieb Reindl Harald:
Am 19.11.2015 um 11:22 schrieb Elod G:
Looking at the spamass-milter source code I see this:
if (assassin->numrcpt() == 0)
{
/* Send the envelope headers as X-Envelope-From: and
X-Envelope-To: so that SpamAssassin ca
Matus UHLAR - fantomas skrev den 2015-11-19 11:11:
is that really better than having spamassassin do another SPF lookup?
yes
Am 19.11.2015 um 11:22 schrieb Elod G:
Looking at the spamass-milter source code I see this:
if (assassin->numrcpt() == 0)
{
/* Send the envelope headers as X-Envelope-From: and
X-Envelope-To: so that SpamAssassin can use them in its
whitelist checks.
Looking at the spamass-milter source code I see this:
if (assassin->numrcpt() == 0)
{
/* Send the envelope headers as X-Envelope-From: and
X-Envelope-To: so that SpamAssassin can use them in its
whitelist checks. Also forge as complete a dummy
Recei
Am 19.11.2015 um 11:02 schrieb Benny Pedersen:
Matus UHLAR - fantomas skrev den 2015-11-19 10:36:
in any case, spamass-milter will prepend Received: header before all
other
headers, including Received-SPF added by your policy service, which
means SA
won't trust it...
using spampd here since
Matus UHLAR - fantomas skrev den 2015-11-19 10:36:
in any case, spamass-milter will prepend Received: header before
all other
headers, including Received-SPF added by your policy service, which
means SA
won't trust it...
On 19.11.15 11:02, Benny Pedersen wrote:
using spampd here since it have
Matus UHLAR - fantomas skrev den 2015-11-19 10:36:
in any case, spamass-milter will prepend Received: header before all
other
headers, including Received-SPF added by your policy service, which
means SA
won't trust it...
using spampd here since it have not solved it my self yet here, just
s
Matus UHLAR - fantomas skrev den 2015-11-19 09:59:
From what I know, the locally added Received: header is not visible in
milter and the spamass-milter must fake it. Therefore, if Received-SPF
exists, the Received: is prepended before it, which explains the issue.
On 19.11.15 10:13, Benny Peder
On 11/19/2015 10:59, Matus UHLAR - fantomas wrote:
From what I know, the locally added Received: header is not visible in
milter and the spamass-milter must fake it. Therefore, if Received-SPF
exists, the Received: is prepended before it, which explains the issue.
On 19.11.15 11:15, Elod G wrot
So that's why I am seeing headers that are not present in the delivered
e-mail. ALL-INTERNAL has three headers: a simple Received, an
X-Envelope-To, and an X-Envelope-From. All three seem made up.
What a dick move from spamass-milter's part. I have to read up on it a bit.
Elod G
On 11/19/2015 10:
Matus UHLAR - fantomas skrev den 2015-11-19 09:59:
From what I know, the locally added Received: header is not visible in
milter and the spamass-milter must fake it. Therefore, if Received-SPF
exists, the Received: is prepended before it, which explains the issue.
check_policy_service is calle
On 18.11.15 22:36, RW wrote:
Do you mean that it works in the milter on new mail without a
pre-exiting Received-SPF header?
For it to work the SPF header presumably needs to be above the MX
Received header. From what you've written it works correctly when
rescanning delivered mail, but not in th
On Wed, 18 Nov 2015 16:10:13 +0200
Elod G wrote:
> I am using Spamassassin 3.4.0 called by spamass-milter with Postfix
> 2.11 on Ubuntu 14.04. I can't get SA to recognize Auth-results
> headers added by policyd-spf, a Postfix policy server.
> If I run SA with -D -lint with the message source (as r
Am 18.11.2015 um 16:12 schrieb Elod G:
I belive policyd-spf replaces existing headers with its own. I got burnt
once already with header_checks, it's a no go.
Getting back to the subject, I agree, it's probably not a big
performance impact doing the check twice, especially since the DNS query
I belive policyd-spf replaces existing headers with its own. I got burnt
once already with header_checks, it's a no go.
Getting back to the subject, I agree, it's probably not a big
performance impact doing the check twice, especially since the DNS query
is cached by the local resolver. I am wonde
Am 18.11.2015 um 15:49 schrieb Kevin Golding:
So returning to your original questioning, changing to checking ALL
instead of ALL-INTERNAL would result in checking against headers added
by other relays and would presumably be spoofable. You may feel happy
with this if you can ensure that any Rec
On Wed, 18 Nov 2015 14:37:38 -, Elod G wrote:
The SPF plugin is already checking for the the standard Received-SPF and
Authentication-Results headers. Those headers are added by the SPF
policy server and used by other milters. It is just the SA milter that
is not finding them because of a m
The SPF plugin is already checking for the the standard Received-SPF and
Authentication-Results headers. Those headers are added by the SPF
policy server and used by other milters. It is just the SA milter that
is not finding them because of a mis-configuration, I believe.
Elod G
On 11/18/2015 16
Am 18.11.2015 um 15:27 schrieb Elod G:
Policyd is not doing any rejection. While it is a policy server, it is
configured to always permit and its only purpose is to add SPF
authentication headers. These are later parsed by the opendmarc milter.
It would be nice, if SA too would parse them and no
On 11/18/2015 03:27 PM, Elod G wrote:
Policyd is not doing any rejection. While it is a policy server, it is
configured to always permit and its only purpose is to add SPF
authentication headers. These are later parsed by the opendmarc milter.
It would be nice, if SA too would parse them and not
Policyd is not doing any rejection. While it is a policy server, it is
configured to always permit and its only purpose is to add SPF
authentication headers. These are later parsed by the opendmarc milter.
It would be nice, if SA too would parse them and not redo the SPF
validation.
I am still coun
Am 18.11.2015 um 15:10 schrieb Elod G:
I am using Spamassassin 3.4.0 called by spamass-milter with Postfix 2.11
on Ubuntu 14.04. I can't get SA to recognize Auth-results headers added
by policyd-spf, a Postfix policy server
why? SA has it's own SPF rules - the job of the policyd is a hardfail
I am using Spamassassin 3.4.0 called by spamass-milter with Postfix 2.11
on Ubuntu 14.04. I can't get SA to recognize Auth-results headers added
by policyd-spf, a Postfix policy server.
If I run SA with -D -lint with the message source (as received) piped
into it, it works and the headers are recog
36 matches
Mail list logo
