You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Reindl Harald <h....@thelounge.net> on 2015/01/05 18:52:41 UTC
SPF_HELO_PASS,SPF_NONE
how can "SPF_HELO_PASS,SPF_NONE" fire both?
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 05.01.2015 um 19:22 schrieb Derek Diget:
> On Jan 5, 2015 at 18:52 +0100, Reindl Harald wrote:
> =>how can "SPF_HELO_PASS,SPF_NONE" fire both?
>
> Just by going off the names...
>
> The domain presented in the HELO (RFC5321.HELO) command
> passed the SPF check_host() test while the domain used in the mail from
> (RFC5321.MailFrom) command didn't have a SPF record.
>
> S1: 220 mx.example.com ESMTP
> C1: EHLO smtp.example.net
> S2: 250-mx.example.com Hello...pleased to meet you
> C2: MAIL FROM:<se...@example.net>
> S2: 250 Sender OK
> C3: RCPT TO:<re...@example.com>
> S3: 250 Recipient OK
> C4: DATA
>
> So the SPF_HELO_PASS is testing the SPF record for smtp.example.net
> (line C1 above), while the SPF_NONE is testing the domain (example.net)
> used in the "MAIL FROM" (line C2).
so far clear, but i am in favor of *not* issue *any* positive score if
the sending domain just don't have a SPF record which is the case if
SPF_HELO *and* SPF_NONE both hits
@domaintechnik.at don't publish SPF regardless over what server it was
sent and so i see no valid reason for a positive score of outgoing mails
over host5.ssl-gesichert.at[213.145.228.32]
> Remember that SPF checks both the HELO name presented as well as the
> domain used in the Mail From command. (Which is why "you" should have a
> simple "v=spf1 a -all" record for the A record of your sending systems
> as well as not having your sending systems HELO as your top level
> domain.)
nope, define IP or network ranges of the systems allowed to send and you
are done, it works properly and saves dns requests or at least
additional traffic (faced all sorts of troubles in the past with
hostnames in SPF in case of network troubles here and there and never
had a single SPF issue after switch all domains to ipv4 notation)
thelounge.net. 86400 IN TXT "v=spf1
ip4:91.118.73.0/24 ip4:89.207.144.27 -all"
rhsoft.net. 86400 IN TXT "v=spf1
ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85
ip4:85.124.176.243 -all"
Re: SPF_HELO_PASS,SPF_NONE
Posted by Derek Diget <de...@wmich.edu>.
On Jan 5, 2015 at 18:52 +0100, Reindl Harald wrote:
=>how can "SPF_HELO_PASS,SPF_NONE" fire both?
Just by going off the names...
The domain presented in the HELO (RFC5321.HELO) command
passed the SPF check_host() test while the domain used in the mail from
(RFC5321.MailFrom) command didn't have a SPF record.
S1: 220 mx.example.com ESMTP
C1: EHLO smtp.example.net
S2: 250-mx.example.com Hello...pleased to meet you
C2: MAIL FROM:<se...@example.net>
S2: 250 Sender OK
C3: RCPT TO:<re...@example.com>
S3: 250 Recipient OK
C4: DATA
So the SPF_HELO_PASS is testing the SPF record for smtp.example.net
(line C1 above), while the SPF_NONE is testing the domain (example.net)
used in the "MAIL FROM" (line C2).
Remember that SPF checks both the HELO name presented as well as the
domain used in the Mail From command. (Which is why "you" should have a
simple "v=spf1 a -all" record for the A record of your sending systems
as well as not having your sending systems HELO as your top level
domain.)
--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-06 01:31:
> my whole point is when the sending domain don't have a SPF record and
> so "SPF_NONE" correctly hits all meta-rules in context of SPF should
> not fire up at all
its irrelevant since helo testing and envelope from is diffrence tests
there is no dependice even
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 01:27 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-01-06 00:41:
>
>> Benny i got more then you imagine after maintain some hundret domains
>> for over a decade from registry level over DNS to email and
>> webservices, please get out of my sight
>
> fair, helo is more important in spf mta checkers then in sa spf checkers
>
> but the possible faked helo mta can be tested without spf since mta can
> distinct client ips and helo names in a hash table
my whole point is when the sending domain don't have a SPF record and so
"SPF_NONE" correctly hits all meta-rules in context of SPF should not
fire up at all
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-06 00:41:
> Benny i got more then you imagine after maintain some hundret domains
> for over a decade from registry level over DNS to email and
> webservices, please get out of my sight
fair, helo is more important in spf mta checkers then in sa spf checkers
but the possible faked helo mta can be tested without spf since mta can
distinct client ips and helo names in a hash table
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 00:10 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-01-05 23:13:
>> Am 05.01.2015 um 23:07 schrieb Benny Pedersen:
>
>> @domaintechnik.at don't publish SPF regardless over what server it was
>> sent and so i see no valid reason for a positive score of outgoing
>> mails over host5.ssl-gesichert.at[213.145.228.32]
>
> helo is mta, domain is domain owner
>
> a single ip can have more then one domain, domain in mta can be diffrent
> helo domain then envelope from
>
> have you got it now?
Benny i got more then you imagine after maintain some hundret domains
for over a decade from registry level over DNS to email and webservices,
please get out of my sight
Re: SPF_HELO_PASS,SPF_NONE
Posted by RW <rw...@googlemail.com>.
On Mon, 05 Jan 2015 23:13:15 +0100
Reindl Harald wrote:
> so what - the domain and the subdomain publish SPF
> as example "whoever@domaintechnik.at" don't and hence there is no
> justification for hit "score SPF_HELO_PASS -0.001"
>
Ah, when I previously pointed out that it didn't have a positive score
I assumed you must have a custom score.
If you mean why does it have a non-zero score then the reason is that
-0.001 and 0.001 are the standard nominal scores assigned to
informational rules.
> @domaintechnik.at don't publish SPF regardless over what server it
> was sent and so i see no valid reason for a positive score of
> outgoing mails over host5.ssl-gesichert.at[213.145.228.32]
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-05 23:13:
> Am 05.01.2015 um 23:07 schrieb Benny Pedersen:
> @domaintechnik.at don't publish SPF regardless over what server it was
> sent and so i see no valid reason for a positive score of outgoing
> mails over host5.ssl-gesichert.at[213.145.228.32]
helo is mta, domain is domain owner
a single ip can have more then one domain, domain in mta can be diffrent
helo domain then envelope from
have you got it now ?
RE: SPF_HELO_PASS,SPF_NONE
Posted by Marieke Janssen <mj...@myguard.nl>.
>without a SPF record a domain don't have anything but SPF_NONE
Doesn't that depend on the HELO of the server? If they HELO'd with another name which does have a record it would explain it.
(pure speculation, in your posts I didn't see where they HELO'd with, or I have missed it).
SPF_HELO_PASS has nothing to do with the sending domain, but with the name the incoming mailserver identifies itself with HELO in the initial connection, (which can be really anything but should be valid and preferably their own hostname).
Can you dig up the HELO/EHLO from your logfiles or from the headers of the mail in question?
/MJ
-----Oorspronkelijk bericht-----
Van: Reindl Harald [mailto:h.reindl@thelounge.net]
Verzonden: maandag 5 januari 2015 23:13
Aan: users@spamassassin.apache.org
Onderwerp: Re: SPF_HELO_PASS,SPF_NONE
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 05.01.2015 um 23:07 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-01-05 22:58:
>
>> well, the sender don't publish SPF at all
>
> helo is not a spf policy, its a spf helo policy, confused ?, me 2 :=)
without a SPF record a domain don't have anything but SPF_NONE
> dig duggi.junc.org txt
> dig junc.org txt
>
> see not one spf txt, but 2
>
> hope that covers it for others aswell
so what - the domain and the subdomain publish SPF
as example "whoever@domaintechnik.at" don't and hence there is no
justification for hit "score SPF_HELO_PASS -0.001"
duggi.junc.org. 3597 IN TXT "v=spf1 a -all"
junc.org. 3600 IN TXT "v=spf1
ip4:80.162.68.52/30 -all"
@domaintechnik.at don't publish SPF regardless over what server it was
sent and so i see no valid reason for a positive score of outgoing mails
over host5.ssl-gesichert.at[213.145.228.32]
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-05 22:58:
> well, the sender don't publish SPF at all
helo is not a spf policy, its a spf helo policy, confused ?, me 2 :=)
dig duggi.junc.org txt
dig junc.org txt
see not one spf txt, but 2
hope that covers it for others aswell
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 07.01.2015 um 16:27 schrieb RW:
> On Wed, 07 Jan 2015 15:01:56 +0100
> Reindl Harald wrote:
>>
>> Am 07.01.2015 um 14:47 schrieb Matus UHLAR - fantomas:
>>> what if there would be SPF_HELO_FAIL?
>>
>> SA would not be called at all
>>
>>> Maybe you could disable checking SPF_HELO, but some of us don't
>>> want that.
>>
>> the question is who are "some" and who are the majority
>> you can even socre "SPF_HELO_SOFTFAIL" and "SPF_HELO_FAIL" *without*
>> end in "SPF_HELO_PASS,SPF_NONE"
>>
>> meta __SPF_FULL_PASS 0
>> meta __SPF_RANDOM_SENDER 0
>> score SPF_HELO_PASS 0
>> score SPF_NONE 0.05
>> score SPF_PASS -0.05
>> score SPF_HELO_SOFTFAIL 0.5
>> score SPF_HELO_FAIL 1.5
>>
>>> You can _NOT_ know if SPF HELO fails before you do the test
>>
>> if it fails the message get rejected before SA
>
> Your original point was that it's technically incorrect to perform an
> spf helo test in the absence of an envelope policy. And you
> specifically made that point about my example involving an
> SPF_HELO_FAIL.
>
> In any case the test still has to be run for SPF_HELO_SOFTFAIL, so you
> don't avoid an spf test by suppressing SPF_HELO_PASS.
if i could change the dependencies i would do the whole test only if the
envelope-sender has a SPF record which is already in the local resolver
cache and that way save the test, avoid "SPF_HELO_PASS,SPF_NONE" and
also skip the two meta-tests
"SPF_FULL_PASS" as example is impossible without a envelope policy
>> what i want to avoid is such envelope-independent tests giving a
>> message pointless positive karma
>
> For the umpteenth time it's a nominal score to make sure that the rule
> is run and can be seen in logs and headers. It's not "karma" and it
> doesn't "revoke the intended little penalty for SPF_NONE" because that's
> another nominal rule score. A lot of rules have nominal scores, only a
> handful are negative.
>
> When was the last time you saw a classification fail due to nominal
> scores
likely not, but i can't know about every mail if it reached the
milter-reject caused by the summary of tests
the "T_RP_MATCHES_RCVD" as it was non-testing as "RP_MATCHES_RCVD" gave
indeed false negatives multiple times as well some DNSWL was or are too
friendly scored
Re: SPF_HELO_PASS,SPF_NONE
Posted by RW <rw...@googlemail.com>.
On Wed, 07 Jan 2015 15:01:56 +0100
Reindl Harald wrote:
>
> Am 07.01.2015 um 14:47 schrieb Matus UHLAR - fantomas:
> > what if there would be SPF_HELO_FAIL?
>
> SA would not be called at all
>
> > Maybe you could disable checking SPF_HELO, but some of us don't
> > want that.
>
> the question is who are "some" and who are the majority
> you can even socre "SPF_HELO_SOFTFAIL" and "SPF_HELO_FAIL" *without*
> end in "SPF_HELO_PASS,SPF_NONE"
>
> meta __SPF_FULL_PASS 0
> meta __SPF_RANDOM_SENDER 0
> score SPF_HELO_PASS 0
> score SPF_NONE 0.05
> score SPF_PASS -0.05
> score SPF_HELO_SOFTFAIL 0.5
> score SPF_HELO_FAIL 1.5
>
> > You can _NOT_ know if SPF HELO fails before you do the test
>
> if it fails the message get rejected before SA
Your original point was that it's technically incorrect to perform an
spf helo test in the absence of an envelope policy. And you
specifically made that point about my example involving an
SPF_HELO_FAIL.
In any case the test still has to be run for SPF_HELO_SOFTFAIL, so you
don't avoid an spf test by suppressing SPF_HELO_PASS.
> what i want to avoid is such envelope-independent tests giving a
> message pointless positive karma
For the umpteenth time it's a nominal score to make sure that the rule
is run and can be seen in logs and headers. It's not "karma" and it
doesn't "revoke the intended little penalty for SPF_NONE" because that's
another nominal rule score. A lot of rules have nominal scores, only a
handful are negative.
When was the last time you saw a classification fail due to nominal
scores.
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 07.01.2015 um 14:47 schrieb Matus UHLAR - fantomas:
> what if there would be SPF_HELO_FAIL?
SA would not be called at all
> Maybe you could disable checking SPF_HELO, but some of us don't want that.
the question is who are "some" and who are the majority
you can even socre "SPF_HELO_SOFTFAIL" and "SPF_HELO_FAIL" *without* end
in "SPF_HELO_PASS,SPF_NONE"
meta __SPF_FULL_PASS 0
meta __SPF_RANDOM_SENDER 0
score SPF_HELO_PASS 0
score SPF_NONE 0.05
score SPF_PASS -0.05
score SPF_HELO_SOFTFAIL 0.5
score SPF_HELO_FAIL 1.5
> You can _NOT_ know if SPF HELO fails before you do the test
if it fails the message get rejected before SA
what i want to avoid is such envelope-independent tests giving a message
pointless positive karma
> ...and if it's the policyd who checks for SPF on your system, it's too
> late to blame SA
for SPF hard fail SA comes too late, HELO-SPF SOFTFAIL is pointless
because it's testing anyways and a wrong default of policyd-spf was the
first false positive of a billing mail on day one with the new MX system
months ago (SPF_Not_Pass includes SOFTFAIL)
# HELO check rejection policy. Options are:
# HELO_reject = SPF_Not_Pass (default) - Reject if result not
Pass/None/Tempfail
Re: SPF_HELO_PASS,SPF_NONE
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Am 06.01.2015 um 21:31 schrieb Marieke Janssen:
>>>policyd-spf[11818]: None; identity=mailfrom; client-ip=213.145.228.32;
>>helo=host5.ssl-gesichert.at;
>>envelope-from=kundeninfo-return-1-***@domaintechnik.at; receiver=***
>>
>>$ dig txt +short host5.ssl-gesichert.at
>>"v=spf1 mx a ~all"
>>
>>Seems it works as it should?
On 06.01.15 21:41, Reindl Harald wrote:
>did you follow the thread?
it's particularly hard to follow this thread, since the same things get
repeated multiple times.
>i explained multiple times what annoys me and that SPF_HELO_PASS in
>context of a content-scanner is questionable for non-SPF envelopes
>
>* it is pointless
>* it revokes the intended little penalty for SPF_NONE
>* it is a skipable test
>* less pointless tests = better performance
>
>it has been already said anything to that topic including disable the
>test local
what if there would be SPF_HELO_FAIL ?
Maybe you could disable checking SPF_HELO, but some of us don't want that.
You can _NOT_ know if SPF HELO fails before you do the test.
...and if it's the policyd who checks for SPF on your system, it's too late to
blame SA.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The only substitute for good manners is fast reflexes.
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 21:31 schrieb Marieke Janssen:
>> policyd-spf[11818]: None; identity=mailfrom; client-ip=213.145.228.32;
> helo=host5.ssl-gesichert.at;
> envelope-from=kundeninfo-return-1-***@domaintechnik.at; receiver=***
>
> $ dig txt +short host5.ssl-gesichert.at
> "v=spf1 mx a ~all"
>
> Seems it works as it should?
did you follow the thread?
i explained multiple times what annoys me and that SPF_HELO_PASS in
context of a content-scanner is questionable for non-SPF envelopes
* it is pointless
* it revokes the intended little penalty for SPF_NONE
* it is a skipable test
* less pointless tests = better performance
it has been already said anything to that topic including disable the
test local
RE: SPF_HELO_PASS,SPF_NONE
Posted by Marieke Janssen <mj...@myguard.nl>.
> policyd-spf[11818]: None; identity=mailfrom; client-ip=213.145.228.32;
helo=host5.ssl-gesichert.at;
envelope-from=kundeninfo-return-1-***@domaintechnik.at; receiver=***
$ dig txt +short host5.ssl-gesichert.at
"v=spf1 mx a ~all"
Seems it works as it should?
/MJ
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 21:01 schrieb Matus UHLAR - fantomas:
> On 06.01.15 03:34, Reindl Harald wrote:
>> but you are far away from a SPF_HELO_PASS in context of the incoming
>> mail, frankly it's wrong and unrelated until the envelope sender is
>> not @helo-hostname
>
> please, post the problem mail header, thank you
i already statet the envelope @domaintechnik.at as well as the sending
host, see below and i don't talk about a "problem mail" - i just don't
accept "SPF_HELO_PASS,SPF_NONE" matching both - it's nonsense because i
could as well send with "somebody@domaintechnik.at" from our server to
match it too
as said i disabled that behavior in the meantime (while i am not happy
at all about the log-complaints until you disable related meta-tests too
instead have them also silent disabled by implicit dependencies)
meta __SPF_FULL_PASS 0
meta __SPF_RANDOM_SENDER 0
score SPF_HELO_PASS 0
policyd-spf[11818]: None; identity=mailfrom; client-ip=213.145.228.32;
helo=host5.ssl-gesichert.at;
envelope-from=kundeninfo-return-1-***@domaintechnik.at; receiver=***
spamd: result: . -3 -
BAYES_00,CUST_DNSWL_2,CUST_DNSWL_5,HTML_MESSAGE,SPF_HELO_PASS,SPF_NONE
scantime=5.8,size=230534,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=45413,mid=<54...@domaintechnik.at>,bayes=0.000000,autolearn=disabled
Re: SPF_HELO_PASS,SPF_NONE
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 06.01.15 03:34, Reindl Harald wrote:
>but you are far away from a SPF_HELO_PASS in context of the incoming
>mail, frankly it's wrong and unrelated until the envelope sender is
>not @helo-hostname
please, post the problem mail header, thank you.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.
Re: SPF_HELO_PASS,SPF_NONE
Posted by Dave Warren <da...@hireahit.com>.
On 2015-01-05 18:34, Reindl Harald wrote:
>
> if the envelope-domain has no SPF published and want to verify
> anything in context of HELO then you can check:
>
> * does the HELO hostname exist at all
> * does the IP match in both directions
>
> but you are far away from a SPF_HELO_PASS in context of the incoming
> mail, frankly it's wrong and unrelated until the envelope sender is
> not @helo-hostname
You might want to give the SPF specs another read, SPF can optionally
apply to the HELO/EHLO field.
https://tools.ietf.org/html/rfc7208#section-2.3, which reads in part:
> It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
> identity but also separately check the "HELO" identity by applying
> the check_host() function (Section 4 <https://tools.ietf.org/html/rfc7208#section-4>) to the "HELO" identity as the
> <sender>.
Since this applies to the HELO/EHLO field separately from the MAIL FROM
based checks, it is perfectly valid to have a SPF_HELO_PASS even if the
sending domain has no SPF policy. This is normal and expected behaviour.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 03:25 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-01-06 02:45:
>
>> i only say there can not be any sort of SPF PASS if the sending domain
>> don't have any SPF record at all - it's just wrong
>
> you dont get it :(
>
> sending domain is not in helo !
>
> giving up :(
you don't get it
if the envelope-domain has no SPF published and want to verify anything
in context of HELO then you can check:
* does the HELO hostname exist at all
* does the IP match in both directions
but you are far away from a SPF_HELO_PASS in context of the incoming
mail, frankly it's wrong and unrelated until the envelope sender is not
@helo-hostname
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 02:38 schrieb Derek Diget:
> On Tue, 6 Jan 2015 at 00:46 +0100, Reindl Harald wrote:
> =>Am 06.01.2015 um 00:06 schrieb RW:
> =>> On Mon, 05 Jan 2015 22:58:55 +0100
> =>> Reindl Harald wrote:
> =>> > Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
> =>> > > Reindl Harald skrev den 2015-01-05 18:52:
> =>> > > > how can "SPF_HELO_PASS,SPF_NONE" fire both?
> =>> > >
> =>> > > the above is 2 diff tests
> =>> >
> =>> > i know that by myself *but* if the sending domain does not publish
> =>> > any SPF policy then there should be no positive score for
> =>> > "SPF_HELO_PASS"
> =>>
> =>> It doesn't have a positive score:
> =>>
> =>> score SPF_HELO_PASS -0.001
> =>
> =>that is a positive score in context of "less spam probability" just because
> =>somebody sends a HELO command - frankly all day long zombies send HELO
> =>commands of known domains up to fake PTR's
>
> What does (not) having a SPF record and passing or failing have anything
> to do whether a message is spam or not?
did i say that?
i just said what i wrote in the subject is impossible at the same time
> SPF has to do with sender policy
> and is an anti-forgery tool. It is not a anti-spam tool. (A forged
> message may equal spam to most people, but a spam message does not always
> equal a forged message.) Similar idea with DKIM. Both allow the domain
> owner to assert ownership of a particular mail flow, but doesn't say
> ANYTHING about the domain owner. Again, how much spam mail passes both
> SPF and DKIM tests?
>
> Where SPF/DKIM enter into anti-spam is they tie an domain owner to mail
> flows such that a reputation system can build built.
i know that all
> Not sure about your mail flow, but we get LOTs of spam that passes (one
> or both) SPF checks.
which has nothing to do with the topic
> =>if the envelope domain don't push a SPF policy *only* NO_SPF should hit
>
> And back to the original question in post....see
> <http://www.openspf.org/FAQ/Common_mistakes#helo>
>
> To publish/not publish and what to publish in an SPF record discussion
> should probably be moved to spf-discuss or spf-help
> at <http://www.openspf.org/Forums>
NO it should not because i talk about which *spamassassin rules* hit and
why it is wrong - not mor, not less - the sending domain don't publish
any SPF record
Re: SPF_HELO_PASS,SPF_NONE
Posted by Derek Diget <de...@wmich.edu>.
On Tue, 6 Jan 2015 at 00:46 +0100, Reindl Harald wrote:
=>Am 06.01.2015 um 00:06 schrieb RW:
=>> On Mon, 05 Jan 2015 22:58:55 +0100
=>> Reindl Harald wrote:
=>> > Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
=>> > > Reindl Harald skrev den 2015-01-05 18:52:
=>> > > > how can "SPF_HELO_PASS,SPF_NONE" fire both?
=>> > >
=>> > > the above is 2 diff tests
=>> >
=>> > i know that by myself *but* if the sending domain does not publish
=>> > any SPF policy then there should be no positive score for
=>> > "SPF_HELO_PASS"
=>>
=>> It doesn't have a positive score:
=>>
=>> score SPF_HELO_PASS -0.001
=>
=>that is a positive score in context of "less spam probability" just because
=>somebody sends a HELO command - frankly all day long zombies send HELO
=>commands of known domains up to fake PTR's
What does (not) having a SPF record and passing or failing have anything
to do whether a message is spam or not? SPF has to do with sender policy
and is an anti-forgery tool. It is not a anti-spam tool. (A forged
message may equal spam to most people, but a spam message does not always
equal a forged message.) Similar idea with DKIM. Both allow the domain
owner to assert ownership of a particular mail flow, but doesn't say
ANYTHING about the domain owner. Again, how much spam mail passes both
SPF and DKIM tests?
Where SPF/DKIM enter into anti-spam is they tie an domain owner to mail
flows such that a reputation system can build built.
Not sure about your mail flow, but we get LOTs of spam that passes (one
or both) SPF checks.
=>if the envelope domain don't push a SPF policy *only* NO_SPF should hit
And back to the original question in post....see
<http://www.openspf.org/FAQ/Common_mistakes#helo>
To publish/not publish and what to publish in an SPF record discussion
should probably be moved to spf-discuss or spf-help
at <http://www.openspf.org/Forums>.
--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-06 02:45:
> i only say there can not be any sort of SPF PASS if the sending domain
> don't have any SPF record at all - it's just wrong
you dont get it :(
sending domain is not in helo !
giving up :(
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 03:00 schrieb John Hardin:
> On Tue, 6 Jan 2015, Reindl Harald wrote:
>>
>> Am 06.01.2015 um 02:27 schrieb John Hardin:
>>> On Tue, 6 Jan 2015, Reindl Harald wrote:
>>>
>>> > it's a matter of technical correctness
>>> > no SPF on the envelope domain, no SPF
>>> > > * OK: SPF_PASS
>>> > * OK: SPF_PASS,SPF_HELO_PASS
>>> > * OK: SPF_NONE
>>> > * WRONG: SPF_NONE,SPF_HELO_PASS
>>> > > one can argue about the severity but the correctness is out of
>>> question
>>>
>>> Are you assuming that the MTA will always be in the same domain as the
>>> envelope sender address when you say that?
>>
>> no - why should i?
>> we host 600 domains on the same MTA
>>
>> i only say there can not be any sort of SPF PASS if the sending domain
>> don't have any SPF record at all - it's just wrong
>
> And if the MTA's domain, which is in a different domain than the
> envelope sender, *does* have an SPF record, and the MTA is valid per
> that SPF record?
that don't say anything about the incoming mail because of it's envelope
sender with no SPF record - why?
there is no connection between the hosts SPF and the envelope senders
until the envelope publish SPF for his domain and lists that server there
> Are you saying the SPF for the MTA/HELO domain should not be checked at
> all if it is different than the envelope sender domain?
not in context of SPF
in that case you typically look if the HELO name exists at all and matches
but you need to be careful because way too much servers use
localhost.localdomain because a sloppy setup or a hostname from their
internal DNS zone not existing on the WAN (even with the same domain)
and hence things like
http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname are
asking for trouble (been there)
Re: SPF_HELO_PASS,SPF_NONE
Posted by John Hardin <jh...@impsec.org>.
On Tue, 6 Jan 2015, Reindl Harald wrote:
>
> Am 06.01.2015 um 02:27 schrieb John Hardin:
>> On Tue, 6 Jan 2015, Reindl Harald wrote:
>>
>> > it's a matter of technical correctness
>> > no SPF on the envelope domain, no SPF
>> >
>> > * OK: SPF_PASS
>> > * OK: SPF_PASS,SPF_HELO_PASS
>> > * OK: SPF_NONE
>> > * WRONG: SPF_NONE,SPF_HELO_PASS
>> >
>> > one can argue about the severity but the correctness is out of question
>>
>> Are you assuming that the MTA will always be in the same domain as the
>> envelope sender address when you say that?
>
> no - why should i?
> we host 600 domains on the same MTA
>
> i only say there can not be any sort of SPF PASS if the sending domain don't
> have any SPF record at all - it's just wrong
And if the MTA's domain, which is in a different domain than the envelope
sender, *does* have an SPF record, and the MTA is valid per that SPF
record?
Are you saying the SPF for the MTA/HELO domain should not be checked at
all if it is different than the envelope sender domain?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
An entitlement beneficiary is a person or special interest group
who didn't earn your money, but demands the right to take your
money because they *want* it. -- John McKay, _The Welfare State:
No Mercy for the Middle Class_
-----------------------------------------------------------------------
12 days until Benjamin Franklin's 309th Birthday
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 02:27 schrieb John Hardin:
> On Tue, 6 Jan 2015, Reindl Harald wrote:
>
>> it's a matter of technical correctness
>> no SPF on the envelope domain, no SPF
>>
>> * OK: SPF_PASS
>> * OK: SPF_PASS,SPF_HELO_PASS
>> * OK: SPF_NONE
>> * WRONG: SPF_NONE,SPF_HELO_PASS
>>
>> one can argue about the severity but the correctness is out of question
>
> Are you assuming that the MTA will always be in the same domain as the
> envelope sender address when you say that?
no - why should i?
we host 600 domains on the same MTA
i only say there can not be any sort of SPF PASS if the sending domain
don't have any SPF record at all - it's just wrong
Re: SPF_HELO_PASS,SPF_NONE
Posted by John Hardin <jh...@impsec.org>.
On Tue, 6 Jan 2015, Reindl Harald wrote:
> it's a matter of technical correctness
> no SPF on the envelope domain, no SPF
>
> * OK: SPF_PASS
> * OK: SPF_PASS,SPF_HELO_PASS
> * OK: SPF_NONE
> * WRONG: SPF_NONE,SPF_HELO_PASS
>
> one can argue about the severity but the correctness is out of question
Are you assuming that the MTA will always be in the same domain as the
envelope sender address when you say that?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
An entitlement beneficiary is a person or special interest group
who didn't earn your money, but demands the right to take your
money because they *want* it. -- John McKay, _The Welfare State:
No Mercy for the Middle Class_
-----------------------------------------------------------------------
12 days until Benjamin Franklin's 309th Birthday
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-06 01:55:
> * OK: SPF_PASS
> * OK: SPF_PASS,SPF_HELO_PASS
meta SPF_FULL_PASS (SPF_PASS && SPF_HELO_PASS)
score as you like
> * OK: SPF_NONE
> * WRONG: SPF_NONE,SPF_HELO_PASS
meta SPF_FULL_FAIL (!SPF_PASS && SPF_HELO_PASS)
score as you like
> one can argue about the severity but the correctness is out of question
well its opensource, it might not be a good test anyway
Re: SPF_HELO_PASS,SPF_NONE
Posted by RW <rw...@googlemail.com>.
On Tue, 06 Jan 2015 01:55:18 +0100
Reindl Harald wrote:
>
> > The point of helo tests is when they fail. If a
> > compromised host is telling you it's not permitted to send email
> > then what does it matter if the (probably spoofed) envelope domain
> > doesn't have an SPF policy
>
> it's a matter of technical correctness
> no SPF on the envelope domain, no SPF
>
> * OK: SPF_PASS
> * OK: SPF_PASS,SPF_HELO_PASS
> * OK: SPF_NONE
> * WRONG: SPF_NONE,SPF_HELO_PASS
>
> one can argue about the severity but the correctness is out of
> question
From RFC 7208
2.3. The "HELO" Identity
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
identity but also separately check the "HELO" identity by applying
the check_host() function (Section 4) to the "HELO" identity as the
<sender>. Checking "HELO" promotes consistency of results and can
reduce DNS resource usage. If a conclusive determination about the
message can be made based on a check of "HELO", then the use of DNS
resources to process the typically more complex "MAIL FROM" can be
avoided. Additionally, since SPF records published for "HELO"
identities refer to a single host, when available, they are a very
reliable source of host authorization status. Checking "HELO" before
"MAIL FROM" is the RECOMMENDED sequence if both are checked.
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 01:32 schrieb RW:
> On Tue, 06 Jan 2015 00:46:18 +0100
> Reindl Harald wrote:
>> Am 06.01.2015 um 00:06 schrieb RW:
>>> On Mon, 05 Jan 2015 22:58:55 +0100
>>> Reindl Harald wrote:
>>>> Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
>>>>> Reindl Harald skrev den 2015-01-05 18:52:
>>>>>> how can "SPF_HELO_PASS,SPF_NONE" fire both?
>>>>>
>>>>> the above is 2 diff tests
>>>>
>>>> i know that by myself *but* if the sending domain does not publish
>>>> any SPF policy then there should be no positive score for
>>>> "SPF_HELO_PASS"
>>>
>>> It doesn't have a positive score:
>>>
>>> score SPF_HELO_PASS -0.001
>>
>> that is a positive score in context of "less spam probability" just
>> because somebody sends a HELO command - frankly all day long zombies
>> send HELO commands of known domains up to fake PTR's if the
>> envelope domain don't push a SPF policy *only* NO_SPF should hit
>
> As I pointed-out the -0.001 is a nominal score assigned to
> informational rules
yes and no, having 10 wrong informational hits and you are at -0.01 and
may make the difference between tag-level or not
> The point of helo tests is when they fail. If a
> compromised host is telling you it's not permitted to send email then
> what does it matter if the (probably spoofed) envelope domain doesn't
> have an SPF policy
it's a matter of technical correctness
no SPF on the envelope domain, no SPF
* OK: SPF_PASS
* OK: SPF_PASS,SPF_HELO_PASS
* OK: SPF_NONE
* WRONG: SPF_NONE,SPF_HELO_PASS
one can argue about the severity but the correctness is out of question
Re: SPF_HELO_PASS,SPF_NONE
Posted by RW <rw...@googlemail.com>.
On Tue, 06 Jan 2015 00:46:18 +0100
Reindl Harald wrote:
>
>
> Am 06.01.2015 um 00:06 schrieb RW:
> > On Mon, 05 Jan 2015 22:58:55 +0100
> > Reindl Harald wrote:
> >> Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
> >>> Reindl Harald skrev den 2015-01-05 18:52:
> >>>> how can "SPF_HELO_PASS,SPF_NONE" fire both?
> >>>
> >>> the above is 2 diff tests
> >>
> >> i know that by myself *but* if the sending domain does not publish
> >> any SPF policy then there should be no positive score for
> >> "SPF_HELO_PASS"
> >
> > It doesn't have a positive score:
> >
> > score SPF_HELO_PASS -0.001
>
> that is a positive score in context of "less spam probability" just
> because somebody sends a HELO command - frankly all day long zombies
> send HELO commands of known domains up to fake PTR's if the
> envelope domain don't push a SPF policy *only* NO_SPF should hit
As I pointed-out the -0.001 is a nominal score assigned to
informational rules. The point of helo tests is when they fail. If a
compromised host is telling you it's not permitted to send email then
what does it matter if the (probably spoofed) envelope domain doesn't
have an SPF policy.
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.01.2015 um 00:06 schrieb RW:
> On Mon, 05 Jan 2015 22:58:55 +0100
> Reindl Harald wrote:
>> Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
>>> Reindl Harald skrev den 2015-01-05 18:52:
>>>> how can "SPF_HELO_PASS,SPF_NONE" fire both?
>>>
>>> the above is 2 diff tests
>>
>> i know that by myself *but* if the sending domain does not publish
>> any SPF policy then there should be no positive score for
>> "SPF_HELO_PASS"
>
> It doesn't have a positive score:
>
> score SPF_HELO_PASS -0.001
that is a positive score in context of "less spam probability" just
because somebody sends a HELO command - frankly all day long zombies
send HELO commands of known domains up to fake PTR's
if the envelope domain don't push a SPF policy *only* NO_SPF should hit
however, fixed that in "local.cf"
meta __SPF_FULL_PASS 0
meta __SPF_RANDOM_SENDER 0
score SPF_HELO_PASS 0
score SPF_HELO_FAIL 0
score SPF_HELO_SOFTFAIL 0
score SPF_NONE 0.05
score SPF_PASS -0.05
score SPF_SOFTFAIL 1.5
score SPF_FAIL 2.5
Re: SPF_HELO_PASS,SPF_NONE
Posted by RW <rw...@googlemail.com>.
On Mon, 05 Jan 2015 22:58:55 +0100
Reindl Harald wrote:
>
> Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
> > Reindl Harald skrev den 2015-01-05 18:52:
> >> how can "SPF_HELO_PASS,SPF_NONE" fire both?
> >
> > the above is 2 diff tests
>
> i know that by myself *but* if the sending domain does not publish
> any SPF policy then there should be no positive score for
> "SPF_HELO_PASS"
It doesn't have a positive score:
score SPF_HELO_PASS -0.001
Re: SPF_HELO_PASS,SPF_NONE
Posted by Reindl Harald <h....@thelounge.net>.
Am 05.01.2015 um 22:54 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-01-05 18:52:
>> how can "SPF_HELO_PASS,SPF_NONE" fire both?
>
> the above is 2 diff tests
i know that by myself *but* if the sending domain does not publish any
SPF policy then there should be no positive score for "SPF_HELO_PASS"
because take the HELO into account si in general questionable and, well,
the sender don't publish SPF at all
Re: SPF_HELO_PASS,SPF_NONE
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-01-05 18:52:
> how can "SPF_HELO_PASS,SPF_NONE" fire both?
the above is 2 diff tests