On Jan 12, 2015, at 4:58 PM, Mark Martinec wrote:
>> On January 12, 2015 8:06:00 AM EST, Mark Martinec
>>> It would be wrong to assign score to short keys.
>
> Kevin A. McGrail wrote:
>> Actually the rfc specifies that keys 512 to 2048 bits must be verified
>> so I think there is a grey area an
> On Jan 11, 2015, at 3:40 PM, Kevin A. McGrail wrote:
>
> I disagree as well. You can't cherry pick your quotes and you are missing the
> long-lived caveat as well as the next sentence: Verifiers MUST be able to
> validate signatures with keys ranging from 512 bits to 2048 bits
>
> If it is
On Nov 26, 2014, at 10:50 AM, Reindl Harald wrote:
>
> Am 26.11.2014 um 19:45 schrieb Franck Martin:
>> On Nov 26, 2014, at 10:19 AM, Matthias Leisi > <mailto:matth...@leisi.net>> wrote:
>>>
>>>
>> Agreed, it is cheap in resources. However,
On Nov 26, 2014, at 10:19 AM, Matthias Leisi
mailto:matth...@leisi.net>> wrote:
On Wed, Nov 26, 2014 at 6:05 PM, Franck Martin
mailto:fmar...@linkedin.com>> wrote:
As for /64, yes there are hosting providers that have all their customers in
the same /64 and other cases lik
On Nov 26, 2014, at 2:15 AM, Kevin A. McGrail
mailto:kmcgr...@pccc.com>> wrote:
On 11/26/2014 1:53 AM, Matthias Leisi wrote:
On Wed, Nov 26, 2014 at 3:45 AM, Franck Martin
mailto:fmar...@linkedin.com>> wrote:
You may want to read
https://www.m3aawg.org/sites/maaw
On Nov 22, 2014, at 4:15 AM, Aban Dokht wrote:
>
> On 21.11.2014 18:17, Matthias Leisi wrote:
>> We are about to simplify the reporting we
>> previously had, and want to push this especially to detect spam coming
>> in over IPv6.
>
> We also have honeypots with enabled IPv6 MX, but SPAM over I
On Jun 9, 2014, at 11:27 PM, Christian Laußat
wrote:
> Am 10.06.2014 05:53, schrieb Franck Martin:
>> This is not correct. I think it is strange to claim that yahoo or aol,
>> being a co-creator of DMARC and having outstanding engineers in the
>> profession do not kno
On Jun 7, 2014, at 9:49 PM, Christian Laußat
wrote:
> Am 07.06.2014 19:55, schrieb Franck Martin:
>> As DMARC provide a feedback mechanism to the sender, then it is up to
>> the sender to deal with these issues, you are just following their
>> policy, you don’t need to
On Jun 6, 2014, at 10:30 AM, Christian Laußat
wrote:
> Am 05.06.2014 21:48, schrieb Franck Martin:
>> If the policy=reject and the dmarc is fail, then spamassassin should
>> not see the email because opendmarc would have already rejected it (if
>> not it is due to loca
A couple of comments…
If the policy=reject and the dmarc is fail, then spamassassin should not see
the email because opendmarc would have already rejected it (if not it is due to
local policy override, so spamassassin should not change that)
So if you reject on dmarc=fail, this may due to p=qu
On Apr 30, 2014, at 5:05 AM, Christian Laußat
wrote:
> Am 30.04.2014 12:34, schrieb Michael Storz:
>> Am 2014-04-30 11:00, schrieb Axb:
>>> On 04/30/2014 10:30 AM, Michael Storz wrote:
>>> and in the meantime may want to look at
>>> http://sourceforge.net/projects/opendmarc/
>> OpenDMARC is ok
Interesting, thanks for pointing it out
This syntax has been used in a while by some other software, like JIRA, RT, …
so not something new.
In general, I would say spamassassin needs a few extra rules to now handle
domain reputation/blocking (as it seems this is where we are going), I even
fou
May be to give some background and from there please apply what works best for
you.
Linkedin do DMARC.org, this means all the emails sent from Linkedin
infrastructure will pass SPF (be with the mailfrom or helo strings) and be DKIM
signed. Furthermore the domain present in all the strings will
On Aug 8, 2013, at 10:49 PM, John Hardin wrote:
> On Thu, 8 Aug 2013, Quanah Gibson-Mount wrote:
>
>> For SA 3.4.0, it says in 50_scores.cf:
>>
>> # SPF
>> # Note that the benefit for a valid SPF record is deliberately minimal; it's
>> # likely that more spammers would quickly move to setti
On Aug 1, 2013, at 12:44 PM, Benny Pedersen wrote:
> Franck Martin skrev den 2013-07-31 23:06:
>
>> Now as we move to IPv6, reputation will shift from an IP based type
>> reputation, to a domain based type reputation. Unfortunately, spam
>> assassin seems to be lackin
On Jul 31, 2013, at 11:19 PM, RGB Camera
mailto:zauschne...@gmail.com>>
wrote:
On Wed, Jul 31, 2013 at 2:06 PM, Franck Martin
mailto:fmar...@linkedin.com>> wrote:
On Jul 31, 2013, at 10:08 PM, Kevin Miller
mailto:kevin_mil...@ci.juneau.ak.us>> wrote:
> Problem is,
On Jul 31, 2013, at 10:08 PM, Kevin Miller wrote:
> Problem is, the from adddress is often a "Joe job" - i.e., a forged address,
> so the domain mentioned there likely doesn't have anything to do with the
> actual source of the mail. It seems to me that if the domain isn't the
> actual sourc
On Jul 31, 2013, at 7:56 PM, Ralf Hildebrandt
wrote:
> * Franck Martin :
>
>> I looked at http://spamassassin.apache.org/tests_3_3_x.html could not find
>> any rule that do the above. Please help.
>
> That's a bit odd. I found it being mentioned here:
>
On Jul 31, 2013, at 7:43 PM, Jari Fredriksson wrote:
> 31.07.2013 20:08, Franck Martin kirjoitti:
>> Hi all,
>>
>> I noticed there is no rules to check if the domain in various emails fields
>> are on blocking lists like DBL at spamhaus. I'm willing to work o
Hi all,
I noticed there is no rules to check if the domain in various emails fields are
on blocking lists like DBL at spamhaus. I'm willing to work on some of these
rules, but I would appreciate any advice to bootstrap the process. If you can
reference documents or say something like, look at t
20 matches
Mail list logo
