RE: [qmailtoaster] DMARC checking?

2016-07-21 Thread Dan McAllister - QMT DNS Admin
LOL - Thanks for the "education" about DMARC :)

For the record, I depend heavily on DMARC records -- but 90% of mail servers 
that will even check for SPF, do so with the SPF record in mind, and not the 
DMARC one. As I asserted in my original message, only a few "big guns" are even 
looking at the DMARC records at all, much less providing the response 
mechanisms.

To my knowledge, the DMARC record cannot REPLACE the SPF record (they're both 
just TXT record lookups), but the DMARC record CAN tell a recipient server that 
you are interested in hearing about "bad mail" from your domain(s).
(Most SPF records end with a "~all" -- which is actually an indication that 
you're "just testing SPF" and creating a "soft fail" when it is violated. MY 
SPF records end with "-all" [that would be a DASH instead of a TILDE] -- which 
is an indication that we think we know what we're doing, and if It fails SPF, 
it should be considered a HARD FAIL... what you do with it after that is up to 
the recipient mail server. The supposition is that, someday, most will reject 
or discard HARD FAIL messages, but even in QMail, we have our own options (read 
up on SPF levels), so not everyone is playing by the same rules.)

Generally equivalent statements can be made about DKIM.

In NEITHER case have I seen any kind of documentation on what an organization 
is supposed to do if SPF says to HARD FAIL any disproven sender, but DMARC says 
not to... or the other way around!

So I repeat my assertion that the real VALUE of DMARC is in the back-reporting 
function which I will repeat has helped me numerous times to detect an 
issue BEFORE other mechanisms (like RBLs) have been triggered!

As you might expect, my servers & domains use SPF and DMARC -- and if we had 
better processing (long-standing bug) in QMAIL for DKIM, I would use it too!

Cheers!

Dan McAllister

PS: Perhaps when I retire in a few years I'll fix the DKIM processing and 
create DMARC processing for QMAIL :) 
Most on here don't know it, but I started in SW development tracking missiles 
at CCAFS!


-Original Message-
From: Eric [mailto:ebr...@whitehorsetc.com] 
Sent: Thursday, July 21, 2016 2:05 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] DMARC checking?

Dan,

This is from the DMARC website
(https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F):

"How does DMARC work, briefly, and in non-technical terms?"

"A DMARC policy allows a sender to indicate that their messages are protected 
by SPF and/or DKIM, and tells a receiver what to do if neither of those 
authentication methods passes – such as junk or reject the message. DMARC 
removes guesswork from the receiver’s handling of these failed messages, 
limiting or eliminating the user’s exposure to potentially fraudulent & harmful 
messages. DMARC also provides a way for the email receiver to report back to 
the sender about messages that pass and/or fail DMARC evaluation."

And:

"Why is DMARC needed?"

"End users and companies all suffer from the high volume of spam and phishing 
on the Internet. Over the years several methods have been introduced to try and 
identify when mail from (for example) IRS.GOV really is, or really isn’t coming 
from the IRS. However:

 These mechanisms all work in isolation from each other
 Each receiver makes unique decisions about how to evaluate the results
 The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:

 Domain owners to:
 Signal that they are using email authentication (SPF, DKIM)
 Provide an email address to gather feedback about messages using their 
domain – legitimate or not
 A policy to apply to messages that fail authentication (report, 
quarantine, reject)

 Email receivers to:
 Be certain a given sending domain is using email authentication
 Consistently evaluate SPF and DKIM along with what the end user sees 
in their inbox
 Determine the domain owner’s preference (report, quarantine or
reject) for messages that do not pass authentication checks
 Provide the domain owner with feedback about messages using their 
domain

A domain owner who has deployed email authentication can begin using DMARC in 
“monitor mode” to collect data from participating receivers. As the data shows 
that their legitimate traffic is passing authentication checks, they can change 
their policy to request that failing messages be quarantined. As they grow 
confident that no legitimate messages are being incorrectly quarantined, they 
can move to a 'reject' policy."

It seems to me that the DMARC website indicates that not only is feedback 
provided for but a message policy (report, quarantine, reject) for failed 
authentication.

Correc

Re: [qmailtoaster] DMARC checking?

2016-07-21 Thread Eric

Dan,

This is from the DMARC website 
(https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F):


"How does DMARC work, briefly, and in non-technical terms?"

"A DMARC policy allows a sender to indicate that their messages are 
protected by SPF and/or DKIM, and tells a receiver what to do if neither 
of those authentication methods passes – such as junk or reject the 
message. DMARC removes guesswork from the receiver’s handling of these 
failed messages, limiting or eliminating the user’s exposure to 
potentially fraudulent & harmful messages. DMARC also provides a way for 
the email receiver to report back to the sender about messages that pass 
and/or fail DMARC evaluation."


And:

"Why is DMARC needed?"

"End users and companies all suffer from the high volume of spam and 
phishing on the Internet. Over the years several methods have been 
introduced to try and identify when mail from (for example) IRS.GOV 
really is, or really isn’t coming from the IRS. However:


These mechanisms all work in isolation from each other
Each receiver makes unique decisions about how to evaluate the results
The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:

Domain owners to:
Signal that they are using email authentication (SPF, DKIM)
Provide an email address to gather feedback about messages 
using their domain – legitimate or not
A policy to apply to messages that fail authentication (report, 
quarantine, reject)


Email receivers to:
Be certain a given sending domain is using email authentication
Consistently evaluate SPF and DKIM along with what the end user 
sees in their inbox
Determine the domain owner’s preference (report, quarantine or 
reject) for messages that do not pass authentication checks
Provide the domain owner with feedback about messages using 
their domain


A domain owner who has deployed email authentication can begin using 
DMARC in “monitor mode” to collect data from participating receivers. As 
the data shows that their legitimate traffic is passing authentication 
checks, they can change their policy to request that failing messages be 
quarantined. As they grow confident that no legitimate messages are 
being incorrectly quarantined, they can move to a 'reject' policy."


It seems to me that the DMARC website indicates that not only is 
feedback provided for but a message policy (report, quarantine, reject) 
for failed authentication.


Correct me if I'm wrong.

Eric





On 7/20/2016 4:57 PM, Dan McAllister - QMT DNS Admin wrote:

I'm not sure what you mean by DMARC checking?
Generally, SPF is triggered by the existence of an appropriate DNS entry, while 
a DKIM check would be triggered by a DKIM signature in the header of the 
message.
The point of DMARC isn't to trigger any checking, it is to provide a FEEDBACK 
mechanism to senders whose domains may be being attacked or otherwise abused.
AFIK, only a few MAJOR mail providers are actively providing that feedback -- 
but even so, it's been EXTREMELY valuable to me as an ESP admin! They have 
helped me capture abuse far faster than otherwise possible!

So again, I'm not sure what you're asking for with regards to DMARC

Dan McAllister
IT4SOHO

-Original Message-
From: Eric [mailto:ebr...@whitehorsetc.com]
Sent: Wednesday, July 20, 2016 12:44 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] DMARC checking?

Jaime,

I'm not sure. It can be run from the command line so I'm wondering if it could 
not be put in a .qmail/.mailfilter file or even implemented with 
Dovecot...somehow?

Eric


On 7/20/2016 9:07 AM, Jaime Lerner wrote:

Is it possible to set up inbound DMARC checking on a QMT setup?


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



RE: [qmailtoaster] DMARC checking?

2016-07-20 Thread Dan McAllister - QMT DNS Admin
I'm not sure what you mean by DMARC checking?
Generally, SPF is triggered by the existence of an appropriate DNS entry, while 
a DKIM check would be triggered by a DKIM signature in the header of the 
message.
The point of DMARC isn't to trigger any checking, it is to provide a FEEDBACK 
mechanism to senders whose domains may be being attacked or otherwise abused.
AFIK, only a few MAJOR mail providers are actively providing that feedback -- 
but even so, it's been EXTREMELY valuable to me as an ESP admin! They have 
helped me capture abuse far faster than otherwise possible!

So again, I'm not sure what you're asking for with regards to DMARC

Dan McAllister
IT4SOHO

-Original Message-
From: Eric [mailto:ebr...@whitehorsetc.com] 
Sent: Wednesday, July 20, 2016 12:44 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] DMARC checking?

Jaime,

I'm not sure. It can be run from the command line so I'm wondering if it could 
not be put in a .qmail/.mailfilter file or even implemented with 
Dovecot...somehow?

Eric


On 7/20/2016 9:07 AM, Jaime Lerner wrote:
> Is it possible to set up inbound DMARC checking on a QMT setup?

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



Re: [qmailtoaster] DMARC checking?

2016-07-20 Thread Eric

Jaime,

I'm not sure. It can be run from the command line so I'm wondering if it 
could not be put in a .qmail/.mailfilter file or even implemented with 
Dovecot...somehow?


Eric


On 7/20/2016 9:07 AM, Jaime Lerner wrote:

Is it possible to set up inbound DMARC checking on a QMT setup?


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



[qmailtoaster] DMARC checking?

2016-07-20 Thread Jaime Lerner
Is it possible to set up inbound DMARC checking on a QMT setup?