On 1/30/2020 6:37 PM, John Hardin wrote:
> The problem is that there are no Received headers internal to his
> domain, and that makes it look like a MUA is directly contacting your
> MTA to send an email - hence, "DIRECT_TO_MX".
>
> If you can, advise the sender to not remove all the Received heade
On Thu, 30 Jan 2020, premax wrote:
Hello there,
The sender is using Outlook and his own mail server. Mail comes to my
server and scores against DOS_OUTLOOK_TO_MX, because of
__DOS_DIRECT_TO_MX false positive. I've been looking into message
headers for hours and see nothing strange over there
On Thu, 2020-01-30 at 15:05 -0800, John Hardin wrote:
> On Thu, 30 Jan 2020, Matus UHLAR - fantomas wrote:
>
> > > > On 29.01.20 15:21, Kevin A. McGrail wrote:
> > > > > Correct, it's a policy issue. ASF Projects must stop
> > > > > providing SHA-1
> > > > > signatures and we negotiated that dead
On Thu, 30 Jan 2020, Matus UHLAR - fantomas wrote:
On 29.01.20 15:21, Kevin A. McGrail wrote:
>Correct, it's a policy issue. ASF Projects must stop providing SHA-1
>signatures and we negotiated that deadline.
On Thu, Jan 30, 2020 at 10:44:09AM +0100, Matus UHLAR - fantomas wrote:
do you mea
Hello there,
The sender is using Outlook and his own mail server. Mail comes to my server
and scores against DOS_OUTLOOK_TO_MX, because of __DOS_DIRECT_TO_MX false
positive. I've been looking into message headers for hours and see nothing
strange over there. 'Received' header are present. Why is t
Sorry; third machine is openSuSE but old 11.4; second machine was
opensSuSE 13.1
Peraps the perl is too old...
On Thu, 30 Jan 2020, Henrik K wrote:
On Thu, Jan 30, 2020 at 04:49:37PM +, John wrote:
i have built 3.4.4 from sources on three different computers. The
first two worked OK an
On Thu, Jan 30, 2020 at 04:49:37PM +, John wrote:
> i have built 3.4.4 from sources on three different computers. The
> first two worked OK and the new system is in service (A Debian and a
> openSuSE system). However on the third machine I have a range f
> problems I do not understand.
Would
i have built 3.4.4 from sources on three different computers. The
first two worked OK and the new system is in service (A Debian and a
openSuSE system). However on the third machine I have a range f
problems I do not understand.
First it noted a number of missing optional perk modules which limi
> Key to the issue is I fail to see how the highly intrusive security work
> done for 3.4.3 can possibly be backported.
The Debian patches for CVE-2018-11805 and CVE-2019-12420 onto 3.4.2 are
roughly 100kb in size.
Kevin A. McGrail schrieb am 29.01.2020 um 20:12:
- Fix for CRLF handling with SpamAssMilter & DKIM
Sorry that I didn't check and write about rc1, but I can confirm that
for me, valid DKIM signatures are again detected as valid with the
released 3.4.4.
Many thanks!
Alex
On 1/30/2020 9:54 AM, RW wrote:
> On Thu, 30 Jan 2020 11:00:32 +0100
> Matus UHLAR - fantomas wrote:
>
On 29.01.20 15:21, Kevin A. McGrail wrote:
>> I use debian, and it uses GPG signatures. so I understand that sha-1
>> issue even less...
> It was a matter of Apache policy as I understand
On Thu, 30 Jan 2020 11:00:32 +0100
Matus UHLAR - fantomas wrote:
> >> On 29.01.20 15:21, Kevin A. McGrail wrote:
> I use debian, and it uses GPG signatures. so I understand that sha-1
> issue even less...
It was a matter of Apache policy as I understand it. There were no
security implications
> whitelist_from *.powersystemsdesign.com
>
> sender is: newslet...@powersystemsdesign.com
Your whitelist entry expects a literal dot before the second level
domain. Try *@powersystemsdesign.com
Hi!
In /etc/mail/spamassassin/local.cf I have, among other things:
whitelist_from *.powersystemsdesign.com
Still mails from them are flagged as SPAM:
Content analysis details: (5.3 points, 5.0 required)
pts rule name description
-- -
> I use debian, and it uses GPG signatures. so I understand that sha-1
> issue even less
Which release do you worry about? Even oldoldstable is at 3.4.2, which
should be fine according to
> If you do not update to 3.4.2 or later, you will be stuck at the last
> ruleset with SHA-1 signatures.
On Thu, Jan 30, 2020 at 11:00:32AM +0100, Matus UHLAR - fantomas wrote:
> >>On 29.01.20 15:21, Kevin A. McGrail wrote:
> >>>Correct, it's a policy issue. ASF Projects must stop providing SHA-1
> >>>signatures and we negotiated that deadline.
>
> >On Thu, Jan 30, 2020 at 10:44:09AM +0100, Matus UH
On 29.01.20 15:21, Kevin A. McGrail wrote:
>Correct, it's a policy issue. ASF Projects must stop providing SHA-1
>signatures and we negotiated that deadline.
On Thu, Jan 30, 2020 at 10:44:09AM +0100, Matus UHLAR - fantomas wrote:
do you mean, not having updates is better than using sha-1?
O
On Thu, Jan 30, 2020 at 10:44:09AM +0100, Matus UHLAR - fantomas wrote:
> On 29.01.20 15:21, Kevin A. McGrail wrote:
> >Correct, it's a policy issue. ASF Projects must stop providing SHA-1
> >signatures and we negotiated that deadline.
>
> do you mean, not having updates is better than using sha-
On 29.01.20 15:21, Kevin A. McGrail wrote:
Correct, it's a policy issue. ASF Projects must stop providing SHA-1
signatures and we negotiated that deadline.
do you mean, not having updates is better than using sha-1?
wouldn't clients supporting sha256 still use those over sha-1 or do you
expec
19 matches
Mail list logo
