Re: [dmarc-discuss] Heterogeneity in handling non-OD inputs among web-based DMARC checking tools

[Scott Kitterman via dmarc-discuss]

On Thursday, December 30, 2021 3:24:43 PM EST su...@banbreach.com via dmarc-
discuss wrote:
> On Friday, December 31, 2021 00:05 IST, Scott Kitterman via dmarc-discuss 
 wrote:
> > On Thursday, December 30, 2021 1:02:33 PM EST su...@banbreach.com via
> > dmarc-> 
> > discuss wrote:
> > > osx:~ test$ dig _dmarc.gov.in txt
> > > 
> > > Does RFC 7489 allow an eTLD to set up a DMARC record?
> > 
> > It does not.  RFC 9091 does.
> 
> Thanks.
> 
> 1. Since gov.in is not part of the PSD DMARC test group, what is the correct
> interpretation of the gov.in DMARC record?
> 
> 2. When searching for DMARC records for net.ac, Proofpoint reports that the
> record is empty, Valimail reports the record is not-configured, Agari and
> Dmarcian report no DMARC record found. A consistent, correct error message
> would be helpful irrespective of which vendor's tool we use. Will be
> addressed in RFC 9091?

Per RFC 9091, since gov.in isn't listed in one of the registries, the record 
would not be used.  Those can be updated, so that's not necessarily going to 
stay that way.  Also, as John Levine mentioned, in the update that we have in 
progress in the working group, the record would be used.

No.  RFC 9091 is published and complete.  It does not address that point.

Scott K


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Heterogeneity in handling non-OD inputs among web-based DMARC checking tools

[Scott Kitterman via dmarc-discuss]

On Thursday, December 30, 2021 1:02:33 PM EST su...@banbreach.com via dmarc-
discuss wrote:
> On Thursday, December 30, 2021 18:40 IST, Alessandro Vesely via dmarc-
discuss  wrote:
> > gov.in isn't listed in http://psddmarc.org/registry.html
> 
> Thanks. I believe my question was not entirely clear. Let me rephrase.
> 
> osx:~ test$ dig _dmarc.gov.in txt
> 
> ; <<>> DiG 9.8.3-P1 <<>> _dmarc.gov.in txt
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38605
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;_dmarc.gov.in.   IN  TXT
> 
> ;; ANSWER SECTION:
> _dmarc.gov.in.3303IN  TXT "v=DMARC1\; 
> p=quarantine\; sp=none\;
> fo=1\;rua=mailto:pmaster-wl...@gov.in\;ruf=mailto:pmaster-wl...@gov.in;
> 
> ;; Query time: 125 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Thu Dec 30 23:20:20 2021
> ;; MSG SIZE  rcvd: 145
> 
> Does RFC 7489 allow an eTLD to set up a DMARC record?

It does not.  RFC 9091 does.

Scott K


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Problems with settings DMARC

[Scott Kitterman via dmarc-discuss]

On May 25, 2020 12:33:45 AM UTC, Figo Morales via dmarc-discuss 
 wrote:
>I keep getting this message from my crons job:
>
>DMARC failure to load tld list
>'/usr/share/publicsuffix/public_suffix_list.dat': No such file or
>directory
>
>Any help is welcome.

If you are using Debian or a Debian derivative such as Ubuntu, install the 
publicsuffix package.

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC vs DKIM keys with s=mtasts

[Scott Kitterman via dmarc-discuss]

On March 29, 2020 10:36:50 PM UTC, John Levine  wrote:
>In article <3074162.RNaZIRUnTP@l5580> you write:
>>RFC 6376, Section 3.6.1, in the s= paragraphs says:
>>
>>> *  matches all service types
>>
>>If libopendkim and Mail::DKIM are looking for a literal '*' as the
>service 
>>type, rather than accepting any value for service type, they are buggy
>and 
>>should be fixed AFAICT.
>
>If there's an s= tag, they accept "*" or a colon separated list that
>contains "email".  My locally patched libopendkim does what pydkim
>does and also accepts a list with "tlsrpt".
>
>The language in 6376 says if a key record has an s= tag and it doesn't
>have a value we like, we ignore the record.  That's why the DKIM
>signatures with s=tlsrpt don't validate, since that's not a key that's
>valid for the 'email' service.
>
>>> RFC 8460 says the key SHOULD have s=tlsrpt and the recipient MAY
>ignore
>>> reports without that service type.  I'm inclined to consider that an
>error
>>> in view of experience with it.  Different service types are for
>messages
>>> delivered some way other than SMTP.
>>
>>I'm not sure that follows if service types are correctly processed.  I
>am 
>>curious what you think it a kludge in dkimpy?
>
>Since RFC 8460 doesn't update 6376, I'm confident that an s=tlsrpt key
>shouldn't validate a signature on ordinary e-mail not intended as a
>TLS report.  Arguably, it shouldn't validate e-mail even if it *is*
>intended as a report, since the spec says s= is there for "other
>services" and TLS reports aren't another service, they're e-mail.  If
>you want to make RFC 8460 happy, add another signature separate from
>the one that email uses.
>
>My recollection from back when that language was written 15 years ago
>is that we meant service in the RFC 6335 sense, different things that
>would never show up in the same stream as e-mail messages.  The
>specific example was signing SIP headers, which I think would have
>been a better idea than much more complex STIR/SHAKEN.  It still might
>be interesting to put DKIM signatures on HTTP messages.

I don't think 8460 needed to update 6376, since valid service values are 
defined by the registry, not by 6376.  The mistake was not updating the 
registry.

After looking at it again, I see your point about ignoring unknown service 
types.  I agree a second signature for regular email stream validation (e.g. 
DMARC) would make sense.

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC vs DKIM keys with s=mtasts

[Scott Kitterman via dmarc-discuss]

On Sunday, March 29, 2020 4:03:42 PM EDT John R Levine via dmarc-discuss 
wrote:
...
> The C libopendkim and perl Mail::DKIM libraries have hard-coded tests for
> 'email' or '*'.  Python dkimpy has a kludge that accepts 'tlsrpt' along
> with the other two.  None of them have a way to say to look for a service
> type other than 'email',
> 
> Beyond the kludge in dkimpy I don't see how to make mta-sts work properly
> with DMARC other than by even more grotesque kludges.

RFC 6376, Section 3.6.1, in the s= paragraphs says:

> *  matches all service types

If libopendkim and Mail::DKIM are looking for a literal '*' as the service 
type, rather than accepting any value for service type, they are buggy and 
should be fixed AFAICT.

> RFC 8460 says the key SHOULD have s=tlsrpt and the recipient MAY ignore
> reports without that service type.  I'm inclined to consider that an error
> in view of experience with it.  Different service types are for messages
> delivered some way other than SMTP.

I'm not sure that follows if service types are correctly processed.  I am 
curious what you think it a kludge in dkimpy?  I think what the latest version 
is doing is what is defined in RFC 6376 and RFC 8460 (there are some additional 
restrictions on tlsrpt processing defined in RFC 8460).  Before RFC 8460 came 
up dkimpy ignored s= completely because there wasn't anything specific to do 
for specific service types and anything is valid.

On a related note, RFC 8460 neglected to register the new service type.  I've 
filed an erratum about that:

https://www.rfc-editor.org/errata/eid5889

Scott K




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC and SPF Failures

[Scott Kitterman via dmarc-discuss]

On February 21, 2020 4:46:32 PM UTC, Marisa Clardy via dmarc-discuss 
 wrote:
>Hello,
>
>This may have already been discussed before, but I couldn't find
>anything
>about it.
>
>In our organization, we provide mail filtering for customers. We had
>SPF
>failures being rejected for a long time, however recently, we
>implemented
>DMARC, and set it so that if a domain has a DMARC policy, it doesn't
>reject
>based on an SPF failure.
>
>Some of our customers have complained about this, specifically in the
>cases
>where p=none. They say that when p=none, we should still reject SPF
>failures.
>
>My manager and I both agree that this isn't the case, based on our
>understanding of DMARC.
>
>Either way, even if we reject SPF failures on p=none, we will need to
>find
>a solution that retains DMARC's ability to report. The biggest problem
>for
>this though is we do SPF failures after the RCPT TO command, and have
>to do
>it there, because we have flags that let specific customers turn off
>SPF
>rejection, so it's not like we can just move the SPF rejection to after
>the
>DATA command.
>
>As such, we were curious about what the greater DMARC community thinks
>about this.

You can do it however makes sense for you.  See RFC 7489 Section 6.7 [1].  

Personally, I'm highly unlikely to publish a DMARC policy other than p=none due 
to high false positive rates.  I have a SPF policy that ends in -all, since I 
have very few problems with SPF false positives.

For myself, I'd certainly prefer you continue to reject SPF failures.

Scott K


[1] https://tools.ietf.org/html/rfc7489#section-6.7

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Substituted Source IP question

[Scott Kitterman via dmarc-discuss]

This is why DMARC uses an 'or' vice 'and' test between aligned DKIM and SPF 
results.  There are cases where on fails and the other succeeds, so overall the 
reliability is higher if you do both.

Scott K

On November 18, 2018 1:02:48 PM UTC, Edward Siewick via dmarc-discuss 
 wrote:
>Thanks Randal.  This confirms the university's view of the situation.  
>So there's some work needed to accommodate this across our mail
>domains.
>
>It also means a mandate for SPF and DMARC w/o also specifying DKIM for 
>the From: domain is problematic.
>
>Regards,
>Edward
>-- 
>
>On 11/18/2018 03:46 AM, Randal Pinto wrote:
>> Very common Edward. You’ll also see this when you email distribution
>lists or when people have forwarding rules setup on their inboxes.
>These are situations where DKIM is required for a successful DMARC
>validation.
>>
>> Best,
>> Randal
>> https://redsift.com
>>
>>
>>> On 17 Nov 2018, at 18:32, Edward Siewick via dmarc-discuss
> wrote:
>>>
>>> ---
>>> Authentication: pass
>>> Contents: pass
>>> Trust: warn
>>> ---
>>> * Message scanned by OnINBOX from Red Sift *
>>>
>>>
>>> I'm requesting insights on an oddity impacting the Source IP
>appearing in received RUA reports.
>>>
>>> A university receiving my organization's emails is sending RUAs that
>identify the university's own mailhosts as the Source IP for the
>messages.  The DKIM domain reflects my organization's named domains.
>Their explanation is that the mail is being forwarded internally from
>an external facing AWS-hosted mailhost to a gmail service that handles
>their end user mailboxes.
>>>
>>> The resulting records in the RUA reports look rather hinky to me. I
>have an opportunity to discuss the matter with the university's
>software engineer responsible for this. So insights on whether RUAs
>with other than the true original Source IP is commonplace would be
>helpful.
>>>
>>> Edward
>>>
>>> -- 
>>>
>>>
>>> ___
>>> dmarc-discuss mailing list
>>> dmarc-discuss@dmarc.org
>>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>>
>>> NOTE: Participating in this list means you agree to the DMARC Note
>Well terms (http://www.dmarc.org/note_well.html)
>
>
>___
>dmarc-discuss mailing list
>dmarc-discuss@dmarc.org
>http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
>NOTE: Participating in this list means you agree to the DMARC Note Well
>terms (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

[Scott Kitterman via dmarc-discuss]

On October 9, 2018 10:37:49 PM UTC, John Levine via dmarc-discuss 
 wrote:
>In article <24dd5bc1-ca89-473c-9d11-cb712504c...@akamai.com> you write:
>>p=none -> “we’re trying to figure out if we’re going to be able to go
>to p=quarantine”
>>
>>If you treat quarantine differently than none, you’re sending me
>misleading data in the reports you send (if of course
>>you send reports) - or your downstream recipients send.
>
>Sorry, but that is just wrong.  I publish p=none because that is my
>policy.  That's what the spec says, that's what it means.
>
>R's,
>John

Same here.  I publish p=none to get the feedback.  I don't have any idea which 
decade it will be when mailing lists are either updated or obsoleted 
sufficiently so that it might be reasonable for me to even consider anything 
else.

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] DMARC Reporting De-duplication

[Scott Kitterman via dmarc-discuss]

I participate in a lot of mailing lists many of which that have a large number 
of subscribers.  As a result, when I send a single message to a mailing list, 
many copies of the same message get sent to users at large mail providers.  
These get counted as individual messages in aggregate reporting.

As an example, I have been able to find four messages I sent to 
lists.debian.org email lists on April 30th.  The volume reported for that 
source for that day from various feedback reporters was 2,436.  This makes it 
a little hard to consume the feedback.

Shouldn't it be possible to de-duplicate these based on message ID before 
sending aggregate reports back?  Can/should this be added to DMARC the next 
time the specification is updated?

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

[Scott Kitterman via dmarc-discuss]

On Sunday, April 22, 2018 02:12:33 PM Roland Turner via dmarc-discuss wrote:
> On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote:
> > As most of you already know, the DCRUP working group is adding a new
> > signature algorithm to DKIM.  I have been sending dual
> > rsa-sha256/ed25519-sha256 signed mail for some time and I have notice an
> > oddity in DMARC reporting.> 
> > Typically, I'll see something like this XML snippet:
> > 
> > 
> > 
> > 
> > kitterman.com
> > pass
> > 201803r
> > 
> > 
> > 
> > 
> > kitterman.com
> > fail
> > 201803e
> > 
> > 
> > 
> > The first one is the rsa-sha256 signature and the second, marked fail, is
> > the ed25519-sha256 signature (I can tell based on the selector).  In all
> > cases I've checked, the correct (DMARC pass) result was obtained, but I
> > don't think this is the best way to report it.
> 
> It would be helpful for the receiver to explain that the problem is an
> interoperability one rather than an asserted failure of an implemented
> algorithm, certainly.
> 
> > RFC 6376 says:
> >> 3.3.4.  Other Algorithms
> >> 
> >> Other algorithms MAY be defined in the future.  Verifiers MUST ignore
> >> any signatures using algorithms that they do not implement.
> > 
> > I'm not sure reporting a failure is consistent with "MUST ignore".  In any
> > case, I think it would be useful to distinguish between DKIM evaluation
> > failed and not evaluated due to unknown algorithm in DMARC reporting.
> 
> There are half a dozen things which must be ignored if not supported
> (canonicalisations, etc.), but the obligation to ignore doesn't appear
> to imply an obligation not to report by whatever means are appropriate,
> only that the ignored elements must be removed from consideration prior
> to computing a pass.
> 
> More directly, in 6.3 Interpret Results/Apply Local Policy:
> > 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.
> 
> This would appear to encourage treating 3.3.4 cases in the same way as
> all unverified email, i.e. reporting a fail, as the example you quote
> does. I do note that RFC 7601 - whose results RFC 7489 uses -
> establishes separate criteria for none, fail, policy, and neutral. It
> might be argued that neutral is a better fit for reporting the use of a
> signature algorithm not supported by the verifier:
> 
> none:  The message was not signed.
> 
> pass:  The message was signed, the signature or signatures were
>acceptable to the ADMD, and the signature(s) passed verification
>tests.
> 
> fail:  The message was signed and the signature or signatures were
>acceptable to the ADMD, but they failed the verification test(s).
> 
> policy:  The message was signed, but some aspect of the signature or
>signatures was not acceptable to the ADMD.
> 
> neutral:  The message was signed, but the signature or signatures
>contained syntax errors or were not otherwise able to be
>processed.  This result is also used for other failures not
>covered elsewhere in this list.
> 
> 
> Would using neutral with some explanatory text in a human_result element
> suit, or would you advocate the addition of "unsupported" (or similar)
> to 7601 and 7489?

I think neutral is reasonable.  I'd add to the definition above that the 
signature was not used for DMARC evaluation.  Neutral is what multiple 
implementations already report in their authentication results header fields 
for these signatures:

Authentication-Results: mx.google.com;
   dkim=neutral (no key) header.i=@kitterman.com header.s=201803e 
header.b=hxFQlnEt;

Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral
 reason="invalid (unsupported algorithm ed25519-sha256)"
 header.d=kitterman.com header.b=INr2EzUJ;

Scott K


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

[Scott Kitterman via dmarc-discuss]

As most of you already know, the DCRUP working group is adding a new signature 
algorithm to DKIM.  I have been sending dual rsa-sha256/ed25519-sha256 signed 
mail for some time and I have notice an oddity in DMARC reporting.

Typically, I'll see something like this XML snippet:



kitterman.com
pass
201803r


kitterman.com
fail
201803e


The first one is the rsa-sha256 signature and the second, marked fail, is the 
ed25519-sha256 signature (I can tell based on the selector).  In all cases 
I've checked, the correct (DMARC pass) result was obtained, but I don't think 
this is the best way to report it.

RFC 6376 says:

> 3.3.4.  Other Algorithms
> 
>Other algorithms MAY be defined in the future.  Verifiers MUST ignore
>any signatures using algorithms that they do not implement.

I'm not sure reporting a failure is consistent with "MUST ignore".  In any 
case, I think it would be useful to distinguish between DKIM evaluation failed 
and not evaluated due to unknown algorithm in DMARC reporting.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC fail for our subdomains, why?

[Scott Kitterman via dmarc-discuss]

On Thursday, March 23, 2017 03:31:14 PM Peter Olsson via dmarc-discuss wrote:
...
> MD.se. TXT "v=spf1 ip4:X ip4:X ip4:X ip4:X ip4:X/24 ip4:X/24 ip4:X ip6:X
> ip6:X ip6:X include:X -all"
...

Is md.se the actual domain?  I don't see a TXT record in DNS.

$ dig -x md.se

; <<>> DiG 9.9.5 <<>> -x md.se
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7664
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

If the SPF record isn't actually published, then the SPF result may be a 
result based on SPF "Best guess" [1].  Google is known to use best guess 
internally and will generate an SPF results header field based on it.  I don't 
recall if it is specified that it's a best guess result or not.

If it is best guess, I  also don't know if Google considers a best guess 
result as sufficient for DMARC.

I don't mind taking a quick look at the SPF result.  Please send me:

The actual domain
The full SPF record you think you have published
The full Google SPF results header field (most importantly including the X 
that is the IP address it was from).

It might as well be offlist as there isn't much value in cluttering the list 
with the details.

Scott K


[1] http://www.openspf.org/FAQ/Best_guess_record

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] Getting to reject, was :Re: FortiNet’s FortiMail DMARC implementation

[Scott Kitterman via dmarc-discuss]

On November 14, 2016 2:42:42 PM EST, Terry Zink via dmarc-discuss 
 wrote:
>> Well, DMARC addresses one particular vector - we still need to find
>more effective ways 
>> to address cousin domains, display name abuse, etc.
>
>I didn't mean cousin domains, I mean domains that are not the same but
>have a relationship (e.g., one is a vendor of the other). They both
>have weak authentication records (no DMARC, or DMARC + p=none), and
>then one of them gets spoofed.
>
>So yes, the fix is to publish a stronger DMARC policy, but lots of
>domains who publish DMARC have a weak policy. It's hard to get to
>p=reject/quarantine if you are not a big company and are doing it
>yourself.

It's also essentially impossible if you make non-trivial use of mailing lists.  
Even though I've has SPF -all records for over a decade and encourage people to 
reject mail purporting to be from my domains that fail SPF, I am no where near 
being able to do so for DMARC because of mailing lists.

p= none is not just because people don't care.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC and null path

[Scott Kitterman via dmarc-discuss]

On May 13, 2016 4:56:40 PM EDT, "A. Schulze via dmarc-discuss" 
 wrote:
>
>
>Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss:
>> In Office 365 it would. Others' implementations may vary.
>
>"may or may not" - is that really the intention of DMARC?

I think RFC 7489, paragraph 3.1.2 is very explicit about this.  It is supposed 
to pass and if it doesn't it's a bug.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC and null path

[Scott Kitterman via dmarc-discuss]

There is a subtle distinction involved here.  RFC 7208 (and RFC 4408 before 
it) don't literally say to use RFC5321.Helo if RFC5321.Mailfrom is null.  What 
they say to to construct a MailFrom using postmas...@rfc5321.helo.  That's the 
difference between RFC5321.Mailfrom and RFC7208/4408.Mailfrom which is what 
DMARC uses.  

So technically, DMARC always uses Mailfrom for SPF, but that Mailfrom may have 
been, in some cases, constructed using Helo.

People often say things like "use Helo if Mailfrom is null", but that's 
shorthand, not precisely what the RFCs say to do.

Scott K

On Monday, May 09, 2016 09:50:33 PM Maarten Oelering via dmarc-discuss wrote:
> Hi Franck,
> 
> You explained this before, but also then I didn’t quite understand.
> 
> First you say there is the SPF check on HELO and on MAILFROM. That I know
> and understand. Then you say DMARC only uses the RFC5321.Mailfrom, but
> which includes falls back on RFC5321.Helo.
> 
> But isn’t that the same in practice? The HELO domain is the HELO domain.
> Or is the difference that alignment is required when
> postmaster@ is used in DMARC context?
> 
> Thanks,
> 
> Maarten
> 
> > On 9 mei 2016, at 19:27, Franck Martin via dmarc-discuss
> >  wrote:
> > 
> > SPF provides 2 results. People get confused because they often think there
> > is only one.
> > 
> > The first result is based on the RFC7489.HELO and the second result is
> > based on the RFC7489.MAILFROM.
> > 
> > The first result could allow you to close a connection at the RFC5321.Helo
> > stage, while the second result would allow you to close the connection
> > after the RFC5321.Mailfrom. In practice both results are integrated in
> > higher reputation layers...
> > 
> > DMARC uses only the second result (and identifiers).
> > 
> > As a side note and as Terry points out, Office 365, only uses the second
> > results for SPF. Many implementations of SPF use only the second result.
> > 
> > RFC7489.MAILFROM is defined as RFC5321.MailFrom unless it is empty, in
> > that case it is postmaster@
> > 
> > Hope this helps.
> > 
> > On Mon, May 9, 2016 at 8:17 AM, Terry Zink via dmarc-discuss
> > > wrote: This is
> > a good point, I'm not sure about how others do it, but in Office 365 we
> > compare the 5322.From domain against the domain that was used to
> > authenticate SPF. That's the 5321.MailFrom unless it is <>, in which case
> > we use the HELO/EHLO domain. That would allow a DMARC pass in the absence
> > of a DKIM signature.
> > 
> > -- Terry
> > 
> > -Original Message-
> > From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org
> > ] On Behalf Of Sistemisti Posta
> > via dmarc-discuss Sent: Monday, May 9, 2016 3:38 AM
> > To: dmarc-discuss@dmarc.org 
> > Subject: [dmarc-discuss] DMARC and null path
> > 
> > Hello DMARC users,
> > 
> >because I'm new in DMARC world I'm trying to understand some details
> > 
> > before to start with policy implementation.
> > 
> > A detail I would understand is related to mails with null path, or null
> > sender address, typically sent by Delivery Status Notifications.
> > 
> > It seems that the only way to pass DMARC with null path is to DKIM sign
> > the mails. Is it true?
> > 
> > I ask this because RFC7489 says that exists a condition when DMARC
> > considers the null path:
> > 
> > "Note that the RFC5321.HELO identity is not typically used in the
> > 
> > context of DMARC (except when required to "fake" an otherwise null
> > reverse-path)"
> > 
> > And:
> > 
> > "DMARC uses the result of SPF authentication of the MAIL FROM identity.
> > Section 2.4 of [SPF] describes MAIL FROM processing for cases in which
> > the MAIL command has a null path."
> > 
> > RFC4408 says accordingly:
> > 
> > 'When the reverse-path is null, this document defines the "MAIL FROM"
> > identity to be the mailbox composed of the localpart "postmaster" and
> > the "HELO" identity (which may or may not have been checked separately
> > before).'
> > 
> > So if a mail with null path and HELO domain equal to RFC5322.From passes
> > the SPF check, why should DMARC fail?
> > 
> > See at this live example:
> > 
> > libero.it  descriptive text "v=spf1
> > ip4:212.48.25.128/25  ip4:212.48.14.160/27
> >  include:srs.bis.na.blackberry.com
> >  include:srs.bis.eu.blackberry.com
> >  include:srs.bis.ap.blackberry.com
> >  include:mail.zendesk.com
> >  -all"
> > _dmarc.libero.it  descriptive text "v=DMARC1\;
> > p=quarantine\; ...
> > 
> > If 212.48.14.166  sends a mail with null path,
> > RFC5322.From=@libero.it  and *helo=libero.it
> > *, then SPF thinks to have 

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Tuesday, February 16, 2016 06:17:27 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> > To
> > the extent ARC is useful to mitigate the DMARC mailing list issue, it's
> > only useful with additional data inputs that are not public and are not
> > feasible for small providers to generate on their own.
> 
> I meant to ask earlier: would you level the same criticism at SMTP, given
> that running a useful mail-receiving-server without a solid DNSBL is now
> more-or-less infeasible? Does the fact that Spamhaus is already available
> free of charge to all of the small guys change this analysis?

The fact that there are high quality services available free/reasonable for a 
little guy to pay does alter my perspective.  At the time  DNSBLs were 
becoming popular/necessary there wasn't the same level of concentration in the 
market and even going back to open relay lists there's ~always been something 
anyone on a modest budget could use.

> Perhaps the fact that SMTP was developed at a time that abuse was not
> widespread gives it a free pass on this front? Presumably you don't argue
> that, *because* we're already in a high-abuse environment we should
> therefore cease collaboration on any class of solution which happens to
> require more data than is either: (a) feasible for small guys to process
> usefully, or
> (b) available to small guys at all?

SMTP has always been, with a little study, been something any competent admin 
could do.  It takes a lot more study and more resources than a decade or two 
ago, but we haven't, in my opinion, crossed a tipping point where that's not 
longer possible.  So SMTP gets a pass because it's ~always been accessible (I 
know in the dim reaches of history that wasn't quite always so).

I think solutions feasible for one segment of the market (large, small, 
purple, blue, don't care) are fine to collaborate on as long as people are 
clear it's a partial solution.  

> Would the public availability from a trustworthy source of data that makes
> it possible to use ARC to decide when to override DMARC policies[1] change
> your position?
> 
> - Roland
> 
> 1: I *don't* believe that this would take the form of a whitelist. It's more
> like the ability to recognise changes in baseline behaviour by forwarders
> who may or may not be ARC signing. I suspect that John Levine's concerns
> about whitelists have some strength.

It would as that data is the barrier to entry I'm worried about.  I think it's 
actually two lists:

1.  Domains good enough you ought to trust to believe what they say in ARC.
2.  Domains bad enough you ought to reject their mail if they show up in ARC.

I do wonder though if I have the data to toss the message why they didn't in 
the first place (and if they didn't why I should trust them).  So generically, 
yes, but I'm not certain what the characteristics of such a data source would 
be.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Tuesday, February 16, 2016 06:02:31 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> >> Roland Turner wrote:
> >> 
> >> This is just a diffusion process, not an exclusion of smaller players.
> >> Indeed, it would almost appear that you'd be happier if the big guys had
> >> excluded smaller players from this initiative...
> > 
> > Until maybe someday the results of the analysis to use ARC are somehow
> > available, they have.
> 
> All diffusion looks like this.
> 
> The "one size fits all" mentality gave us the lost decade. Recognising that
> differently-situated practitioners need different things and developing a
> range of tools/protocols/etc. to suit the range of needs (most of which
> will be not useful for most practitioners) is not merely more effective, it
> currently appears to be the only way forward.
> > The use of an open standard (which I am in favor of and
> > this is good), doesn't materially change that.  If I can write code to
> > implement a standard, but don't have the necessary inputs to use it, it's
> > not particularly of use.
> 
> "not particularly of use to Scott" != "not useful".
> 
> This is of course a different question to the one about whether/how to
> involve yourself, more below.
> > Personally, I try to consider putting my time where either I'll benefit
> 
> Eminently sensible, I do the same.
> 
> > or I think the global Internet will benefit.
> 
> Likewise, and so here's the challenge: the big guys hardening their part of
> the environment against criminals doesn't merely improve life for the big
> guys (e.g. by shifting criminals' focus elsewhere), they are so big that
> they are materially altering the economics in a way that makes crime less
> profitable and therefore less likely than it would otherwise be. This
> directly benefits the global Internet in a way that a
> batteries-included-but-less-impactful approach could not, even assuming
> that such an approach exists (are you aware of one?).
> 
> Do you really mean "or", or do you actually mean "and"? We are talking about
> an initiative that, if successful, will materially benefit the global
> Internet, even though you personally will not be able wield the resulting
> tool for some time, or possibly even ever (unlikely, but possible). Do you
> support it anyway?
> 
> (A less charitable interpretation is that your concern is merely resentment
> or envy of large organisations. Presumably this is not correct.)

No.  Not at all.  I do mean 'or'.  I quite routinely invest time in things to 
make the Internet work better that don't personally benefit me.  Obviously the 
greater the personal and systemic benefit the greater my motivation, but I 
certainly have and do work on things that don't help me in any way 
proportionate to the time I invest in it. 

Along with the good things you (quite reasonably) describe, there will also be 
an increased tendency towards concentration of power in a few hands.  
Personally, I think that's a bad thing.  Your previous message in this thread 
captured my concern very nicely.

Thanks,

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

The difference in this case is one, maintaining a Wordpress site, requires a 
lot of vigilance, but no information/data that's not publicly available.  To 
the extent ARC is useful to mitigate the DMARC mailing list issue, it's only 
useful with additional data inputs that are not public and are not feasible 
for small providers to generate on their own.

It's the difference between can, but often shouldn't and can't.

I'll stop here though, the horse was probably dead a few mails ago.

Scott K

On Monday, February 15, 2016 02:11:57 PM Al Iverson via dmarc-discuss wrote:
> Scott, I don't really see any difference in the class of problem. You could
> choose to outsource email it to Google Apps or Microsoft Office 365 if you
> don't want to figure this stuff out yourself. Many do, from SMB to
> enterprise level, even though email is core to just about every company's
> business. For some, that's very much the reason to job it out to a company
> who focuses on email as an area of expertise.
> 
> On the flip side, I disagree with regard to your take on running a blog.
> Anybody can do it, but many people outsource that as well. I personally
> host my blog with a third party service, because self-hosted Wordpress is
> one of the most hacked into things out there and I want no part of that
> noise, even though in theory I could handle it. I know I'm not the only
> one, and just about anything in this paragraph could similarly apply to
> email.
> 
> Regards,
> Al Iverson
> 
> 
> --
> Al Iverson - Minneapolis - (312) 275-0130
> Simple DNS Tools since 2008: xnnd.com
> www.spamresource.com & aliverson.com
> 
> On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > ARC purpose is to say when DMARC fail and the email should be rejected
> > that it is ok to let it through. As such there is no scale problem and
> > anyone can do it.
> > 
> > If email is your core business, then complaining you have to do some work,
> > will not give any sympathy.
> > 
> > On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> > 
> > dmarc-discuss@dmarc.org> wrote:
> >> That's a totally different class of problem.  Any competent sysadmin with
> >> some
> >> time can maintain a CMS based web site (e.g. Wordpress).  The fact that
> >> so
> >> many are not competently managed is a function of capability and
> >> willingness
> >> to do a little work, not a function of inadequate scale.
> >> 
> >> Also, following that example, I choose to blog on wordpress.com,
> >> specifically
> >> so I don't have to worry about such things, but the blog isn't a core
> >> business
> >> function, so that's fine.  Email is more important, so I care more how
> >> and
> >> where it gets done.
> >> 
> >> Scott K
> >> 
> >> On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss
> >> 
> >> wrote:
> >> > Yes it is a "you have to be this tall to ride with us". For instance,
> >> 
> >> many
> >> 
> >> > Wordpress sites are on URL blocking lists, because the managers cannot
> >> 
> >> keep
> >> 
> >> > with basic security updates. So if you want to host a website, you have
> >> 
> >> to
> >> 
> >> > be that tall to ride with us (or find a hosting company, that will give
> >> 
> >> you
> >> 
> >> > a child seat)
> >> > 
> >> > The mail ecosystem is going this way too. The tools are opensource,
> >> > available to all, but you need to deploy them and maintain them.
> >> > 
> >> > The spat of serious data breaches because of email, is making all of us
> >> > very nervous that kids can create so much havoc so easily...
> >> > 
> >> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> >> > 
> >> > dmarc-discuss@dmarc.org> wrote:
> >> > > Scott Kitterman wrote:
> >> > > > It would be nice if we didn't design standards that only worked at
> >> > > > a
> >> > > 
> >> > > certain
> >> > > 
> >> > > > scale.  "You must be this tall to ride" worries me.
> >> > > 
> >> > > There's nothing about ARC that is scale-specific, except for the
> >> 
> >> obvious
> >> 
> >> > > observation that there's a batteries-not-included problem, so the
&g

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

That's a totally different class of problem.  Any competent sysadmin with some 
time can maintain a CMS based web site (e.g. Wordpress).  The fact that so 
many are not competently managed is a function of capability and willingness 
to do a little work, not a function of inadequate scale.

Also, following that example, I choose to blog on wordpress.com, specifically 
so I don't have to worry about such things, but the blog isn't a core business 
function, so that's fine.  Email is more important, so I care more how and 
where it gets done.

Scott K

On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss 
wrote:
> Yes it is a "you have to be this tall to ride with us". For instance, many
> Wordpress sites are on URL blocking lists, because the managers cannot keep
> with basic security updates. So if you want to host a website, you have to
> be that tall to ride with us (or find a hosting company, that will give you
> a child seat)
> 
> The mail ecosystem is going this way too. The tools are opensource,
> available to all, but you need to deploy them and maintain them.
> 
> The spat of serious data breaches because of email, is making all of us
> very nervous that kids can create so much havoc so easily...
> 
> On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > Scott Kitterman wrote:
> > > It would be nice if we didn't design standards that only worked at a
> > 
> > certain
> > 
> > > scale.  "You must be this tall to ride" worries me.
> > 
> > There's nothing about ARC that is scale-specific, except for the obvious
> > observation that there's a batteries-not-included problem, so the analysis
> > work required to make good use of it as a receiver is likely to be
> > infeasible for smaller receivers meaning that:
> > 
> > - initially only larger receivers will do it, and
> > - if it works then, over time, vendors/developers will embed slow-moving
> > pieces in products and/or reputation data providers will add faster moving
> > pieces to their services.
> > 
> > This is just a diffusion process, not an exclusion of smaller players.
> > Indeed, it would almost appear that you'd be happier if the big guys had
> > excluded smaller players from this initiative...
> > 
> > I'd also point out that we spent most of a decade (2003 - 2011) wandering
> > in a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> > most-heavily-phished organisation working directly with one of the big
> > guys
> > in private to get any purchase on the problem, and their subsequent
> > sharing
> > of it (DMARC) to bring about progress more broadly. It would appear that
> > ARC is on a similar path to improving the situation for largest unresolved
> > piece of the problem (supporting forwarding). This does suggest a general
> > difficulty in using a consensus-driven process to devise solutions, rather
> > than merely refine/standardise/evolve them, however this does not seem
> > like
> > a reason for concern, it may simply indicate that we've gotten as far as
> > we
> > can get at present with such processes. The important test when deciding
> > whether to cooperate would appear to be whether the particular solution
> > unduly benefits the big guys compared to other viable solutions that are
> > already known about. !
> > 
> >  If there are none, then cooperating on ARC would appear to be a
> > 
> > no-brainer.
> > 
> > > Solving the mailing list 'problem' in a way that requires me to switch
> > > to
> > > gmail (or some other large scale provider) to get my list mail delivered
> > 
> > is
> > 
> > > worse than no solution at all for me.
> > 
> > Obviously. This is not being proposed, see the comments about about
> > vendors/developers and reputation data providers.
> > 
> > - Roland
> > ___
> > dmarc-discuss mailing list
> > dmarc-discuss@dmarc.org
> > http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> > 
> > NOTE: Participating in this list means you agree to the DMARC Note Well
> > terms (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Monday, February 15, 2016 07:27:21 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> > It would be nice if we didn't design standards that only worked at a
> > certain scale.  "You must be this tall to ride" worries me.
> 
> There's nothing about ARC that is scale-specific, except for the obvious
> observation that there's a batteries-not-included problem, so the analysis
> work required to make good use of it as a receiver is likely to be
> infeasible for smaller receivers meaning that:

Yes.  Exactly it.

> - initially only larger receivers will do it, and
> - if it works then, over time, vendors/developers will embed slow-moving
> pieces in products and/or reputation data providers will add faster moving
> pieces to their services.
> 
> This is just a diffusion process, not an exclusion of smaller players.
> Indeed, it would almost appear that you'd be happier if the big guys had
> excluded smaller players from this initiative...

Until maybe someday the results of the analysis to use ARC are somehow 
available, they have.  The use of an open standard (which I am in favor of and 
this is good), doesn't materially change that.  If I can write code to 
implement a standard, but don't have the necessary inputs to use it, it's not 
particularly of use.

> I'd also point out that we spent most of a decade (2003 - 2011) wandering in
> a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> most-heavily-phished organisation working directly with one of the big guys
> in private to get any purchase on the problem, and their subsequent sharing
> of it (DMARC) to bring about progress more broadly. It would appear that
> ARC is on a similar path to improving the situation for largest unresolved
> piece of the problem (supporting forwarding). This does suggest a general
> difficulty in using a consensus-driven process to devise solutions, rather
> than merely refine/standardise/evolve them, however this does not seem like
> a reason for concern, it may simply indicate that we've gotten as far as we
> can get at present with such processes. The important test when deciding
> whether to cooperate would appear to be whether the particular solution
> unduly benefits the big guys compared to other viable solutions that are
> already known about. ! If there are none, then cooperating on ARC would
> appear to be a no-brainer.

Personally, I try to consider putting my time where either I'll benefit or I 
think the global Internet will benefit.  

> > Solving the mailing list 'problem' in a way that requires me to switch to
> > gmail (or some other large scale provider) to get my list mail delivered
> > is worse than no solution at all for me.
> 
> Obviously. This is not being proposed, see the comments about about
> vendors/developers and reputation data providers.

It's not being proposed, but I expect it'll be the effect.  

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Friday, February 12, 2016 05:11:34 AM Roland Turner via dmarc-discuss 
wrote:
> John Levine wrote:
> >>> So I hear what you're saying, but it doesn't change my mind.  I guess if
> >>> the large providers think this is useful, then meh, OK,
> >> 
> >> That would be the guys who receive more than half of the world's email? I
> >> would rank that slightly above "meh", but sure, for small guys it's not
> >> yet obvious what value ARC provides. I'd suggest a wait-and-see
> >> approach.
> > 
> > Yes, exactly.  Pretty much the entire value of ARC is the strong hint
> > that the gorillas plan to implement it as a workaround to DMARC issues.
> 
> I am perhaps imaging things, but my recollection is that there is not merely
> a hint that ARC is being devised and implemented for this purpose, but that
> this was the openly stated rationale.

It would be nice if we didn't design standards that only worked at a certain 
scale.  "You must be this tall to ride" worries me.  

Solving the mailing list 'problem' in a way that requires me to switch to 
gmail (or some other large scale provider) to get my list mail delivered is 
worse than no solution at all for me.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Wednesday, February 10, 2016 07:17:31 AM Roland Turner via dmarc-discuss 
wrote:
> Scott,
> 
> You're [still!] confusing multiple conceptions of trust, including at least:
> 
> 1) trust in the intention and ability of multiple upstream forwarders to
> ARC-sign correctly, 
> 2) trust in the lack of intention to abuse by the
> organisation at the other end of the SMTP connection, and 
> 3) trust in the
> intention and ability of the organisation at the other end of the SMTP
> connection to make exactly the same decision about disposition of a
> particular message (in fact: of all messages) as you would.
> 
> Implicit in (3) are two additional assumptions that may or may not be true:
> a) that the organisation at the other end of the SMTP connection has exactly
> one level of confidence in message disposition (this is patently not true;
> larger senders/forwarders routinely maintain discernibly separate pools in
> order to help receivers make better choices), and 
> b) that you have exactly
> one level of confidence in message disposition (this may well be true of
> you personally as it is of me, but it certainly isn't for larger
> forwarders).
> 
> For larger receivers, the ability to see upstream (only possible when they
> trust at least one of the upstream intermediaries to ARC sign correctly)
> allows better decision-making (e.g. about DMARC overrides) than does your
> apparent "the organisation at the other end of the SMTP connection is
> good/bad" dichotomy. Note in particular that the ability to test ARC
> signatures from forwarders upstream of the organisation at the other end of
> the SMTP connection allows for DMARC overrides to happen, specifically, in
> the situation where the receiver doesn't trust the organisation at the
> other end of the SMTP connection. Adding ARC makes this possible more
> frequently than DMARC+SPF+DKIM does.

I see your point, but I'm still not sure what it buys you.  Without your #2, 
#1 is irrelevant, and #3 is, given #2, not a big deal I don't think.  As for 
a) and b), while that's certainly true (that large senders have different 
levels of quality messages sent from different pools), that's trivially 
discernible from IP reputation data if you have a large volume of it.

So I hear what you're saying, but it doesn't change my mind.  I guess if the 
large providers think this is useful, then meh, OK, but I think it's pretty 
clearly not for anyone else and I am a little surprised they don't have 
equally good ways to solve the problem already deployed.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

To start with, you'll have to explain why receivers should trust a sender to 
not lie about where they got the mail from in an ARC header field if they don't 
already trust the sender.

Scott K

On Sunday, February 07, 2016 11:14:12 AM Franck Martin via dmarc-discuss 
wrote:
> ARC will help, but there are many mailing lists that don't have DKIM or
> even SPF. So even if ARC is available tomorrow, it may take years before
> mailing lists adopt any solution. So someone will have to make a stand, to
> get operators to deploy something.
> 
> On Sun, Feb 7, 2016 at 10:10 AM, Al Iverson via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > The mailing list question can be a bit tricky. Yeah, the DKIM
> > signature is supposed to transport just fine, unless your MLM rewrites
> > any header or content that breaks the signature. And when you deal
> > with that, eventually you're going to run into list subscribers whose
> > posts get rejected by some other subscribers, due to the poster's
> > domain having a P=reject DMARC policy.
> > 
> > I would say there's not a clear consensus on how best to handle
> > mailing lists in a DKIM+DMARC world. A bunch of email folks are
> > working on a standard called Authenticated Received Chain (ARC) that
> > would in theory help to address issues with mailing lists. (See
> > http://arc-spec.org/ ). But, we're a ways from being able to call that
> > a solution.
> > 
> > I'm a mailing list operator myself, at probably about the same level
> > you are. (Instead of Mailman, I run a custom MLM that I wrote myself,
> > mostly as a programming exercise.) What I have chosen to do is strip
> > an existing DKIM signature, rewrite the from address if it appears to
> > be a domain that has a restrictive DMARC policy, and then sign it with
> > DKIM as the list domain. This works well for me, but not everybody
> > agrees that it's the best path. I'm not the only one to have done
> > something similar; Yahoo Groups, Google Groups Mail-list.com and
> > OnlineGroups.net all send as the group instead of as the poster either
> > all the time or as needed; and mailman can be configured similarly.
> > 
> > Here's a link to an overview of the various issues in play for mailing
> > lists, and info on what I and others have chosen to do to address it.
> > http://www.spamresource.com/2015/02/dmarc-mailing-lists-roundup.html
> > 
> > Here's where to go to learn more about what you can do with Mailman:
> > http://wiki.list.org/DEV/DMARC
> > 
> > Note: There will probably be at least one really angry reply to this
> > post telling me how horrible this is and that I broke mailing lists.
> > It'll be a rehash of an argument from more than a year ago. Truth be
> > told, somebody else broke mailing lists; this is just how I personally
> > decided to implement a fix that seems to work well for me. YMMV.
> > 
> > Regards,
> > Al Iverson
> > 
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> > ___
> > dmarc-discuss mailing list
> > dmarc-discuss@dmarc.org
> > http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> > 
> > NOTE: Participating in this list means you agree to the DMARC Note Well
> > terms (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Sunday, February 07, 2016 08:25:13 PM John Levine wrote:
> In article <2049568.4HsipfqAXp@kitterma-e6430> you write:
> >To start with, you'll have to explain why receivers should trust a sender
> >to not lie about where they got the mail from in an ARC header field if
> >they don't already trust the sender.
> 
> If you're suggesting that ARC is only useful when you already trust
> the forwarding party, and if you trust the forwarding party, why do
> you need ARC, yeah, that's been pointed out before.
> 
> The best explanation I've seen was from someone at Google who said
> that they often see well behaved lists suddenly start to send spam
> when a spambot happens to send mail that fakes a subscriber's return
> address.  ARC would make it somewhat easier to tell when that happens.

OK.  Specifically in a DMARC context (this being the DMARC list), I don't see 
that it's particularly related to DMARC and solving the DMARC mailing list 
problem.  For the reasons you correctly state have been gone over before.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] A bit quiet?

[Scott Kitterman via dmarc-discuss]

On October 26, 2015 9:12:17 AM EDT, Roland Turner via dmarc-discuss 
 wrote:
>Scott Kitterman wrote:
...
snipped down to one bit as we seem to mostly be going around in circles
...
>> As a domain owner, I can control what sources of mail are able to
>> generate mail that passes SPF or has a valid DKIM signature with d=
>my
>> domain.  Anyone, anywhere can generate an ARC stamp with my domain in
>it,
>> so it's completely different.
>
>No, they can't.
>
>(More accurately, like a DKIM signature, anyone can create one, but it
>won't validate unless they've also gotten their hands on one of your
>private keys.)

Who adds the ARC stamp? Perhaps I read it wrong, but I read it as being added 
by the intermediary and not the originator (previous hop).

If I read it right, anyone can create an ARC stamp claiming to have received 
authenticate (e.g. DKIM signed) mail from my domain.  Am I reading it wrong?

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] A bit quiet?

[Scott Kitterman via dmarc-discuss]

On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss wrote:
> Scott Kitterman wrote:
> > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss 
 wrote:
> >>The question is not who you trust - ARC doesn't directly change that -
> >>but how you reliably automate determining whether the message was
> >>forwarded only by people that you trust. At present, you have to dig
> >>through Received: headers, infer per-forwarder internal structure and
> >>behaviour and, frequently, guess. ARC addresses that problem, not the
> >>one you're asking about.
> >>
> > I don't see why the signing domain of the DKIM signature that could be
> > added by the most recent sender doesn't already give an identifier  to use
> > to evaluate trust in the sender.
> 
> It does, but that only allows you to identify - and apply your trust
> assessment to - the most recent sender. ARC provides a means to
> automatically assess the chain *upstream* of the most recent sender.

Only if you already have a high degree of trust in the most recent sender.

> It might be worth pointing out that trust is this context is not absolute,
> and should not be transitive, because:
> 
> - trusting the integrity (good intention) of the forwarder is not the same
> as trusting the competence of the forwarder, and
> 
> - there are different competences that you may or may not be willing to
> trust (ability of a forwarder to ARC/DKIM sign correctly and maintain
> secrecy of keys is a *far* lower bar than ability of a forwarder to make
> exactly the same decisions about what abuse to exclude as those that you as
> receiver would make, particularly when you make local, secret decisions as
> part of doing so; this distinction gets increasingly acute as receivers get
> larger).

Since the most recent sender can claim in an ARC stamp whatever arbitrary 
upstream senders they care to, it seems to me that placing any value at all on 
an ARC stamp from anything other than a highly trusted sender opens an abuse 
vector.

> > I can see that ARC gives a way to communicate information about
> > the upstream senders, but I don't see how that's related to DMARC.
> 
> Many receivers implementing DMARC wish to be able to make decisions about
> when to ignore p=reject on a more fine-grained basis than all-or-nothing
> trust of the most recent sender. ARC is built to facilitate this and,
> therefore, is directly relevant to DMARC.

It would already require a high level of trust in the most recent sender not 
to engage in ARC stamp forgery to do this.  Since DMARC is about 
authentication of an identity (5322.From), if you trust the most recent sender 
not to have forged the ARC stamp, I'm still not seeing the value of them 
adding the stamp.

> > From a DMARC perspective, if you know the sender is trustworthy, you do a
> > local override.  ARC doesn't seem to be needed for that.
> 
> You keep talking about "the sender" as if there were only one. In your
> message to which I am replying, there are 7 Received: headers in various
> formats from 3, 4 or 5 ADMDs, interspersed with various information about
> authentication assessments. This is tough for me to assess as a human with
> considerable expertise in this area. For software to do it reliably would
> be both difficult and fragile. If you don't get why being able to perform
> this assessment automatically and reliably is valuable then ARC is never
> going to make sense to you, no matter how many detail questions you ask.
> I'd suggest that this may simply mean that ARC is not relevant to you and
> that, therefore, it may be the case that you can safely ignore it while
> those for whom the problem is relevant move forward to run the experiment.

When I'm receiving a message, I'm receiving it from a single sender.  The 
message may have a history before that, but from my perspective, it's only got 
one at the moment.

I've never said ARC doesn't have value.  I've said I didn't see the value for 
solving the the issue that DMARC has with mailing lists that perform 
transformations that break DKIM signatures (like this one).   This is the 
DMARC list, not the ARC list.

I'm trying to understand why people seem to be claiming ARC is somehow helpful 
to DMARC.  I don't dispute it may be independently useful, but those uses 
would be off topic here.

> >>The amount of discussion to date about specific historical whitelist
> >>proposals is neither here nor there. The question is whether ARC's
> >>degree of support for reliable automatic chain-of-custody assessment
> >>provides a material improvement for a group of receivers interoperating
> >>with a group of forwarders. So long as the answer to that question is
> >>yes, then this is progress. I'd suggest that:
> >>
> >>*   large receivers are generally keen to implement things that
> >>materially improve their ability to separate wheat from chaff (ARC does
> >>this if it's implemented by any significant subset of mailing-list
> 

Re: [dmarc-discuss] A bit quiet?

[Scott Kitterman via dmarc-discuss]

On October 23, 2015 2:10:26 PM EDT, "J. Gomez via dmarc-discuss" 
<dmarc-discuss@dmarc.org> wrote:
>On Friday, October 23, 2015 4:07 PM, Scott Kitterman via dmarc-discuss
>wrote:
>
>> On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss
>> <dmarc-discuss@dmarc.org> wrote: 
>> > The question is not who you trust - ARC doesn't directly change
>> > that - but how you reliably automate determining whether the
>> > message was forwarded only by people that you trust. At present,
>> > you have to dig through Received: headers, infer per-forwarder
>> > internal structure and behaviour and, frequently, guess. ARC
>> > addresses that problem, not the one you're asking about.
>> 
>> I don't see why the signing domain of the DKIM signature that could
>> be added by the most recent sender doesn't already give an identifier
>> to use to evaluate trust in the sender.  
>> 
>> I can see that ARC gives a way to communicate information about the
>> upstream senders, but I don't see how that's related to DMARC. 
>> 
>> From a DMARC perspective, if you know the sender is trustworthy, you
>> do a local override.  ARC doesn't seem to be needed for that.
>
>How do you know the sender is trustworthy, if the email he sends 
>is failing a DMARC check?
>
>Is this ARC thing a mechanism to know when it is safe to ignore 
>the sender's DMARC policy of "p=reject"? And if it is such, shouldn't 
>it be part of the DMARC standard?

It's not. It's only useful when provided by senders you trust.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] A bit quiet?

[Scott Kitterman via dmarc-discuss]

On October 22, 2015 1:19:51 PM EDT, Franck Martin via dmarc-discuss 
 wrote:
>The fun is moving to ARC
>
>https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
>

How does that actually help? At least as I read the draft, anyone can make up a 
'bad' message and an associated made up DKIM signature and then add their ARC 
stamp claiming the signature was valid when the message arrived?

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] A bit quiet?

[Scott Kitterman via dmarc-discuss]

Okay. If I implement ARC as a receiver, then I ignore p=reject from Senders I 
trust not to lie to me if it passes ARC?

Scott K

On October 22, 2015 10:15:24 PM EDT, Roland Turner via dmarc-discuss 
<dmarc-discuss@dmarc.org> wrote:
>ARC provides a standardised, software-implementable, means for
>trustworthy forwarders to implement chain-of-custody records and
>therefore for receivers to reliably and simply automate assessments
>about messages received through trustworthy paths that are currently
>both generally too complicated to make other than by hand and - for
>longer forwarding chains than author->list->recipient - depend upon
>trusting untrustworthy data from several hops upstream.
>
>The decisions about who to trust remain more-or-less those which
>receivers already make, ARC extends the distance that that trust can be
>algorithmically extended. An untrusted bad guy gains nothing, except
>against a naive receiver who imagines that ARC is magic. See also naive
>receivers assuming that SPF passing meant that a message was not spam.
>Likewise DKIM passing. Likewise DMARC passing. The important change
>here is that, in addition to incorporating an assessment of the
>trustworthiness of the author and/or the last hop, assessments of the
>trustworthiness of forwarders enter the picture.
>
>- Roland
>
>
>Roland Turner | Labs Director
>Singapore | M: +65 96700022
>roland.tur...@trustsphere.com
>
>
>
>____________
>From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of
>Scott Kitterman via dmarc-discuss <dmarc-discuss@dmarc.org>
>Sent: Friday, 23 October 2015 04:44
>To: dmarc-discuss@dmarc.org
>Subject: Re: [dmarc-discuss] A bit quiet?
>
>On October 22, 2015 1:19:51 PM EDT, Franck Martin via dmarc-discuss
><dmarc-discuss@dmarc.org> wrote:
>>The fun is moving to ARC
>>
>>https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
>>
>
>How does that actually help? At least as I read the draft, anyone can
>make up a 'bad' message and an associated made up DKIM signature and
>then add their ARC stamp claiming the signature was valid when the
>message arrived?
>
>Scott K
>
>___
>dmarc-discuss mailing list
>dmarc-discuss@dmarc.org
>http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
>NOTE: Participating in this list means you agree to the DMARC Note Well
>terms (http://www.dmarc.org/note_well.html)
>
>___
>dmarc-discuss mailing list
>dmarc-discuss@dmarc.org
>http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
>NOTE: Participating in this list means you agree to the DMARC Note Well
>terms (http://www.dmarc.org/note_well.html)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] what is SPF-DNS?

[Scott Kitterman via dmarc-discuss]

On Wednesday, June 24, 2015 11:17:38 AM Tomki Camp via dmarc-discuss wrote:
 in 7.3.1 there is a required entry ‘SPF-DNS’, for which I can’t find any
 definition reference.
 
 https://datatracker.ietf.org/doc/rfc7489/?include_text=1

It's defined in RFC 6591, Section 3.2.6.

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] mail.ru DMARC processing issue

[Scott Kitterman via dmarc-discuss]

I've been reviewing some DMARC failures reported in data from mail.ru.  

In this case the From domain is a subdomain of the main company domain (e.g. 
sub.example.com), the DKIM signature is d= the main company domain (e.g. 
example.com), and the DMARC record is the org domain record as well (e.g. 
_dmarc.example.com).  The feedback is that the raw DKIM signature is valid, 
but not aligned.  Reports from other providers, e.g. Google, use the signature 
for DMARC pass.

It seems like perhaps mail.ru is looking for strict DKIM identity alignment 
even though relaxed is the default (and the DMARC record in question doesn't 
specify adkim).

Does anyone have a contact there that they can raise the issue?

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] Issues with Google Authentication Results header fields

[Scott Kitterman via dmarc-discuss]

While not directly DMARC, AR fields can serve as an input for DMARC processing, 
so I think it's generally worth getting right.

I was checking a recent SPF change relevant to one of my serves, so I found 
myself looking at this:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of sc...@kitterman.com designates 
2607:f0d0:3001:aa::2 as permitted sender) smtp.mail=sc...@kitterman.com;
   dkim=pass header.i=@kitterman.com;
   dmarc=pass (p=NONE dis=NONE) header.from=kitterman.com

The major gripe I have with this is that the correct ptype for SPF reports is 
mailfrom, not mail.  See 
http://www.iana.org/assignments/email-auth/email-auth.xhtml

Also, the local part should be removed as was done for DKIM.

If there's someone from Google on the list, I'd appreciate it if you could 
have a look at this or pass it on to someone who can.  If the ptype is wrong, 
it's going to make the field harder to consume reliably.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Postfix 2.11.2 test

[Scott Kitterman via dmarc-discuss]

On October 16, 2014 9:20:07 PM EDT, Benny Pedersen via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:
Just to test how bad it is now, is there more errors now that postfix 
milter is resolved ?

I have still problem with opendkim when rebooting after running a day,
if i 
just reboot after 10 mins opendkim does not fail to stop, but it fails
if 
runned long time

Am i the only one see this problem with opendkim, funny it does not
happend 
with opendmarc ever here

This would probably be better discussed on an opendkim list, since it's not a 
DMARC issue. 

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] Yahoo! DKIM Signing Practices Produce Fragile Signatures

[Scott Kitterman via dmarc-discuss]

With obvious implications for DMARC failures.  See the postfix-users thread 
that starts here:

http://archives.neohapsis.com/archives/postfix/2014-10/0138.html

It would be helpful if Yahoo! were to dial this back a bit and stick with the 
recommended fields to sign (i.e. drop Received and Content-Length).  Signing 
those fields inevitably makes the signatures more fragile.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Yahoo! DKIM Signing Practices Produce Fragile Signatures

[Scott Kitterman via dmarc-discuss]

Postfix removes it.

Scott K

On Monday, October 06, 2014 18:32:43 Murray Kucherawy via dmarc-discuss wrote:
 I get Received:, but why would Content-Length change in-flight?
 
 -MSK
 
 On 10/6/14, 11:01 AM, Scott Kitterman via dmarc-discuss
 
 dmarc-discuss@dmarc.org wrote:
 With obvious implications for DMARC failures.  See the postfix-users
 thread
 that starts here:
 
 https://urldefense.proofpoint.com/v1/url?u=http://archives.neohapsis.com/a
 rchives/postfix/2014-10/0138.htmlk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=aZ0x
 RzXh0AB20HBCmRph%2Bg%3D%3D%0Am=lfSYBVH5FDF6rosyLcdxRtbHZp5ZSdRNYpI%2FRX5G
 Km4%3D%0As=4200de29230600b9387daa6a9396f6c078fbb8a0011afc5ff99f437e767fab
 f8
 
 It would be helpful if Yahoo! were to dial this back a bit and stick with
 the
 recommended fields to sign (i.e. drop Received and Content-Length).
 Signing
 those fields inevitably makes the signatures more fragile.
 
 Scott K
 ___
 dmarc-discuss mailing list
 dmarc-discuss@dmarc.org
 https://urldefense.proofpoint.com/v1/url?u=http://www.dmarc.org/mailman/li
 stinfo/dmarc-discussk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=aZ0xRzXh0AB20HBCm
 Rph%2Bg%3D%3D%0Am=lfSYBVH5FDF6rosyLcdxRtbHZp5ZSdRNYpI%2FRX5GKm4%3D%0As=b
 088a07c4fdc10672e30bf29d947b642af222cb0345354759deb4bc760cc36f1
 
 NOTE: Participating in this list means you agree to the DMARC Note Well
 terms
 (https://urldefense.proofpoint.com/v1/url?u=http://www.dmarc.org/note_well
 .htmlk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=aZ0xRzXh0AB20HBCmRph%2Bg%3D%3D%0
 Am=lfSYBVH5FDF6rosyLcdxRtbHZp5ZSdRNYpI%2FRX5GKm4%3D%0As=4b0dcd065be5e034
 bb0d6fcf9943fd5db1904b0adf73313b58891bb54979af11)
 
 ___
 dmarc-discuss mailing list
 dmarc-discuss@dmarc.org
 http://www.dmarc.org/mailman/listinfo/dmarc-discuss
 
 NOTE: Participating in this list means you agree to the DMARC Note Well
 terms (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Fwd: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue

[Scott Kitterman via dmarc-discuss]

On September 1, 2014 12:50:04 PM EDT, John Levine jo...@taugh.com wrote:
 I don't understand what fo=1 is supposed to mean. ..

 The ambiguity for me is between SPF or DKIM failed and no SPF or
DKIM
 at all.  As I read it, it probably means failure, but maybe it means
 something else.

I think for DMARC, SPF/DKIM failed/none are the same thing.

For DMARC pass/fail, sure.  For DMARC reporting, I dunno.

Practically speaking, I would not find reports confirming that I had
no SPF at all very interesting.  Remember that this is for messages
that passed DMARC anyway, so they must have had signatures.  Ditto if
they say there was no signature, but the SPF was OK.

I agree most wouldn't find it interesting, but fo 0 is the default. 

If there is supposed to be a none/fail distinction for fo 1, then I think it 
needs to be explicitly called out. 

Scott K


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Fwd: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue

[Scott Kitterman via dmarc-discuss]

On August 30, 2014 7:26:19 PM EDT, John Levine jo...@taugh.com wrote:
Does anyone who's implemented fo have a problem with both 0 and
1
being specified?  If it is somehow problematic, then the base spec
ought
to say so.

I don't understand what fo=1 is supposed to mean.  If there's no SPF
record at all, are you supposed to generate a report?  If there's no
DKIM signature at all, same question?  Of if there are DKIM signatures,
but none of them have a d= that matches the From: address?

My reading of the draft says yes to all three. 

Scott K


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] AOL MX server don't support 8BITMIME

[Scott Kitterman via dmarc-discuss]

I'd like to highlight this as an example of what I think is a great value in 
this list.  The ability of operators to have an open dialog about their mail 
operations and how it impacts interoperability is a wonderful thing.  I wish 
there was more of it.

Scott K

On Wednesday, August 06, 2014 17:58:50 Rock, Paul via dmarc-discuss wrote:
 So I checked, we do support it, we just don't announce it as part of the
 ehlo response, which of course means that no one knows we support it. I
 know we had some legacy reasons for disabling 8BITMIME and a few other
 things in our ehlo response, but I'll ask to see if we can turn them back
 on.
 
 PAUL ROCK
 Senior Programmer/Analyst | AOL Mail
 P: 703-265-5734 | C: 703-980-8380
 AIM: paulsrock
 44900 Prentice Dr. | Dulles, VA | 20166-9305
 
 On Aug 6, 2014, at 10:21 AM, A. Schulze via dmarc-discuss dmarc-
disc...@dmarc.org wrote:
  Hello,
  
  yesterday I noted that a testmessage to an aol.de account was delivered to
  the spam-folder @AOL. I guess dkim=fail for that message was the reason.
  
  Some testmessages later i found AOL does not announce the 8BITMIME smtp
  extension. My outbound mta has to recode the content and break the
  already existing signature.
  
  * is there a reason AOL does not support 8BITMIME?
  
   RFC1426 is 20 years old and updated by RFC6152 in 2011
  
  How do other handle that situation?
  Do that recoding also break some opaque S/MIME signatures?
  
  I'm confused...
  
  Andreas
  
  ___
  dmarc-discuss mailing list
  dmarc-discuss@dmarc.org
  http://www.dmarc.org/mailman/listinfo/dmarc-discuss
  
  NOTE: Participating in this list means you agree to the DMARC Note Well
  terms (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Unauthenticated emails being delivered to Google

[Scott Kitterman via dmarc-discuss]

On Friday, August 01, 2014 08:09:53 Anders Wegge Keller via dmarc-discuss 
wrote:
 On Thu, 31 Jul 2014 22:31:36 +
 
 Norman, Jean Marie via dmarc-discuss dmarc-discuss@dmarc.org wrote:
  Has anyone experienced unauthenticated emails being delivered to Google
  recipients despite having a DMARC policy (quarantine or reject) in place?
  We have seen evidence that unauthenticated emails (not passing both SPF
  and DKIM) are being delivered to Google, despite a DMARC policy, when
  messages pass through a 'forwarder', as noted by Google. We are trying to
  better understand this behavior and whether or not anyone has found a
  solution? Any insight or recommendations would be appreciated.
 
  As soon as there is a Sender field in the header, it's the SPF and/or DKIM
 records for the domain in that header, that's used for verification. So in
 this case you need to work with the forwarder, and make them stop their
 practice.

No.  DMARC always keys off From.  Not Sender.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Unauthenticated emails being delivered to Google

[Scott Kitterman via dmarc-discuss]

On August 1, 2014 7:03:03 AM EDT, Anders Wegge Keller via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:
On Fri, 01 Aug 2014 06:40:29 -0400
Scott Kitterman via dmarc-discuss dmarc-discuss@dmarc.org wrote:

 On Friday, August 01, 2014 10:46:08 Anders Wegge Keller via
dmarc-discuss 
 wrote:

  Also, I fail to see how mailing lists could work otherwise, as they
 routinely change several of the signed header fields.
 
 They don't.  That's one of the major reasons why the IETF is
considering 
 kicking off a new DMARC related working group.

I can show you quite a lot of mailing lists, that do in fact add
[Listname]
to the subject field. When I post to a mailing list that add Sender and
sign
the mail with that DKIM-key, everything flows. On the other hand, if I
just
post to a mailing list that copies the message verbatim, I'm flooded
with
failure reports. So whatever you may think should happen, the reality
is
different. 

You read me backwards. They don't was short for they (mailing lists) don't 
generally work with DMARC. 

Scott K

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] MLM and Header-From rewritting - the SMTPopen-relay analogy

[Scott Kitterman via dmarc-discuss]

On Saturday, June 07, 2014 16:33:14 Dave Crocker via dmarc-discuss wrote:
...
 We need to find a way to get objective and comparable information about
 this.
...

If only DMARC had a mechanism for providing feedback so that people could 
measure this and provide data.  ;-)

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] MLM and Header-From rewritting - the SMTPopen-relay analogy

[Scott Kitterman via dmarc-discuss]

On Saturday, June 07, 2014 17:00:25 Dave Crocker wrote:
 On 6/7/2014 4:56 PM, Scott Kitterman via dmarc-discuss wrote:
  If only DMARC had a mechanism for providing feedback so that people
  could measure this and provide data.  ;-)
 
 I'm pretty sure it isn't my jet lag that's causing me to miss the rest
 of the details.  For the question just posed -- make lists harder to use
 for all users of lists -- how can DMARC reporting develop the necessary
 data?

Maybe I lost context, but I thought the claim that was being disputed and 
needed assessment was if p=reject was affecting the rate of phishing attempts.  
It would seem to me that for that question, a comparison of before/after 
p=reject data would yield some interesting information.

For that question, I agree and sorry for the noise.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] DMARC Successful Mail Delivery Reports

[Scott Kitterman via dmarc-discuss]

Over the last few days I've gotten a number of bounces like this, all from 
AOL:

Return-Path: 
Received: from imb-d04.mx.aol.com (imb-d04.mx.aol.com [205.188.128.65])
by qs3710.pair.com (Postfix) with ESMTPS id 51A76125427
for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
Received: from mtaig-mca02.mx.aol.com (mtaig-mca02.mx.aol.com [172.26.221.66])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by imb-d04.mx.aol.com (AOL Mail Bouncer) with ESMTPS id 12B0E38000AA
for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
Received: by mtaig-mca02.mx.aol.com (Internet Inbound)
id 040077087; Sun, 11 May 2014 13:05:39 -0400 (EDT)
Date: Sun, 11 May 2014 13:05:39 -0400 (EDT)
From: mailer-dae...@aol.com (Mail Delivery System)
Subject: Successful Mail Delivery Report
To: i...@kitterman.com
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=8C3437094.1399827939/mtaig-mca02.mx.aol.com
Message-Id: 20140511170539.040077...@mtaig-mca02.mx.aol.com

This is a MIME-encapsulated message.

--8C3437094.1399827939/mtaig-mca02.mx.aol.com
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

Please direct further questions regarding this message to your e-mail
administrator.

--AOL Postmaster


erica.bbr...@aim.com: alias expanded

--8C3437094.1399827939/mtaig-mca02.mx.aol.com
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; mtaig-mca02.mx.aol.com
X-Internet-Inbound-Queue-ID: 8C3437094
X-Internet-Inbound-Sender: rfc822; i...@kitterman.com
Arrival-Date: Sun, 11 May 2014 13:05:38 -0400 (EDT)

Final-Recipient: rfc822; erica.bbr...@aim.com
Original-Recipient: rfc822;erica.bbr...@aim.com
Action: expanded
Status: 2.0.0
Diagnostic-Code: X-Internet-Inbound; alias expanded

--8C3437094.1399827939/mtaig-mca02.mx.aol.com
Content-Description: Message Headers
Content-Type: text/rfc822-headers

Return-Path: i...@kitterman.com
Received: from are-financed-errors.oilbrooklyn.com (safety-good-
sparkprovo.oilbrooklyn.com [199.175.55.32])
by mtaig-mca02.mx.aol.com (Internet Inbound) with ESMTP id 8C3437094
for erica.bbr...@aim.com; Sun, 11 May 2014 13:05:38 -0400 (EDT)
Date: Sun, 11 May 2014 06:30:50 CDT
Mime-Version: 1.0
X-MSGID:1
Content-Type: text/html
From:  Loan Department. i...@kitterman.com
To: erica.bbr...@aim.com
Subject:  RE:Congratulations erica.bbrown $9500 Available For You!
x-aol-global-disposition: S
X-AOL-SCOLL-DMARC: mtaig-mca02.mx.aol.com ; domain : kitterman.com ; policy : 
none ; result : F
Authentication-Results: mx.aol.com;
spf=fail (aol.com: the domain kitterman.com reports that 199.175.55.32 
is 
explicitly not authorized to send mail using it's domain name.) 
smtp.mailfrom=kitterman.com;
dmarc=fail (aol.com: the domain kitterman.com reports that Neither SPF 
nor 
DKIM align.) header.from=kitterman.com;
X-AOL-REROUTE: YES
x-aol-sid: 3039ac1add42536fade22f5e
X-AOL-IP: 199.175.55.32
X-AOL-SPF: domain : kitterman.com SPF : fail

--8C3437094.1399827939/mtaig-mca02.mx.aol.com--

Dear AOL: please stop.  This is brain dead.  In case anyone is wondering, no 
one from i...@kitterman.com sent erica.bbrown any mail telling here we had 
$9500 available for her.

I don't know for sure if this is related to DMARC or not, but the timing seems 
to be roughly in line with their rollout of DMARC p=reject.

I have more if anyone wants to see them.

Scott K
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC Successful Mail Delivery Reports

[Scott Kitterman via dmarc-discuss]

No.  I care too much about actual mailing list traffic for that to be feasible. 
 
If this is happening due to DMARC, a better solution for my use case would be 
to remove my DMARC record.

Scott K

On Monday, May 12, 2014 03:01:00 Franck Martin wrote:
 Besides the backscatter AOL is creating and should stop, seems you should
 move your domain to p=reject to avoid that these spoofed emails get
 delivered to aol users and others...
 
 Printed on recycled paper!
 
  On May 11, 2014, at 19:34, Scott Kitterman via dmarc-discuss
  dmarc-discuss@dmarc.org wrote:
  
  Over the last few days I've gotten a number of bounces like this, all from
  AOL:
  
  Return-Path: 
  Received: from imb-d04.mx.aol.com (imb-d04.mx.aol.com [205.188.128.65])
  
 by qs3710.pair.com (Postfix) with ESMTPS id 51A76125427
 for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
  
  Received: from mtaig-mca02.mx.aol.com (mtaig-mca02.mx.aol.com
  [172.26.221.66]) 
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by imb-d04.mx.aol.com (AOL Mail Bouncer) with ESMTPS id 12B0E38000AA
 for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
  
  Received: by mtaig-mca02.mx.aol.com (Internet Inbound)
  
 id 040077087; Sun, 11 May 2014 13:05:39 -0400 (EDT)
  
  Date: Sun, 11 May 2014 13:05:39 -0400 (EDT)
  From: mailer-dae...@aol.com (Mail Delivery System)
  Subject: Successful Mail Delivery Report
  To: i...@kitterman.com
  Auto-Submitted: auto-replied
  MIME-Version: 1.0
  Content-Type: multipart/report; report-type=delivery-status;
  
 boundary=8C3437094.1399827939/mtaig-mca02.mx.aol.com
  
  Message-Id: 20140511170539.040077...@mtaig-mca02.mx.aol.com
  
  This is a MIME-encapsulated message.
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com
  Content-Description: Notification
  Content-Type: text/plain; charset=us-ascii
  
  Your message was successfully delivered to the destination(s)
  listed below. If the message was delivered to mailbox you will
  receive no further notifications. Otherwise you may still receive
  notifications of mail delivery errors from other systems.
  
  Please direct further questions regarding this message to your e-mail
  administrator.
  
  --AOL Postmaster
  
  
  erica.bbr...@aim.com: alias expanded
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com
  Content-Description: Delivery report
  Content-Type: message/delivery-status
  
  Reporting-MTA: dns; mtaig-mca02.mx.aol.com
  X-Internet-Inbound-Queue-ID: 8C3437094
  X-Internet-Inbound-Sender: rfc822; i...@kitterman.com
  Arrival-Date: Sun, 11 May 2014 13:05:38 -0400 (EDT)
  
  Final-Recipient: rfc822; erica.bbr...@aim.com
  Original-Recipient: rfc822;erica.bbr...@aim.com
  Action: expanded
  Status: 2.0.0
  Diagnostic-Code: X-Internet-Inbound; alias expanded
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com
  Content-Description: Message Headers
  Content-Type: text/rfc822-headers
  
  Return-Path: i...@kitterman.com
  Received: from are-financed-errors.oilbrooklyn.com (safety-good-
  sparkprovo.oilbrooklyn.com [199.175.55.32])
  
 by mtaig-mca02.mx.aol.com (Internet Inbound) with ESMTP id
 8C3437094
 for erica.bbr...@aim.com; Sun, 11 May 2014 13:05:38 -0400 (EDT)
  
  Date: Sun, 11 May 2014 06:30:50 CDT
  Mime-Version: 1.0
  X-MSGID:1
  Content-Type: text/html
  From:  Loan Department. i...@kitterman.com
  To: erica.bbr...@aim.com
  Subject:  RE:Congratulations erica.bbrown $9500 Available For You!
  x-aol-global-disposition: S
  X-AOL-SCOLL-DMARC: mtaig-mca02.mx.aol.com ; domain : kitterman.com ;
  policy : none ; result : F
  Authentication-Results: mx.aol.com;
  
 spf=fail (aol.com: the domain kitterman.com reports that 199.175.55.32
 is
  
  explicitly not authorized to send mail using it's domain name.)
  smtp.mailfrom=kitterman.com;
  
 dmarc=fail (aol.com: the domain kitterman.com reports that Neither SPF
 nor
  
  DKIM align.) header.from=kitterman.com;
  X-AOL-REROUTE: YES
  x-aol-sid: 3039ac1add42536fade22f5e
  X-AOL-IP: 199.175.55.32
  X-AOL-SPF: domain : kitterman.com SPF : fail
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com--
  
  Dear AOL: please stop.  This is brain dead.  In case anyone is wondering,
  no one from i...@kitterman.com sent erica.bbrown any mail telling here we
  had $9500 available for her.
  
  I don't know for sure if this is related to DMARC or not, but the timing
  seems to be roughly in line with their rollout of DMARC p=reject.
  
  I have more if anyone wants to see them.
  
  Scott K
  ___
  dmarc-discuss mailing list
  dmarc-discuss@dmarc.org
  http://www.dmarc.org/mailman/listinfo/dmarc-discuss
  
  NOTE: Participating in this list means you agree to the DMARC Note Well
  terms (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http

Re: [dmarc-discuss] DMARC Successful Mail Delivery Reports

[Scott Kitterman via dmarc-discuss]

Look at the ruf= address and where it was sent.  No.  Not what I requested.

Scott K

On Monday, May 12, 2014 11:07:59 you wrote:
 You have p=none and ruf= turned on, AOL's doing exactly what you've
 requested.
 
 - Roland
 
 On 05/12/2014 10:25 AM, Scott Kitterman via dmarc-discuss wrote:
  Over the last few days I've gotten a number of bounces like this, all from
  AOL:
  
  Return-Path: 
  Received: from imb-d04.mx.aol.com (imb-d04.mx.aol.com [205.188.128.65])
  
  by qs3710.pair.com (Postfix) with ESMTPS id 51A76125427
  for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
  
  Received: from mtaig-mca02.mx.aol.com (mtaig-mca02.mx.aol.com
  [172.26.221.66]) 
  (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
  (No client certificate requested)
  by imb-d04.mx.aol.com (AOL Mail Bouncer) with ESMTPS id 12B0E38000AA
  for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
  
  Received: by mtaig-mca02.mx.aol.com (Internet Inbound)
  
  id 040077087; Sun, 11 May 2014 13:05:39 -0400 (EDT)
  
  Date: Sun, 11 May 2014 13:05:39 -0400 (EDT)
  From: mailer-dae...@aol.com (Mail Delivery System)
  Subject: Successful Mail Delivery Report
  To: i...@kitterman.com
  Auto-Submitted: auto-replied
  MIME-Version: 1.0
  Content-Type: multipart/report; report-type=delivery-status;
  
  boundary=8C3437094.1399827939/mtaig-mca02.mx.aol.com
  
  Message-Id: 20140511170539.040077...@mtaig-mca02.mx.aol.com
  
  This is a MIME-encapsulated message.
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com
  Content-Description: Notification
  Content-Type: text/plain; charset=us-ascii
  
  Your message was successfully delivered to the destination(s)
  listed below. If the message was delivered to mailbox you will
  receive no further notifications. Otherwise you may still receive
  notifications of mail delivery errors from other systems.
  
  Please direct further questions regarding this message to your e-mail
  administrator.
  
  --AOL Postmaster
  
  
  erica.bbr...@aim.com: alias expanded
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com
  Content-Description: Delivery report
  Content-Type: message/delivery-status
  
  Reporting-MTA: dns; mtaig-mca02.mx.aol.com
  X-Internet-Inbound-Queue-ID: 8C3437094
  X-Internet-Inbound-Sender: rfc822; i...@kitterman.com
  Arrival-Date: Sun, 11 May 2014 13:05:38 -0400 (EDT)
  
  Final-Recipient: rfc822; erica.bbr...@aim.com
  Original-Recipient: rfc822;erica.bbr...@aim.com
  Action: expanded
  Status: 2.0.0
  Diagnostic-Code: X-Internet-Inbound; alias expanded
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com
  Content-Description: Message Headers
  Content-Type: text/rfc822-headers
  
  Return-Path: i...@kitterman.com
  Received: from are-financed-errors.oilbrooklyn.com (safety-good-
  sparkprovo.oilbrooklyn.com [199.175.55.32])
  
  by mtaig-mca02.mx.aol.com (Internet Inbound) with ESMTP id 8C3437094
  for erica.bbr...@aim.com; Sun, 11 May 2014 13:05:38 -0400 (EDT)
  
  Date: Sun, 11 May 2014 06:30:50 CDT
  Mime-Version: 1.0
  X-MSGID:1
  Content-Type: text/html
  From:  Loan Department. i...@kitterman.com
  To: erica.bbr...@aim.com
  Subject:  RE:Congratulations erica.bbrown $9500 Available For You!
  x-aol-global-disposition: S
  X-AOL-SCOLL-DMARC: mtaig-mca02.mx.aol.com ; domain : kitterman.com ;
  policy : none ; result : F
  Authentication-Results: mx.aol.com;
  
  spf=fail (aol.com: the domain kitterman.com reports that 199.175.55.32 
  is
  
  explicitly not authorized to send mail using it's domain name.)
  smtp.mailfrom=kitterman.com;
  
  dmarc=fail (aol.com: the domain kitterman.com reports that Neither SPF
  nor
  
  DKIM align.) header.from=kitterman.com;
  X-AOL-REROUTE: YES
  x-aol-sid: 3039ac1add42536fade22f5e
  X-AOL-IP: 199.175.55.32
  X-AOL-SPF: domain : kitterman.com SPF : fail
  
  --8C3437094.1399827939/mtaig-mca02.mx.aol.com--
  
  Dear AOL: please stop.  This is brain dead.  In case anyone is wondering,
  no one from i...@kitterman.com sent erica.bbrown any mail telling here we
  had $9500 available for her.
  
  I don't know for sure if this is related to DMARC or not, but the timing
  seems to be roughly in line with their rollout of DMARC p=reject.
  
  I have more if anyone wants to see them.
  
  Scott K
  ___
  dmarc-discuss mailing list
  dmarc-discuss@dmarc.org
  http://www.dmarc.org/mailman/listinfo/dmarc-discuss
  
  NOTE: Participating in this list means you agree to the DMARC Note Well
  terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)