On Wed, 24 Jan 2018, Bill Cole wrote:
On 24 Jan 2018, at 17:20 (-0500), John Hardin wrote:
On Wed, 24 Jan 2018, Dianne Skoll wrote:
At this point, I would be willing to penalize sites with bad SPF
records (syntactically invalid; more than one different SPF record
attached to the same domain,
On 24 Jan 2018, at 17:20 (-0500), John Hardin wrote:
On Wed, 24 Jan 2018, Dianne Skoll wrote:
At this point, I would be willing to penalize sites with bad SPF
records (syntactically invalid; more than one different SPF record
attached to the same domain, etc.) Those people really deserve
pena
On Wed, 24 Jan 2018, Dianne Skoll wrote:
On Wed, 24 Jan 2018 14:20:57 -0800 (PST)
John Hardin wrote:
At this point, I would be willing to penalize sites with bad SPF
records (syntactically invalid; more than one different SPF record
attached to the same domain, etc.) Those people really dese
On Thu, 25 Jan 2018 01:05:48 +
RW wrote:
> On Wed, 24 Jan 2018 03:07:48 -0500
> Rupert Gallagher wrote:
>
> > To: address matches Reply-To: address.
>
>
> From: Rupert Gallagher
> Reply-To: Rupert Gallagher
Sorry I misread that.
On Wed, 24 Jan 2018 03:07:48 -0500
Rupert Gallagher wrote:
> To: address matches Reply-To: address.
From: Rupert Gallagher
Reply-To: Rupert Gallagher
On Wed, 24 Jan 2018 14:20:57 -0800 (PST)
John Hardin wrote:
> > At this point, I would be willing to penalize sites with bad SPF
> > records (syntactically invalid; more than one different SPF record
> > attached to the same domain, etc.) Those people really deserve
> > penalties because they've
On 24 Jan 2018, at 04:08, Rupert Gallagher wrote:
> Is this the "official" version of kam.cf?
>
> http://www.pccc.com/downloads/SpamAssassin/contrib/
>
> The file is huge, and consists of ad-hoc rules against spammy keywords.
Is less than 300K huge?
That does remind me, though, does SpamAssa
On 2018-01-24 18:10, Bill Cole wrote:
> 1. Mail with an envelope sender domain that has no SPF record is more
> likely to be spam than the overall mail stream.
>
> 2. Mail whose envelope sender domain has a published SPF record which
> repudiates the sending IP is more likely to be spam than the
SPF is designed for authentication, not spam filtering. Using a crowbar as a
hammer. We apply a small score mainly so we see the elements reported.
If the "majors" are using in their hygiene stack, for evalation like you are, I
haven't seen much evidence of that. Of course it's hard to test
On 24 Jan 2018, at 14:59 (-0500), David Jones wrote:
On 01/24/2018 01:33 PM, Bill Cole wrote:
On 24 Jan 2018, at 9:12, David Jones wrote:
What does everyone think about slowly increasing the score for
SPF_NONE and SPF_FAIL over time in the SA rulesets to force the
awareness and importance of
If all those smarties who speak against spf would simply shut-up and implement
it correctly, with dkim and dmarc, and read the dmarc reports, then they would
know how valuable it is.
On raising the score: done, long ago, happy with the outcome, and strongly
recommend it.
On Wed, 2018-01-24 at 14:24 -0800, John Hardin wrote:
> I think he was referring to MTA-side forwarding, not forwarding an
> email you received (which forward comes *from you*).
>
I was wondering if this could be related to Joseph's comment that
"DMARC is destroying forwarding and mailing lists" a
On 01/24/2018 04:00 PM, Vincent Fox wrote:
so there's this argument that goes:
"well we won't really see the benefits until it's FULLY and RIGIDLY
implemented."
However, look at all the major providers with messed up records and
neutral or soft fail. They should have the most resources to
On Wed, 24 Jan 2018, Martin Gregorie wrote:
On Wed, 2018-01-24 at 16:45 -0500, Joseph Brennan wrote:
DMARC is not a standard according to RFC 7489, "Status of This Memo".
It's just informational, for those who want to play the game. DMARC
is destroying forwarding and mailing lists,
Could this
On Wed, 24 Jan 2018, Dianne Skoll wrote:
At this point, I would be willing to penalize sites with bad SPF
records (syntactically invalid; more than one different SPF record
attached to the same domain, etc.) Those people really deserve
penalties because they've messed up.
Does that include "+
On Wed, 2018-01-24 at 16:45 -0500, Joseph Brennan wrote:
> DMARC is not a standard according to RFC 7489, "Status of This Memo".
> It's just informational, for those who want to play the game. DMARC
> is destroying forwarding and mailing lists,
>
Could this be why recent releases of the Evolution M
On 01/24/2018 03:45 PM, Joseph Brennan wrote:
David Jones wrote:
SA could be the large force that helps improve the mail standards like
DMARC -- SPF + DKIM with a little extra on top.
DMARC is not a standard according to RFC 7489, "Status of This Memo".
It's just informational, for those w
so there's this argument that goes:
"well we won't really see the benefits until it's FULLY and RIGIDLY
implemented."
However, look at all the major providers with messed up records and neutral or
soft fail. They should have the most resources to accomplish this and the
most incentives to
David Jones wrote:
SA could be the large force that helps improve the mail standards like
DMARC -- SPF + DKIM with a little extra on top.
DMARC is not a standard according to RFC 7489, "Status of This Memo". It's
just informational, for those who want to play the game. DMARC is
destroying
On 23 Jan 2018, at 21:26 (-0500), David Jones wrote:
We could setup a 60_blacklist_from.cf file in the SA ruleset for
definite bad domains but that's probably not the best place to
maintain that. It really should be in major DBLs that SA already
knows to check.
+1
Unsurprisingly, running a
At this point, I would be willing to penalize sites with bad SPF
records (syntactically invalid; more than one different SPF record
attached to the same domain, etc.) Those people really deserve
penalties because they've messed up.
I would not be willing to penalize sites with *no* SPF at all jus
On 01/24/2018 01:58 PM, Vincent Fox wrote:
I'd rather not think about the manhours I've wasted this year on SPF.
The guy at Evotec.com, among others, who thinks rejecting
for SOFTFAIL is a perfectly valid anti-spoofing strategy and
doesn't blink when pointed to RFC 4408 sec 2.5.5.
Vendors w
I'd rather not think about the manhours I've wasted this year on SPF.
The guy at Evotec.com, among others, who thinks rejecting
for SOFTFAIL is a perfectly valid anti-spoofing strategy and
doesn't blink when pointed to RFC 4408 sec 2.5.5.
Vendors who's first response is:
"Our LEGIT spamer
On 01/24/2018 01:33 PM, Bill Cole wrote:
On 24 Jan 2018, at 9:12, David Jones wrote:
What does everyone think about slowly increasing the score for
SPF_NONE and SPF_FAIL over time in the SA rulesets to force the
awareness and importance of proper SPF?
-1
In every real mailstream I've worked
On 01/24/2018 01:01 PM, Vincent Fox wrote:
SPF is designed for whitelisting, not blacklist.
Not true. We are supposed to reject email that doesn't pass SPF checks
if the domain has told us to with "-all". That is a form of
blacklisting controlled by the domain itself to protect it's own
b
On 24 Jan 2018, at 9:12, David Jones wrote:
What does everyone think about slowly increasing the score for
SPF_NONE and SPF_FAIL over time in the SA rulesets to force the
awareness and importance of proper SPF?
-1
In every real mailstream I've worked with in the lifetime of SPF, lack
of SPF
On Wed, 2018-01-24 at 19:01 +, Vincent Fox wrote:
> SPF is a zombie legacy that someone should shoot in
> the head.
>
SPF is still good for what I've always thought was its main use:
detecting spam delivered by backscatter. Given that its dirt cheap to
implement, and easy too verify now that t
On Wed, 24 Jan 2018 19:01:28 +
Vincent Fox wrote:
> SPF is a zombie legacy that someone should shoot in
> the head.
+1
> Maybe then we could design something that
> is useful for what we all desire, which is properly
> authenticating senders.
We cannot authenticate senders and keep SMTP as
We had three spam messages in about 8 months? I lost count. Our clients are so
used to have a clean inbox that they spot a spam like the proverbial white fly.
Sent from ProtonMail Mobile
On Wed, Jan 24, 2018 at 13:34, Kevin A. McGrail
wrote:
> On 1/24/2018 6:08 AM, Rupert Gallagher wrote:
>
>
SPF is designed for whitelisting, not blacklist.
Remember when "shields" appeared in mail
clients, and how fast that feature disappeared?
Far too many people clicking on phish that seemed
"authentic". With the explosion of cheap domains
and registrars, there's really no snowshoe Black Hat
o
On Wed, Jan 24, 2018 at 08:12:19AM -0600, David Jones wrote:
> Google Chrome and other browsers have been slowly penalizing sites not
> using encryption to the point that soon they will be alerting users of
> plain HTTP sites. This along with letsencrypt.org has been moving the
> HTTPS bar forw
Google Chrome and other browsers have been slowly penalizing sites not
using encryption to the point that soon they will be alerting users of
plain HTTP sites. This along with letsencrypt.org has been moving the
HTTPS bar forward to improve web security and privacy.
I think it's time for the
On 1/24/2018 6:08 AM, Rupert Gallagher wrote:
Is this the "official" version of kam.cf?
http://www.pccc.com/downloads/SpamAssassin/contrib/
Yes. Are there unofficial versions?
The file is huge, and consists of ad-hoc rules against spammy keywords.
We use a completely different approach,
Is this the "official" version of kam.cf?
http://www.pccc.com/downloads/SpamAssassin/contrib/
The file is huge, and consists of ad-hoc rules against spammy keywords.
We use a completely different approach, resulting in few general rules and a
short whitelist. We hardly see any kam-esque spam, b
To: address matches Reply-To: address.
Sent from ProtonMail Mobile
35 matches
Mail list logo
