spf plugin fails on spf records

when it only have ip6: in the domain dns spf records :(

Re: spf records and cnames

al of HELO SPF and SPF records for every hostname is to make forging impossible - the SMTP RFC don't matter in that context - the only question is would a SPF policyd reject a message [harry@srv-rhsoft:~]$ nslookup www.rhsoft.net 8.8.8.8 Server: 8.8.8.8 Address:8.8.

Re: spf records and cnames

On 22.10.15 00:19, Reindl Harald wrote: otherwise you would not be able to set a SPF-record for your CNAMES and "reject_unknown_sender_domain" won't hit for a forged subdomain because it exists - so SPF *must* work for CNAMES or the whole intention for HELO SPF would not work Am 22.10.2015 um

Re: spf records and cnames

Am 22.10.2015 um 13:55 schrieb Matus UHLAR - fantomas: Am 22.10.2015 um 00:08 schrieb Bill Cole: I don't believe so and there's no reason to. CNAME records trump all DNS record types for a name so it may be usually unwise to have a CNAME record for a name that is used in email address domain p

Re: spf records and cnames

Am 22.10.2015 um 00:08 schrieb Bill Cole: I don't believe so and there's no reason to. CNAME records trump all DNS record types for a name so it may be usually unwise to have a CNAME record for a name that is used in email address domain parts, but it isn't inherently wrong. A name which is reso

Re: spf records and cnames

On Thu, 22 Oct 2015 00:59:04 +0200 Reindl Harald wrote: > so *read* what i refer to and read it really > YOU SET THE SPF AS ANY OTHER RECORD TYPE FOR A CNAME IMPLICITLY BY DO > THAT FOR THE A-RECORD THE CNAME IS POINTING TO You don't need to yell. A CNAME does not point to an A record. Regard

Re: spf records and cnames

Am 22.10.2015 um 00:19 schrieb Reindl Harald: Am 22.10.2015 um 00:08 schrieb Bill Cole: On 21 Oct 2015, at 13:48, btb wrote: are spf records allowed to be a cname? I can't see any reason why they shouldn't be... e.g.: http://dpaste.com/0MR0R3C.txt is this explicitly addre

Re: spf records and cnames

Am 22.10.2015 um 00:26 schrieb Dianne Skoll: On Thu, 22 Oct 2015 00:19:05 +0200 Reindl Harald wrote: no it should NOT otherwise you would not be able to set a SPF-record for your CNAMES You can't do that anyway. If a domain has a CNAME record, it MUST NOT have any other records of any

Re: spf records and cnames

On Thu, 22 Oct 2015 00:19:05 +0200 Reindl Harald wrote: > no it should NOT > otherwise you would not be able to set a SPF-record for your CNAMES You can't do that anyway. If a domain has a CNAME record, it MUST NOT have any other records of any other type whatsoever. So there's no way to set

Re: spf records and cnames

Am 22.10.2015 um 00:08 schrieb Bill Cole: On 21 Oct 2015, at 13:48, btb wrote: are spf records allowed to be a cname? I can't see any reason why they shouldn't be... e.g.: http://dpaste.com/0MR0R3C.txt is this explicitly addressed in an rfc? I don't believe so and there

Re: spf records and cnames

On 21 Oct 2015, at 13:48, btb wrote: are spf records allowed to be a cname? I can't see any reason why they shouldn't be... e.g.: http://dpaste.com/0MR0R3C.txt is this explicitly addressed in an rfc? I don't believe so and there's no reason to. CNAME records trump a

Re: spf records and cnames

Am 21.10.2015 um 19:48 schrieb btb: are spf records allowed to be a cname? e.g.: http://dpaste.com/0MR0R3C.txt is this explicitly addressed in an rfc? a CNAME is always followed, hence you can't mix CNAME and other ressource types, in other words: yes otherwise you would need

Re: spf records and cnames

On October 21, 2015 7:49:06 PM btb wrote: http://dpaste.com/0MR0R3C.txt https://dmarcian.com/spf-survey/email.instantbusinessresources.com is this explicitly addressed in an rfc? dont know, aslong spf is valid, then its ok

spf records and cnames

are spf records allowed to be a cname? e.g.: http://dpaste.com/0MR0R3C.txt is this explicitly addressed in an rfc? thanks -ben

R: RE: Spamassassin and SPF records with "+all"

No, I'm not meaning that. I'm instead following the Hardin suggestion, which works better with mass-check. I'm suggesting to use CIDR::Lite to avoid being fooled by stuff like +128.0.0.0/1 +0.0.0.0/1... Giampaolo Benny Pedersen ha scritto: Den 2012-07-13 19:44, Giampaolo Tomassoni skrev: >

RE: Spamassassin and SPF records with "+all"

Den 2012-07-13 19:44, Giampaolo Tomassoni skrev: Our hypothetic plugin could merge together CIDRs via Net::CIDR::Lite->add() and get the resultant merged, non-overlapping CIDRs via ->list(), then count the size of the allowed addresses (via something like 2^(32 - cidr_prefix)) and fire rules

RE: Spamassassin and SPF records with "+all"

> From: John Hardin [mailto:jhar...@impsec.org] > > Agreed. I was speculating that multiple variants of SPF_PERMISSIVE > might be justified, e.g. SPF_PERMISSIVE_ALL, SPF_PERMISSIVE_1, > SPF_PERMISSIVE_8, etc. However, it is only speculation; I have no > data to support that level of complexity bei

Re: Spamassassin and SPF records with "+all"

On Fri, 13 Jul 2012, Martin Gregorie wrote: On Fri, 2012-07-13 at 07:33 -0700, John Hardin wrote: >snippage If checking for +all is justified then checking for */1 through */8 would probably also be justified, perhaps with firing different rule so that a different score could be applied

Re: Spamassassin and SPF records with "+all"

On Fri, 2012-07-13 at 07:33 -0700, John Hardin wrote: > >snippage > If checking for +all is justified then checking for */1 through */8 would > probably also be justified, perhaps with firing different rule so that a > different score could be applied. > >more snippage > So does that m

Re: Spamassassin and SPF records with "+all"

Den 2012-07-13 17:02, David F. Skoll skrev: Absolutely. If you do not want to receive mail from a certain domain and it passes SPF, then there's pretty good evidence the mail really *is* from that domain and that you can apply your domain policy. bingo, if more recipients do this +all will cha

Re: Spamassassin and SPF records with "+all"

Den 2012-07-13 16:33, John Hardin skrev: So does that mean it may be legitimate to treat an SPF PASS as "something bad" if the SPF rule is defined in an "abusive" manner? meta __META_DNSWL_ANY (RCVD_IN_DNSWL_HI || RCVD_IN_DNSWL_MED || RCVD_IN_DNSWL_LOW) meta META_SPF_DNSWL (__META_DNSWL_ANY

Re: Spamassassin and SPF records with "+all"

On Fri, 13 Jul 2012 07:33:34 -0700 (PDT) John Hardin wrote: > So does that mean it may be legitimate to treat an SPF PASS as > "something bad" if the SPF rule is defined in an "abusive" manner? Absolutely. If you do not want to receive mail from a certain domain and it passes SPF, then there's

Re: Spamassassin and SPF records with "+all"

On Fri, 13 Jul 2012, David F. Skoll wrote: SPF has *never* been advocated as an anti-spam measure by the people who developed it. Agreed, but that does not mean under certain circumstances it cannot be useful as a spam indicator. And looking for +all or ?all is not enough; you can easily s

Re: Spamassassin and SPF records with "+all"

On 7/13/2012 4:57 AM, David F. Skoll wrote: > On Thu, 12 Jul 2012 21:37:36 +0100 > Martin Gregorie wrote: > >> True enough. I just wanted to provide a concrete example of extra >> stuff the plug-in could do and why that could be useful. It hadn't >> occurred to me until just now that SPF_PASS can

Re: Spamassassin and SPF records with "+all"

On Thu, 12 Jul 2012 21:37:36 +0100 Martin Gregorie wrote: > True enough. I just wanted to provide a concrete example of extra > stuff the plug-in could do and why that could be useful. It hadn't > occurred to me until just now that SPF_PASS can be triggered by > slovenly and/or careless SPF confi

Re: Spamassassin and SPF records with "+all"

On Thu, 2012-07-12 at 12:17 -0700, John Hardin wrote: > On Thu, 12 Jul 2012, Martin Gregorie wrote: > > > I'd suggest that any SPF record containing '+all' and possibly '?all' > > too, should trigger an SPF_PERMISSIVE rule rather than SPF_PASS so we > > can distinguish an authorised server in a ti

Re: Spamassassin and SPF records with "+all"

Em Wed, 11 Jul 2012 18:22:49 -0400 dar...@chaosreigns.com escreveu: > On 07/11, Josef Karliak wrote: > > within a few days we've spams from domains that has "+all" in the > > TXT spf record. I was thinking that I'll make a plugin that check > > this records and add some point to this email, but

Re: Spamassassin and SPF records with "+all"

On Thu, 12 Jul 2012, Martin Gregorie wrote: I'd suggest that any SPF record containing '+all' and possibly '?all' too, should trigger an SPF_PERMISSIVE rule rather than SPF_PASS so we can distinguish an authorised server in a tightly controlled domain from servers claiming to be part of a domain

Re: Spamassassin and SPF records with "+all"

On Thu, 2012-07-12 at 13:35 +0200, Benny Pedersen wrote: > Den 2012-07-12 09:33, Josef Karliak skrev: > > > "v=spf1 +all". > > if i find a domain with just that i perm reject this domain in mta > without spf testing > That sounds like a good idea. Can the SPF plugin recognise overly permissiv

Re: Spamassassin and SPF records with "+all"

solve spam problems in general, its may only one from > many parameters for spam tagging check > > any spammer can have valid spf records, also strict ones > also any legal mail sender > > in deed many spammers have valid spf entries in dns None of this really matters. It doesn't

Re: Spamassassin and SPF records with "+all" [learning per domain worth of SPF record]

Den 2012-07-12 09:20, David F. Skoll skrev: it's still the case because SPF is now more widely adopted than before. (Spammers tend to be early adopters of technology.) thay are properly implementing dmarc into spamassassin right now :)

Re: Spamassassin and SPF records with "+all"

Den 2012-07-12 08:50, Robert Schetterer skrev: i wouldnt invest time in it spf does not solve spam problems in general, its may only one from many parameters for spam tagging check currect any spammer can have valid spf records, also strict ones also any legal mail sender currect in

Re: Spamassassin and SPF records with "+all"

Den 2012-07-12 09:33, Josef Karliak skrev: "v=spf1 +all". if i find a domain with just that i perm reject this domain in mta without spf testing I tried "META ..." mentioned in some post, I'll see. maybe it helps spammers ? :=) if its your own domain as sender one could ask sender f

Re: Spamassassin and SPF records with "+all" [learning per domain worth of SPF record]

On Thu, 2012-07-12 at 03:20 -0400, David F. Skoll wrote: > On Thu, 12 Jul 2012 09:08:19 +0200 > "Andrzej A. Filip" wrote: > > > Would you suggest/recommend using spf-bayes? > > [auto-learning of "worth" of given domain SPF record] > > That is an interesting idea... store tokens like: > >

Re: Spamassassin and SPF records with "+all"

am. FWIW I think SPF's main use is in avoiding backscatter, e.g. if a spammer forged your address as sender and his target domain is bouncing rejected mail back to you. It does this well, but I don't think its of any use at all for detecting spam other than possibly adding a few points

Re: Spamassassin and SPF records with "+all" [learning per domain worth of SPF record]

Am 12.07.2012 09:08, schrieb Andrzej A. Filip: > On 07/12/2012 09:01 AM, David F. Skoll wrote: >> On Thu, 12 Jul 2012 08:50:59 +0200 >> Robert Schetterer wrote: >> >>> spf does not solve spam problems in general, its may only one from >>> many parameters for spam tagging check >> Indeed. I *never

Re: Spamassassin and SPF records with "+all" [learning per domain worth of SPF record]

On Thu, 12 Jul 2012 09:08:19 +0200 "Andrzej A. Filip" wrote: > Would you suggest/recommend using spf-bayes? > [auto-learning of "worth" of given domain SPF record] That is an interesting idea... store tokens like: example.com*spf-pass and compute probabilities. A while ago, I did an inf

Re: Spamassassin and SPF records with "+all" [learning per domain worth of SPF record]

On 07/12/2012 09:01 AM, David F. Skoll wrote: > On Thu, 12 Jul 2012 08:50:59 +0200 > Robert Schetterer wrote: > >> spf does not solve spam problems in general, its may only one from >> many parameters for spam tagging check > Indeed. I *never* subtract points for an SPF "pass" except for a very >

Re: Spamassassin and SPF records with "+all"

On Thu, 12 Jul 2012 08:50:59 +0200 Robert Schetterer wrote: > spf does not solve spam problems in general, its may only one from > many parameters for spam tagging check Indeed. I *never* subtract points for an SPF "pass" except for a very few select domains that I trust. I only ever use SPF t

Re: Spamassassin and SPF records with "+all"

now perl. Are > there some other options ? Does anybody solve this problems ? > Thanks and best regards > J.Karliak. > i wouldnt invest time in it spf does not solve spam problems in general, its may only one from many parameters for spam tagging check any spammer can have valid

Re: Spamassassin and SPF records with "+all"

Den 2012-07-12 01:26, John Hardin skrev: "adding a point" is different from "listing as spammers". yes make more meta would solve things as +all, i have not seen it as a problem with domains that use +all here, there is more domains that creates invalid spf, and dont want to resolve the prob

Re: Spamassassin and SPF records with "+all"

On Thu, 12 Jul 2012, Benny Pedersen wrote: Den 2012-07-12 00:22, dar...@chaosreigns.com skrev: That's a *really* unprofessional way to say "Everything in this domain passes SPF." it will be more unproffessional to treat +all as a spammy sign, atleast in spf terms Not if it actually occu

Re: Spamassassin and SPF records with "+all"

Den 2012-07-12 00:22, dar...@chaosreigns.com skrev: That's a *really* unprofessional way to say "Everything in this domain passes SPF." it will be more unproffessional to treat +all as a spammy sign, atleast in spf terms spamassassin does not need to test +all, show an example where spamme

Re: Spamassassin and SPF records with "+all"

On Thu, 12 Jul 2012, Benny Pedersen wrote: Den 2012-07-11 23:17, John Hardin skrev: Adding a point for a domain that says "email from all possible IP addresses is valid" may be justifiable. problem is when webhotels make default +all and hosted domains dont have control over there full dn

Re: Spamassassin and SPF records with "+all"

Den 2012-07-11 23:17, John Hardin skrev: Adding a point for a domain that says "email from all possible IP addresses is valid" may be justifiable. problem is when webhotels make default +all and hosted domains dont have control over there full dns, should this domain so be listed as spammers

Re: Spamassassin and SPF records with "+all"

Den 2012-07-11 21:34, Josef Karliak skrev: within a few days we've spams from domains that has "+all" in the TXT spf record. spamassassin does give -100 in score for spf_pass ? :=) I was thinking that I'll make a plugin that check this records and add some point to this email, but I do not kn

Re: Spamassassin and SPF records with "+all"

On 7/11/12 3:45 PM, "Martin Gregorie" wrote: > On Wed, 2012-07-11 at 21:34 +0200, Josef Karliak wrote: >> Good evening, >>within a few days we've spams from domains that has "+all" in the >> TXT spf record. >> > All SPF can do is check that the sender has a valid IP for that domain, > i.e.

Re: Spamassassin and SPF records with "+all"

On 07/11, Josef Karliak wrote: > within a few days we've spams from domains that has "+all" in the > TXT spf record. I was thinking that I'll make a plugin that check > this records and add some point to this email, but I do not know Your best chance may be to open a spamassassin bug requesting

Re: Spamassassin and SPF records with "+all"

On Wed, 11 Jul 2012, Martin Gregorie wrote: On Wed, 2012-07-11 at 21:34 +0200, Josef Karliak wrote: within a few days we've spams from domains that has "+all" in the TXT spf record. how are you proposing to improve on what SA currently does? Adding a point for a domain that says "email f

Re: Spamassassin and SPF records with "+all"

address as sender and his target domain is bouncing rejected mail back to you. It does this well, but I don't think its of any use at all for detecting spam other than possibly adding a few points for an SPF-FAIL. However, as SPF records aren't necessarily correct (they may never have been

Spamassassin and SPF records with "+all"

Good evening, within a few days we've spams from domains that has "+all" in the TXT spf record. I was thinking that I'll make a plugin that check this records and add some point to this email, but I do not know perl. Are there some other options ? Does anybody solve this problems ? Th

Re: hallmark greeting card spam and broken spf records.

Michael Scheidell wrote: #2, hallmark ITSELF has broken spf records (componds the problem) That IS the problem as I understand it. It appears that Hallmark has made a legitimate effort to publish an accurate SPF record identifying their systems. Unfortunately the record is unnecessarily

RE: hallmark greeting card spam and broken spf records.

> -Original Message- > From: Matus UHLAR - fantomas [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 04, 2007 4:08 AM > To: users@spamassassin.apache.org > Subject: Re: hallmark greeting card spam and broken spf records. > > > > On Friday 03 August 20

Re: hallmark greeting card spam and broken spf records.

flag when > evaluating the "spam level" of a message. Spammers ARE taking advantage of > this by placing +all in the SPF records of the domains that they purchase for > the purposes of sending spam. What this does is tells the receiving server > that ANY IP ADDRESS is al

Re: hallmark greeting card spam and broken spf records.

l they at least fix their spf > records: (i suspect its the :12" "9 )? shb a period? I have a good friend who patches his qmail so that if it sees a spf record that is extra wide, he reverses it's meaning. - Quoting from qmail.jms1.net Some people are improperly treatin

RE: hallmark greeting card spam and broken spf records.

> -Original Message- > From: McDonald, Dan [mailto:[EMAIL PROTECTED] > Sent: Friday, August 03, 2007 2:45 PM > To: users@spamassassin.apache.org > Subject: Re: hallmark greeting card spam and broken spf records. > > On Fri, 2007-08-03 at 13:26 -0400, Michael Sche

Re: hallmark greeting card spam and broken spf records.

On Fri, 3 Aug 2007, Michael Scheidell wrote: > Subject: [SPAM]You have recieved a Hallmark E-Card ! http://www.impsec.org/~jhardin/antispam/postcards.cf has been updated for this subject line, and also for some new domain names. -- John Hardin KA7OHZhttp://www.impsec.org/~j

Re: hallmark greeting card spam and broken spf records.

llmark till they at least fix their spf > records: (i suspect its the :12" "9 )? shb a period? Isn't it the ~all (rather than -all)? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part

hallmark greeting card spam and broken spf records.

(yes, spf is broken) especially when companies like hallmark, who know they are being used as 'phishing' targets list the whole world as authoritative mail servers. I say damn them all, blacklist hallmark till they at least fix their spf records: (i suspect its the :12" &qu

Re: on the value of SPF records

Mathias Homann wrote: One day, spamassassin seems to think that this newsletter, send to my private email, is spam. This leads to me running it through spamassassin in debug mode... and what do I see... The guy at $SOMEOTHERCOMPANY has set up SPF records for their systems as well... and has

Re: on the value of SPF records (was: Re: Importance of SMTP gateway reverse lookup domain?)

On Freitag, 17. März 2006 00:25 Mathias Homann wrote: > One day, i get a ticket in our ticket system, which sums up as "we > need to have spf records, and we need them now, because that guy at > $SOMEOTHERCOMPANY says so, so that our newsletter is less likely to > get flagged a

Re: on the value of SPF records (was: Re: Importance of SMTP gateway reverse lookup domain?)

From: "Mathias Homann" <[EMAIL PROTECTED]> ... bye, MH yes, i DO know that this list is NOT the scary evil monastery. but it fits into the discussion... sort of... Um, er, , , aren't monasteries for "boys"? I better get outa here FAST before someone notices. >{

on the value of SPF records (was: Re: Importance of SMTP gateway reverse lookup domain?)

Am Donnerstag, 16. März 2006 23:46 schrieb Michael Monnerie: > On Donnerstag, 16. März 2006 17:15 Stewart, John wrote: > > Aye; thanks. Unfortunately, our current external DNS server > > doesn't yet support SPF records. =( let me rant a bit about SPF records. Background

RE: SPF Records

On Wed, 6 Oct 2004 14:00:19 -0400, Dave Duffner - NWCWEB.com wrote > Last we heard from this (or another, poss. MailScanner) List > was that SPF's are now a dead issue. Some locations are using it > and trying to keep it alive, but even MicroWreck backed off their > stance in supporting it.

Re: SPF Records

m sure. SPF is not an anti-spam tool, it is an anti-spoofing tool. Spammers can and do have valid SPF records. What you want, if anything, is to penalize SPF failures as spoofs. Vivek Khera, Ph.D. +1-301-869-4449 x806 smime.p7s Description: S/MIME cryptographic signature

Re: SPF Records

http://spf.pobox.com/ More important than the current percentaje of domains publishing SPF records is the fact that most important domains around the world (commonly used to forge email addresses) *do* have SPF records now. - Oscar.

Re: SPF Records

The actual number is about: 140.000 domains This only includes those manually registered at: http://spftools.infinitepenguins.net/register.php Check also: http://spf.pobox.com/ More important than the current percentaje of domains publishing SPF records is the fact that most important domains

Re: SPF Records

On 2004-10-06, at 19.48, Stuart Gall wrote: I read that 21,000 domains now use an SPF record, so we should be checking for it right? The numbers are far greater than that. You can check the statistics of domains that use SPF and that have manually registered that they do here:

RE: SPF Records

Dave Duffner - NWCWEB.com said: > > Last we heard from this (or another, poss. MailScanner) List > was that SPF's are now a dead issue. Some locations are using it > and trying to keep it alive, but even MicroWreck backed off their > stance in supporting it. Quite mistaken, the attempt by

Re: SPF Records

On Wed, Oct 06, 2004 at 02:00:19PM -0400, Dave Duffner - NWCWEB.com wrote: > Last we heard from this (or another, poss. MailScanner) List > was that SPF's are now a dead issue. Some locations are using it > and trying to keep it alive, but even MicroWreck backed off their > stance in suppor

RE: SPF Records

> -Original Message- > From: Stuart Gall [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 06, 2004 1:49 PM > To: users@spamassassin.apache.org > Subject: SPF Records > > Hello, > Does SA 3.0.0 check for the presence of the SPF record in the DNS of > the

Re: SPF Records

On Wed, Oct 06, 2004 at 08:48:48PM +0300, Stuart Gall wrote: > Does SA 3.0.0 check for the presence of the SPF record in the DNS of > the originating domain ? If you have Net::DNS installed and the plugin loaded (it is by default). -- Randomly Generated Tagline: "A: You mean it's not due on Fri

Re: SPF Records

On Wed, 6 Oct 2004, Stuart Gall wrote: Hello, Does SA 3.0.0 check for the presence of the SPF record in the DNS of the originating domain ? I read that 21,000 domains now use an SPF record, so we should be checking for it right? Out of how many domains total? The numbers impressive. The percen

SPF Records

Hello, Does SA 3.0.0 check for the presence of the SPF record in the DNS of the originating domain ? I read that 21,000 domains now use an SPF record, so we should be checking for it right? Stuart Gall Klien bottle for rent Enquire within. -

Re: Speakeasy just implemented SPF records - badly

--On Friday, September 24, 2004 11:33 AM -0400 Steve Prior <[EMAIL PROTECTED]> wrote: In case anyone else is going to run into this, sometime yesterday speakeasy.net implemented default SPF records for all of their DNS hosting customers. I don't see it for the two domains they host fo

Speakeasy just implemented SPF records - badly

In case anyone else is going to run into this, sometime yesterday speakeasy.net implemented default SPF records for all of their DNS hosting customers. The problem is that they did it badly. No notification whatsoever was sent out that they were doing this and no chance to review (or even change