On May 7, 2013, at 5:01 PM, Roman Prokhorov <r...@stalker.com> wrote:
> Hello,
>
> I'm new to this list; trying to implement DMARC in Perl as a plugin for
> CommuniGate Pro mail server.
There is this DMARC plugin that is a Qpsmtpd plugin, in perl:
https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/dmarc
And don't forget about CPAN, where you can find these:
http://search.cpan.org/~shari/Mail-DMARC-opendmarc/
http://search.cpan.org/~msimerson/Mail-DMARC
We are both running DMARC in production but neither Davide's nor my modules
have the reporting elements completed. I'm writing the report aggregation
functions right now.
> So far so good, I have already implemented the "authentication" part; will
> share the sources when I get all the nuances sorted out.
>
> Have been checking emails we receive (mostly spam) against DMARC for last
> several days and to my surprise there are very few emails from domains who
> have DMARC records. E.g. google.com has one but gmail.com doesn't. This means
> DMARC can't be treated as a way to combat spam, at least for now; and in my
> understanding it's primary purpose, given a stream of legitimate emails, is
> to reveal emails which are "more legitimate" than others :-)
Have you read the draft proposal yet?
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
The email ecosystem currently lacks a cohesive mechanism through
which email senders and receivers can make use of multiple
authentication protocols in an attempt to establish reliable domain
identifiers.
DMARC's main purpose is to authenticate who a message is from. A side effect is
to reduce the prevalence of phish and joe-job attacks. It does this by
replacing the bounces one would normally get when someone spams using their
domain with specially crafted emails containing gzipped XML files which are
typically larger than the spam they'd have received otherwise. It is
particularly effective at this.
DMARC will not likely reduce the amount of spam. What it is likely to do is
discourage spammers from sending spam using other organizations domain names.
So they'll continue to buy or "taste" domain names, set them up with SPF, DKIM,
and DMARC records, spew a bunch of spam from that domain name, and then discard
it.
> Currently I have some questions regarding the implementation of DMARC:
>
> If a domain has DMARC record, do I have to expect messages pretending to be
> from that domain to have DKIM signatures?
I think this question has been answered in the Draft at:
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
DMARC operates as a policy layer atop implementations of DKIM and
SPF. These technologies are the building blocks of DMARC as each
technology is widely deployed, supported by mature tools, and is
readily available to both senders and receivers. They are also
complementary, as each is resilient to many of the failure modes of
the other. Furthermore, neither of these require direct user
interaction to be successful, nor are they burdened by heavy
considerations such as public key infrastructure, which have
inhibited the uptake of other message signing and encryption
protocols. (For further discussion, see Section 1 of [DKIM].) In
addition, DMARC can operate even if a message author has chosen to
deploy only one of these.
See also Appendix A.2.
> As I understand I don't, and in order to pass DMARC test a message has to
> pass SPF *or* DKIM test (not *and*), right?
Correct.
> Additionally, if SPF/DKIM check passed it has to pass the appropriate
> "alignment" test - this is the new part which was introduced in DMARC.
Aye.
> The final result of the DMARC check can be either pass or fail (when both SPF
> and DKIM failed, or when SPF passed but SPF alignment failed, or DKIM passed
> but alignment failed), no neutral result. Or what?
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
Section 4.3. It answers your question in precise detail.
> When a message has non-existent/invalid/etc domain in From, should it be
> treated as failed the DMARC test, or DMARC is not applicable here?
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
Section 15.1:
The absence of a single, properly-formed RFC5322.From field renders
the message invalid.
The complete answer is more complex, obviously, but is also covered amply in
the draft.
Matt_______________________________________________
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)
