date:20180126

[mailop] As I havent' seen this on the list as of yet.. serious problem with ClamAv affecting email servers..

2018-01-26 Thread Michael Peddemors


Just for the record, more information on the ClamAv mailing lists..

http://lists.clamav.net/pipermail/clamav-users/2018-January/005722.html

 
--

"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail's dkim=neutral

2018-01-26 Thread Leo Gaspard

On 01/26/2018 04:45 PM, Vladimir Dubrovin via mailop wrote:> Actually,
SPF can not protect against (visible) spoofing, because it
> doesn't check RFC5322.From, it performs sender's server identification
> for SMTP's MAIL FROM/HELO domain only.

Just adding that “it” also protects against visible spoofing when used
in conjunction with DMARC, as DMARC performs the “SPF” check against the
domain part of 5322.From

>> On the other hand, there could be false positives (like automatic
>> forwarding), but in this case DKIM should remain ok.
>>
> 
> Not exactly, because there are mailing lists, and list can modify
> message content, e.g. subject, like this one.

(actually, this one rewrote 5322.From, most likely because corp.mail.ru
publishes a p=reject DMARC record, so as not to break the DKIM signature
and thus send a DMARC-rejected email -- but that's maybe off-topic)

>> So when there's SPF, and it fails, AND there's DKIM, and it fails too,
>> I guess we can consider that the trap is working as intended, and try
>> to prevent a spoofing attempt from being successful.
> 
> Unfortunately, the fact message fails or passes SPF and DKIM doesn't
> have sufficient correlation with spam/ham or phishing/clear properties
> to use it directly, for large e-mail systems, at least. It may work for
> some private server where you can control all possible mail flows.

Also, RFC6376 §6.3:

   If the email cannot be verified, then it SHOULD be treated the same
   as all unverified email, regardless of whether or not it looks like
   it was signed.

As to why this makes sense, saying “there's DKIM and it fails” most
likely means there is a bug in the sender's mail system, not that there
is an attack: an attacker wouldn't earn anything against
not-utterly-ill-configured servers by adding a bogus DKIM signature.

However, note that §6.3 also states:

   [...] If an MTA does wish to reject such
   messages during an SMTP session (for example, when communicating with
   a peer who, by prior agreement, agrees to only send signed messages),
   and a signature is missing or does not verify, the handling MTA
   SHOULD use a 550/5.7.x reply code.

So it doesn't necessarily mean “let mail pass in the no-DKIM /
failing-DKIM case”, it just means “please handle both the same way.”

HTH,
Leo

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail's dkim=neutral

2018-01-26 Thread Vladimir Dubrovin via mailop

26.01.2018 17:37, Benjamin BILLON пишет:
>
> Thanks for those details,
>
>  
>
> My understanding is that SPF was primarily conceived against spoofing,
> and not for reputation purposes.
>
> It doesn't mean that spammers can't have a proper SPF. It doesn't mean
> that legitimate senders can't have no SPF.
>


It's right from RFC 7208:

   An additional benefit to mail receivers is that after the use of an
   identity is verified, local policy decisions about the mail can be
   made based on the sender's domain, rather than the host's IP address.
   This is advantageous because reputation of domain names is likely to
   be more accurate than reputation of host IP addresses since domains
   are likely to be more stable over a longer period.  Furthermore, if a
   claimed identity fails verification, local policy can take stronger
   action against such email, such as rejecting it.


Actually, SPF can not protect against (visible) spoofing, because it
doesn't check RFC5322.From, it performs sender's server identification
for SMTP's MAIL FROM/HELO domain only.



> On the other hand, there could be false positives (like automatic
> forwarding), but in this case DKIM should remain ok.
>

Not exactly, because there are mailing lists, and list can modify
message content, e.g. subject, like this one.


>  
>
> So when there's SPF, and it fails, AND there's DKIM, and it fails too,
> I guess we can consider that the trap is working as intended, and try
> to prevent a spoofing attempt from being successful.
>

Unfortunately, the fact message fails or passes SPF and DKIM doesn't
have sufficient correlation with spam/ham or phishing/clear properties
to use it directly, for large e-mail systems, at least. It may work for
some private server where you can control all possible mail flows.


>  
>
> But yeah, DMARC could help. With ISPs which actually check it.
>
>  
>
> Best,
>
> --
>
> Benjamin
>
>  
>
>  
>
> *From:*Vladimir Dubrovin [mailto:dubro...@corp.mail.ru]
> *Sent:* Friday, 26 January, 2018 19:32
> *To:* Benjamin BILLON 
> *Cc:* mailop@mailop.org
> *Subject:* Re: [mailop] Gmail's dkim=neutral
>
>  
>
> 26.01.2018 13:07, Benjamin BILLON пишет:
>
> Hi there!
>
>  
>
> I have a case where one sender's message has been abused, reused
> by someone who just added a Subject: line (so now there's two),
> before sending it.
>
> Apparently the final recipient was at Gmail (given the headers I
> had access to), and logically:
>
>   * SPF failed: the domain name of the MAIL FROM didn't allow this
> IP, which is not mine, to send. Fine.
>   * dkim=neutral (body hash did not verify): here I'm puzzled. One
> of the purposes of DKIM being to validate the consistency of
> the content. If the body hash doesn't verify, then it's
> inconsistent. Then why "neutral" and not a pure fail?
>
>  
>
>  
>
> none:
>
> The message was not signed.
>
> fail:
>
> The message was signed and the signature(s) is (were) acceptable to
> the verifier, but it (they) failed the verification test(s).
>
> neutral:
>
> The message was signed but the signature(s) contained syntax errors or
> were not otherwise able to be processed. This result SHOULD also be
> used for other failures not covered elsewhere in this list.
>
> permerror:
>
> The message could not be verified due to some error which is
> unrecoverable, such as a required header field being absent. A later
> attempt is unlikley to produce a final result.
>
>
> There is no much difference between these states, any state different
> from "pass" and "temperror" means message is not actually signed
> correctly. Invalid hash means DKIM-Signature header doesn't match the
> message. Verifier can treat it as either invalid DKIM-Signature header
> (neutral) or verification failure (fail), there is no strict
> requirements and there is no practical difference.
>
>
>   *  
>
>  
>
> Another question is how come the email hasn't been rejected
> already, with a failed SPF and a, let's say, neutral DKIM.
>
> I don't know if it hit junk folder or not (I like to believe it
> did, but I still receive the complaint).
>
>  
>
>
> Spammer can publish SPF and sign messages with DKIM.  The fact of DKIM
> presence or absence means nearly nothing. DKIM can be used by itself
> to use DKIM domain's reputation to validate message. Same goes to SPF.
> In the absence of DKIM or SPF, or if DKIM/SPF domains lacks reputation
> data, verifier can use reputation of IP address.
>
> An exception is if SPF and DKIM are used as authentication method
> within DMARC policy. If you want message with your From address to be
> rejected in the absence of both valid DKIM and SPF authentication you
> have to publish restrictive DMARC policy.
>
>
>
> Side not: the recipient we initially send the first message to was
> also a Gmail user.
>
>  
>
> Cheers,
>
> --
>
> Benjamin
>
>
>
>
>

Re: [mailop] Gmail's dkim=neutral

2018-01-26 Thread Benjamin BILLON

Thanks for those details,

My understanding is that SPF was primarily conceived against spoofing, and not 
for reputation purposes.
It doesn't mean that spammers can't have a proper SPF. It doesn't mean that 
legitimate senders can't have no SPF.
On the other hand, there could be false positives (like automatic forwarding), 
but in this case DKIM should remain ok.

So when there's SPF, and it fails, AND there's DKIM, and it fails too, I guess 
we can consider that the trap is working as intended, and try to prevent a 
spoofing attempt from being successful.

But yeah, DMARC could help. With ISPs which actually check it.

Best,
--
Benjamin


From: Vladimir Dubrovin [mailto:dubro...@corp.mail.ru]
Sent: Friday, 26 January, 2018 19:32
To: Benjamin BILLON 
Cc: mailop@mailop.org
Subject: Re: [mailop] Gmail's dkim=neutral

26.01.2018 13:07, Benjamin BILLON пишет:
Hi there!

I have a case where one sender's message has been abused, reused by someone who 
just added a Subject: line (so now there's two), before sending it.
Apparently the final recipient was at Gmail (given the headers I had access 
to), and logically:

  *   SPF failed: the domain name of the MAIL FROM didn't allow this IP, which 
is not mine, to send. Fine.
  *   dkim=neutral (body hash did not verify): here I'm puzzled. One of the 
purposes of DKIM being to validate the consistency of the content. If the body 
hash doesn't verify, then it's inconsistent. Then why "neutral" and not a pure 
fail?


none:
The message was not signed.
fail:
The message was signed and the signature(s) is (were) acceptable to the 
verifier, but it (they) failed the verification test(s).
neutral:
The message was signed but the signature(s) contained syntax errors or were not 
otherwise able to be processed. This result SHOULD also be used for other 
failures not covered elsewhere in this list.
permerror:
The message could not be verified due to some error which is unrecoverable, 
such as a required header field being absent. A later attempt is unlikley to 
produce a final result.

There is no much difference between these states, any state different from 
"pass" and "temperror" means message is not actually signed correctly. Invalid 
hash means DKIM-Signature header doesn't match the message. Verifier can treat 
it as either invalid DKIM-Signature header (neutral) or verification failure 
(fail), there is no strict requirements and there is no practical difference.



  *

Another question is how come the email hasn't been rejected already, with a 
failed SPF and a, let's say, neutral DKIM.
I don't know if it hit junk folder or not (I like to believe it did, but I 
still receive the complaint).


Spammer can publish SPF and sign messages with DKIM.  The fact of DKIM presence 
or absence means nearly nothing. DKIM can be used by itself to use DKIM 
domain's reputation to validate message. Same goes to SPF. In the absence of 
DKIM or SPF, or if DKIM/SPF domains lacks reputation data, verifier can use 
reputation of IP address.

An exception is if SPF and DKIM are used as authentication method within DMARC 
policy. If you want message with your From address to be rejected in the 
absence of both valid DKIM and SPF authentication you have to publish 
restrictive DMARC policy.



Side not: the recipient we initially send the first message to was also a Gmail 
user.

Cheers,
--
Benjamin




___

mailop mailing list

mailop@mailop.org

https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



--

Vladimir Dubrovin

@Mail.Ru
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail's dkim=neutral

2018-01-26 Thread Vladimir Dubrovin via mailop

26.01.2018 13:07, Benjamin BILLON пишет:
>
> Hi there!
>
>  
>
> I have a case where one sender's message has been abused, reused by
> someone who just added a Subject: line (so now there's two), before
> sending it.
>
> Apparently the final recipient was at Gmail (given the headers I had
> access to), and logically:
>
>   * SPF failed: the domain name of the MAIL FROM didn't allow this IP,
> which is not mine, to send. Fine.
>   * dkim=neutral (body hash did not verify): here I'm puzzled. One of
> the purposes of DKIM being to validate the consistency of the
> content. If the body hash doesn't verify, then it's inconsistent.
> Then why "neutral" and not a pure fail?
>


none:
The message was not signed.

fail:

The message was signed and the signature(s) is (were) acceptable to
the verifier, but it (they) failed the verification test(s).

neutral:
The message was signed but the signature(s) contained syntax errors
or were not otherwise able to be processed. This result SHOULD also
be used for other failures not covered elsewhere in this list.

permerror:

The message could not be verified due to some error which is
unrecoverable, such as a required header field being absent. A later
attempt is unlikley to produce a final result.


There is no much difference between these states, any state different
from "pass" and "temperror" means message is not actually signed
correctly. Invalid hash means DKIM-Signature header doesn't match the
message. Verifier can treat it as either invalid DKIM-Signature header
(neutral) or verification failure (fail), there is no strict
requirements and there is no practical difference.

>  *
>
>
>  
>
> Another question is how come the email hasn't been rejected already,
> with a failed SPF and a, let's say, neutral DKIM.
>
> I don't know if it hit junk folder or not (I like to believe it did,
> but I still receive the complaint).
>
>  
>

Spammer can publish SPF and sign messages with DKIM.  The fact of DKIM
presence or absence means nearly nothing. DKIM can be used by itself to
use DKIM domain's reputation to validate message. Same goes to SPF. In
the absence of DKIM or SPF, or if DKIM/SPF domains lacks reputation
data, verifier can use reputation of IP address.

An exception is if SPF and DKIM are used as authentication method within
DMARC policy. If you want message with your From address to be rejected
in the absence of both valid DKIM and SPF authentication you have to
publish restrictive DMARC policy.


> Side not: the recipient we initially send the first message to was
> also a Gmail user.
>
>  
>
> Cheers,
>
> --
>
> Benjamin
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Gmail's dkim=neutral

2018-01-26 Thread Benjamin BILLON

Hi there!

I have a case where one sender's message has been abused, reused by someone who 
just added a Subject: line (so now there's two), before sending it.
Apparently the final recipient was at Gmail (given the headers I had access 
to), and logically:

  *   SPF failed: the domain name of the MAIL FROM didn't allow this IP, which 
is not mine, to send. Fine.
  *   dkim=neutral (body hash did not verify): here I'm puzzled. One of the 
purposes of DKIM being to validate the consistency of the content. If the body 
hash doesn't verify, then it's inconsistent. Then why "neutral" and not a pure 
fail?

Another question is how come the email hasn't been rejected already, with a 
failed SPF and a, let's say, neutral DKIM.
I don't know if it hit junk folder or not (I like to believe it did, but I 
still receive the complaint).

Side not: the recipient we initially send the first message to was also a Gmail 
user.

Cheers,
--
Benjamin
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Fasthosts.co.uk on here?

2018-01-26 Thread Paul Smith


On 25/01/2018 21:46, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2018-01-24 at 09:30 -0500, Al Iverson wrote:

Smells like a Fasthosts misconfiguration from here.

If they are doing ip queries against the DBL for all connections, they
will be refusing all incoming email. One might think that would be
quickly noticed and corrected. Perhaps they only do those queries for
some subset of the inbound mail.


We haven't had any more instances of this happening since Monday. We 
also had had other (good) mail that had worked before suddenly being 
blocked due to other DNSBLs. So, my suspicion is that over the weekend 
someone decided to 'improve' their spam filter and went a bit too far, 
and then at least some of those 'improvements' were rolled back on Monday.


(Our server doesn't use an IP address literal in EHLO, so I don't think 
it's that).





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] As I havent' seen this on the list as of yet.. serious problem with ClamAv affecting email servers..

Re: [mailop] Gmail's dkim=neutral

Re: [mailop] Gmail's dkim=neutral

Re: [mailop] Gmail's dkim=neutral

Re: [mailop] Gmail's dkim=neutral

[mailop] Gmail's dkim=neutral

Re: [mailop] Anyone from Fasthosts.co.uk on here?

7 matches

Site Navigation

Mail list logo

Footer information