On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos hsan...@isdg.net wrote:
I downloaded OpenDKIM source code to see whats it offers. I believe I saw:
o ADSP was no longer supported, pulled. Grep showed one instance of an
inline comment referring to ADSP.
Correct.
o ATPS was offered, but I
On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez jgo...@seryrich.com wrote:
The question to me is whether the message that the MLM software emits
is the same as the original message. If it is, then the Author ought
to be preserved across the MLM. If it is not, then the MLM emits a
new
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez jgo...@seryrich.com wrote:
Couldn't the DMARC specification spell out that Receivers claiming to be
DMARC-compliant, when choosing to *accept* incoming messages from Senders
publishing p=reject (irrespective of whether such accepted messages passed
or
On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels
mjass...@encs.concordia.ca wrote:
On Sun, 26 Apr 2015 12:21:04 +0200,
J. Gomez jgo...@seryrich.com wrote:
On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote:
The From header field is not in the public domain,
On Thu, Apr 16, 2015 at 9:31 AM, John Levine jo...@taugh.com wrote:
The most tedious and unhelpful discussions here have implicitly (or
perhaps explicitly) assumed that receiver nontechnical costs don't
matter, then repeatedly pointed out the true but useless fact that
there are single party
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine jo...@taugh.com wrote:
At least, we need to look at what non-technical costs they push onto other
parties.
Some changes have insignificant non-techincal costs and are not
controversial, e.g., adding a List-ID header for the benefit of
On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink tz...@exchange.microsoft.com
wrote:
1. For Hotmail, every mailing list that our users are signed up for would
result in a new DNS entry. How do we manage the lifecycle around that?
Should we automate its addition? Should we automate its removal? Do
On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman skl...@kitterman.com
wrote:
For the umpteenth time, the issue isn't managing a DNS zone. That's the
easy
part. The hard part is knowing what to put in it. Many companies, not
even
the really big ones, have thousands of domains. Go publish
Colleagues,
The DBOUND working group has officially formed. We will be working on the
question of what to do about our concerns with the Public Suffix List,
which is an important component of DMARC, so it's relevant here.
The chairs will be announcing to that list soon what our plan of attack
On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
Remembering to what great lengths the ietf-dkim group went to make sure
that every bit of a message was covered by the signature (and with the l=
discussions in mind) I would really be surprised if adding
On Tue, Apr 14, 2015 at 12:03 PM, Terry Zink tz...@exchange.microsoft.com
wrote:
Getting someone to add anything to DNS doesn't work well [3] unless it is
automated because the majority of people that I work with in the customer
space don't feel comfortable managing DNS; it is rare that I
On Tue, Apr 14, 2015 at 7:56 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
If I misunderstood the proposal and it requires someone to be
keeping a list of mailing lists used (either globally or by
individual users), then I think this is not a good idea at all. I
don't think any
On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull
turnb...@sk.tsukuba.ac.jp wrote:
Douglas Otis writes:
If the DMARC domain fails to step up, then a reasonable fallback
could require the display of the Sender header offering the needed
alignment.
I don't understand this. We
On Apr 13, 2015 2:22 PM, Rolf E. Sonneveld
But, if this 'registration' does not apply to the 'mandatory tag draft',
that means that every sender will always add the weak signature +
'fs=initial domain' and a replay attack is reduced to breaking the weak
signature?
You can't reuse the weak
On Thu, Apr 9, 2015 at 10:47 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
TPA is still on the table for other 3rd party services (invoicing etc),
because conditional signatures do nothing for them.
I suggest that TPA or ATPS are way too complicated for third party services
like
On Wed, Apr 8, 2015 at 7:06 PM, John Levine jo...@taugh.com wrote:
It seems to me that this addresses the same issues that the list
mutation stuff does with a lot less complication, and without having
to enumerate all of the ways that a list might change the message. It
only assumes that the
On Thu, Apr 9, 2015 at 11:25 AM, John Levine jo...@taugh.com wrote:
Yeah, now that I look at your drafts again, I see that we are both
making the same assertion that this message is a mutated version of
one that someone else sent. I still like mine better because trying
to enumerate all of
On Wed, Apr 8, 2015 at 9:19 AM, John Levine jo...@taugh.com wrote:
Comments on either or both are welcome.
They both have the same problem: the list says:
Here's what I did. Whadda ya think?
Every recipient system has to come up with its own heuristics to
decide what combinations of
On Wed, Apr 8, 2015 at 7:06 PM, John Levine jo...@taugh.com wrote:
I updated my conditional signature draft, which is now (thanks to a
suggestion from Ned Freed) the mandatory tag draft.
https://tools.ietf.org/html/draft-levine-dkim-conditional-01
[...]
Well, I'm game to try. Adjustments
Colleagues,
I've posted a new version of draft-kucherawy-dkim-list-canon, which had
expired. It was one of several we were considering a while back as a way
of dealing with some indirect mail flows.
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/
Also, I've posted a new one
On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
if DMARC is really the succes that dmarc.org claims it is [1] and with so
many of the big ESPs around here [2] I fail to see why it would be so
difficult to involve the MUA developers of these same ESPs?
On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy superu...@gmail.com
wrote:
If the input is the message and the output is a set of zero or more
SDIDs representing domains whose signatures validated, then I don't think
it matters if we go the v=2 route or the new header field name route
On Thu, Apr 2, 2015 at 6:25 PM, John R Levine jo...@taugh.com wrote:
So receipt of a message signed in the new form will likely produce an
incorrect signature validation, ...
I wondered about that, too, so before I proposed a version bump, I took a
look at the code that people use:
*
On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker d...@dcrocker.net wrote:
The main difference I see is that if we call v2 something else, we now
have a tedious administrative exercise of finding every place something
refers to DKIM and change it to DKIM or DKIM-plus. This does not
strike me
On Wed, Apr 1, 2015 at 6:00 PM, Michael Jack Assels
mjass...@encs.concordia.ca wrote:
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply the DMARC check using each of those domains found in the
On Wed, Apr 1, 2015 at 11:11 AM, John Levine jo...@taugh.com wrote:
Has anyone looked at my double signing draft? The idea is the the
original sender (which we'll call, oh, Yahoo) puts on a very weak
signature probably only on From, Date, and Message-ID, with l=0 and a
new tag that says the
On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin fra...@peachymango.org
wrote:
Looking better...
Special thanks to Elizabeth for improving the document after I integrated
(all?) previous comments. Please see this revision and post
comments/reviews against it.
It sure seems better. :-)
A
On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy superu...@gmail.com
wrote:
There are those among you that disagree, I know. Does anyone have actual
data (not theory, not passion, but data) that any of the policy or
third-party solutions we've discussed before can work, work just about
On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez jgo...@seryrich.com wrote:
No. It is unreliable for Receivers to apply it. Sure, for the Sender
p=reject is perfectly reliable, if he happens to have all his ducks neatly
in a row. But the Receiver cannot know if the Sender has all his ducks
neatly
On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett a...@encs.concordia.ca
wrote:
But yes, the ideal situation is where we sort every message
correctly and unambiguously. Meanwhile...
Even if we grant that p=quarantine is a problem WE cause,
the fact is that until we have a *good* solution for
On Tue, Mar 24, 2015 at 6:46 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
OK, but is it folly to consider a header canonicalization that can
handle this? DKIM is designed to accommodate incremental
improvements, after all.
Sec. 5.3 isn't, though. :-(
As I read 5.3, it says you
On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
An mta could opt to send a message with unencoded utf8 headers (display
name, subject, etc) to another peer advertising SMTPUTF8 even if none
of
the envelope were internationalized addresses. If the
not
- A sends a message to B with an unencoded utf8 Subject: invoking the
SMTPUTF8 extension
- B could opt to encode the Subject: header using rfc2047 to produce a
message acceptable to C
On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy superu...@gmail.com
wrote:
On Tue, Mar 24, 2015 at 8:17 AM
On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez jgo...@seryrich.com wrote:
I know for sure I will publish only p=none for my client's domains, and
use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be
reliably relied on. But I would love to be able to reliably rely on DMARC's
On Mon, Mar 23, 2015 at 5:25 PM, John Bucy jb...@google.com wrote:
Based on a quick glance, it doesn't look like
draft-kucherawy-dkim-list-canon-00 addresses encoded headers like rfc2047.
An mta could opt to send a message with unencoded utf8 headers (display
name, subject, etc) to another
On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker d...@dcrocker.net wrote:
On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote:
And since the From field is the only one users really see every time,
I'm not sure that declaring and supporting yet another
no-seriously-this-is-the-author field would
?
cheers
john
On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy superu...@gmail.com
wrote:
There was one proposed:
https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00
This working group will be discussing this and other options before long.
-MSK
On Thu, Mar 19, 2015 at 1
On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez jgo...@seryrich.com wrote:
Why is it better for DMARC to be adapted to indirect email flows, instead
of indirect email flows to be adapted to DMARC?
What does provide more value to end users at large: indirect email flows
to be kept old-style, or the
There was one proposed:
https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00
This working group will be discussing this and other options before long.
-MSK
On Thu, Mar 19, 2015 at 1:45 PM, John Bucy jb...@google.com wrote:
I was glad to see mention of content-transfer-encoding
On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink tz...@exchange.microsoft.com
wrote:
If bulk email providers have shown no interest in promoting a solution,
why do we think they'd latch onto this new non-aligned header field as a
solution?
+1. And since the From field is the only one users
On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen t...@eudaemon.net wrote:
Hi Murray Elizabeth, thanks for wrestling this through the process. The
Working Group can now adopt this as input.
/goes off to figure out which buttons need to be pushed
=- Tim
I have to resubmit it as
FYI:
-- Forwarded message --
From: rfc-edi...@rfc-editor.org
Date: Wed, Mar 18, 2015 at 1:04 PM
Subject: RFC 7489 on Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
Cc: drafts-update-...@iana.org,
On Tue, Mar 17, 2015 at 8:23 AM, Alessandro Vesely ves...@tana.it wrote:
Right, which is why things like semi-colon don't need to be
percent-encoded; they're already special characters in the context of a
URL.
So are comma and exclamation. What puzzles me is that DMARC spec treats
them
On Mon, Mar 16, 2015 at 3:51 AM, Alessandro Vesely ves...@tana.it wrote:
Section 2.2 of RFC3986 lists semi-colon as a reserved character that has
to
be percent-encoded in these URLs. We don't need to repeat it here, I
think.
If the spec is going to be read by ignorants like me, it's
On Mon, Mar 16, 2015 at 12:57 PM, Steven M Jones s...@crash.com wrote:
Just to be explicit, it also allows for multiple mailto: URIs -
something that is seen in the wild, though perhaps not if one looks up
a half dozen DMARC records at random. But at the end of January multiple
mailto: URIs
On Mon, Mar 16, 2015 at 12:22 PM, Murray S. Kucherawy superu...@gmail.com
wrote:
Your question is Are they equivalent? I believe they are. Although it
might be ideal to have a specification so tight that there's exactly one
way to do something, in the end I don't think it's harmful to have
On Sun, Mar 15, 2015 at 11:53 AM, Alessandro Vesely ves...@tana.it wrote:
This seems to be a bug:
OLD:
dmarc-uri = URI [ ! 1*DIGIT [ k / m / g / t ] ]
; URI is imported from [URI]; commas (ASCII
; 0x2c) and exclamation points (ASCII
at 4:05 PM, Franck Martin fra...@peachymango.org
wrote:
--
*From: *Murray S. Kucherawy superu...@gmail.com
*To: *dmarc@ietf.org
*Sent: *Friday, January 30, 2015 1:23:48 AM
*Subject: *[dmarc-ietf] Comments on draft-ietf-dmarc-interoperability
Thanks for putting
Thanks for putting this together. Here are the results of a late-night
first-time reading:
Section 2:
The sentence starting This the secondary appears to be mangled. I can't
parse it.
Section 2.1, paragraph 1:
The first sentence reads like a basic tautology: A fundamental aspect of X
is the
On Tue, Jan 20, 2015 at 6:14 PM, John Levine jo...@taugh.com wrote:
Do people concur with this change, or something close to it?
I'm OK with it, but to the meta-question, I realize the practical
issues involved with yanking something out of the production queue,
but in this case I wonder if
On Tue, Jan 20, 2015 at 1:44 PM, Anne Bennett a...@encs.concordia.ca
wrote:
I apologize for my inadvertently poor timing; I was catapulted
into all this last week when my parent domain (also my
Organizational Domain) published an SPF record and a DKIM
record, and we became concerned that they
On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen t...@eudaemon.net wrote:
No objection — please do use the WG’s tracker for these items. Anne’s
thorough review will be picked up (and not rediscovered!) if we’ve got an
obvious place to start from.
Done for Anne's points, and I'll do so for Jim
On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen t...@eudaemon.net wrote:
DMARC implementations are already in the wild and deployed. Input to the
existing specification will be largely based on working implementations.
You might have your own reasons for waiting for this WG to review the DMARC
Hello Anne,
On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett a...@encs.concordia.ca
wrote:
Having just spent several hours poring over this document
(-12), I might as well send my additional minor observations.
I suspect that some of you will consider these items trivial,
but they gave me pause
On Thu, Jan 1, 2015 at 1:02 PM, Kurt Andersen kander...@linkedin.com
wrote:
I'm OK with the new wording, but would have liked to see the -09 statement
about reporting temp errors carried over:
When otherwise appropriate due to DMARC policy, receivers MAY send
feedback reports regarding
On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
3.1.3 Flow diagram
The box titled 'User Mailbox' could give the impression that there's only
one choice for delivery. However, quarantining can be done without delivery
to a mailbox. I'd suggest to
OK, seriously, I hope I don't have to crack this open again. Conflict
review is slated for the 1/8 telechat, and a flurry of last minute edits
might not sit well with the IESG. We need to leave actual work, as much as
at all possible, to the WG, and not to hacking on the ISE version.
Diffs to
On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman skl...@kitterman.com
wrote:
I don't think it does. What I was trying to say is that if you already
got an
aligned pass from one method, you're done. It doesn't matter if they other
one gets a DNS error, you already have a definitive result.
On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker dcroc...@gmail.com wrote:
One could argue either way about the multi-valued From:, but at least it
has an essential relationship to DMARC, since DMARC evaluates From:. If
DMARC were required to handle multi-valued From:, it would alter DMARC
On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman skl...@kitterman.com
wrote:
5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very
least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide.
I'm not clear why you say it doesn't. 5.6.3 describes two options for
On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman skl...@kitterman.com
wrote:
The draft strongly encourages DMARC implementers to ignore SPF policy, so
I don't think assuming messages will be deferred due only due to SPF or
DKIM results indicating a temporary DNS error is appropriate.
If
On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker d...@dcrocker.net wrote:
I disagree. DMARC operators all seem to apply this practice, so it's
correct to say that if you play this game, you reject mail from
non-existent domains. Essentially in this way DMARC is a profile of
On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman skl...@kitterman.com
wrote:
Messages for which SPF and/or DKIM evaluation encounters a temporary
DNS error have not received a definitive result for steps 3 and/or 4
above.
If the message has not passed the the DMARC mechanism check
On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker d...@dcrocker.net wrote:
The goal, as you state it, is at the level of seeking world peace. It
is very laudable and and very, very broad. It covers vastly more than
the scope of DMARC.
DMARC is a specific bit of technology working towards that
Hi Rolf, getting back to your review (thanks for the nudge):
On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
Abstract:
This lack of cohesion has several effects: receivers have difficulty
providing feedback to senders about authentication, senders
On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman skl...@kitterman.com
wrote:
As I read -08 what to do in that case is undefined. There's a dangling
pointer
to 5.6.3. It's dangling because nothing in that section addresses the
question of how to handle DKIM/SPF temporary errors.
5.6.3's
On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman skl...@kitterman.com
wrote:
There was a recent thread on postfix-users about DMARC rejections when
there
are DNS errors that caused me to review -08 to see what it says on the
matter.
At the end of section 5.6.2, it says:
Handling of
Covering the stuff Dave didn't cover:
On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton fen...@bluepopcorn.net wrote:
Top of page 6: The receiver reports to the domain owner... The
receiver actually sends reports to a report receiver designated by the
domain owner.
Fixed.
2.4 Out of Scope
I
On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin fra...@peachymango.org
wrote:
I think we should recommend something here, not sure if it needs to be
normative. We do say to ignore the SPF policy when p!=none, though I think
we can be normative on the lower layers. I see 2 options here:
On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin fra...@peachymango.org
wrote:
--
*From: *Murray S. Kucherawy superu...@gmail.com
*To: *Franck Martin fra...@peachymango.org
*Cc: *dmarc@ietf.org, Scott Kitterman skl...@kitterman.com
*Sent: *Tuesday, December 23
Colleagues,
draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been
pointed out that a review from back in April has not been properly attended
to.
Could I get the WG (forgive me, co-chairs!) to comment on this so that I
can see what changes might be appropriate here? Having
On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin fra...@peachymango.org
wrote:
I'm just asking for this list to be set up exactly like the i...@ietf.org
list. If Elizabeth ensures she emails in txt only, everything will be fine.
i...@ietf.org is the outlier, actually. Every other IETF list
I've posted an update to the base draft, based on recent feedback from Ned
and others. Hopefully I've resolved all of the concerns (especially the
major ones), as the ISE would like to send the draft to the IESG for
conflict review in the next day or two. It also has to begin formal review
of
On Fri, Nov 7, 2014 at 10:06 AM, John Levine jo...@taugh.com wrote:
1) Evaluate all the domains you find, and if any of them have published
DMARC policies, apply the strictest one ...
Given the anti-phishing goals of DMARC, I don't see how anything else
makes any sense. Or you could skip a
On Fri, Nov 7, 2014 at 8:57 PM, turnb...@sk.tsukuba.ac.jp wrote:
Trent Adams writes:
-
It is important to note that identifier alignment cannot occur, and
DMARC determination applied, with a message that is not valid per RFC
5322 [MAIL]. This is particularly true when a message has
On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink tz...@exchange.microsoft.com
wrote:
Since SPF authorizes an often _shared_ outbound IP address, it has been
accurately described
as an authorization method. DMaRC permits a DKIM signature to be
spoofed and still allow
a message to be accepted
On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman skl...@kitterman.com
wrote:
On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote:
...
As was done with the DKIM deployment RFCs, the same has been done for
DMARC. It seems neither DKIM nor DMARC follow the path of least
Just noticed that I never replied to this:
On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman skl...@kitterman.com
wrote:
Since this is the WG list, I'm not sure if this is still the right list for
issues with the base spec or not, but here goes ...
The definition of fo in Section 5.2, General
Colleagues,
With apologies once again that it's taken so long, I have submitted the
base draft again to the datatracker. It underwent what Eliot Lear calls a
haircut, which is to say I spent a good chunk of time rearranging the
material, consolidating redundant sections, removing unnecessarily
On Sat, Oct 25, 2014 at 9:57 AM, Dave Crocker d...@dcrocker.net wrote:
On 10/25/2014 12:34 PM, J. Gomez wrote:
DMARC is a DKIM Policy Framework. According the marketing, it has gain
widespread adoption especially among your list users domains. Isn't
why you are here, to stop it?
If by
On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos hsan...@isdg.net wrote:
I'm already lost of whats going on. It seems we are waiting of Murray. Its
all Murray. Geez, Its all really Murray's framework to all this. Not a
negative, but there has to be more. There is more. There has always been
On Tue, Oct 7, 2014 at 1:41 PM, Tim Draegen t...@eudaemon.net wrote:
The intention is to have something in place -- the MLM model -- that can
be used to quickly identify issues that are related to DMARC
interoperability with any given piece of MLM software. I read Alessandro's
model as a way
On Mon, Oct 6, 2014 at 2:52 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
Can I get some clarification on the intent here? As worded, this
paragraph suggests that we are looking to produce a model for MLMs to
follow in a DMARC-aware world. I was under the impression that (a)
On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos hsan...@isdg.net wrote:
Murray, I think we need to make the distinction of two different concepts
and acronyms; MLM Mailing List Manager and MLS Mail List Servers that
serve the MLM market. There are some basic integration guidelines for both
the
On Wed, Sep 17, 2014 at 1:43 AM, Sven Krohlas sven.kroh...@1und1.de wrote:
RFC 7372 proposes to use a 550 response code for reverse DNS auth
failures, see section 3.3.
Reverse DNS checks are usually done early in the connection (like IP
blocks) in the connection establishment stage of the
Colleagues,
As you know, the DMARC base draft is being processed via the Independent
Stream. Procedurally it's ready to move forward toward publication, with
the caveat that the prose in it needs a serious haircut. (There is also
the option to split the document before publishing it, but I
Though I would never put such a thing in a standards document, OpenDKIM
does have the capability to rewrite arriving header fields prior to
signing/verifying to overcome things like this. Your ESP's verifier could
be trained to ignore the added line prior to verifying, or better yet, do
DKIM
How will most mail clients know not to display it if it's made part of the
body?
On Mon, Sep 15, 2014 at 4:39 PM, Terry Zink tz...@exchange.microsoft.com
wrote:
Having the Virus scanned by xxx defeats the purpose of advertising
because most mail clients won't display it, and the point of
On Fri, Aug 29, 2014 at 7:13 PM, Douglas Otis doug.mtv...@gmail.com wrote:
While the PSL might be useful for offering some web related assertions,
its current form is inappropriate for email policy. Those working on the
web/email related issues might hope these common concerns will engender
On Fri, Aug 29, 2014 at 12:37 PM, Tim Draegen t...@eudaemon.net wrote:
Simply put, the public suffix concept is useful beyond what DMARC requires
of it. The best that DMARC can do (as a piece of technology) is fully
articulate 1 specific use case for the public suffix concept, and hope that
On Sat, Aug 23, 2014 at 7:34 AM, Miles Fidelman mfidel...@meetinghouse.net
wrote:
I did notice the absence of anything related to process. How are we going
to get to a document (that) captures all known interoperability issue
between DMARC and indirect email flows? If this were an RFC,
On Tue, Jul 29, 2014 at 4:42 PM, Tomki Camp tc...@agari.com wrote:
5.2 has 'A DMARC policy record MUST comply with the formal specification
found in Section 5.3
http://www.blackops.org/%7Emsk/dmarc/draft-dmarc-base.html#dmarc_abnf in
that the v and p tags MUST be present and MUST appear in
[Changing Subject: to a new thread and dropping i...@ietf.org, since this
is not charter discussion]
On Sun, Jul 20, 2014 at 12:27 AM, Douglas Otis doug.mtv...@gmail.com
wrote:
ATPS is not the lite version of TPA-Label. This is explained in
On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely ves...@tana.it wrote:
My question about the stance toward DKIM tweaks[1] was never answered.
To re-state, while preclusion is apparent for the organizational
domain issue, it is not clear for DKIM. The charter says:
The working group
On Wed, Jul 2, 2014 at 9:59 AM, Douglas Otis doug.mtv...@gmail.com wrote:
Agreed, as it seems such efforts have been excluded by the charter
language. It would be a shame, since there needs to be a remedy permitting
back-office services such as those offered by Intuit and the like. It
seems
On Thu, Jun 26, 2014 at 10:26 AM, Jim Fenton fen...@bluepopcorn.net wrote:
The base specification relies on the ability of an email receiver to
determine the organizational domain responsible for sending mail. An
organizational domain is the basic domain name obtained through a public
: New Version Notification for draft-kucherawy-dkim-delegate-01.txt
To: Murray S. Kucherawy superu...@gmail.com, Dave Crocker
dcroc...@bbiw.net
A new version of I-D, draft-kucherawy-dkim-delegate-01.txt
has been successfully submitted by Murray S. Kucherawy and posted to the
IETF repository
On Fri, Jun 20, 2014 at 11:21 AM, John Levine jo...@taugh.com wrote:
This looks an awful lot like my draft-levine-cdkim-00 and
draft-levine-dkim-conditional-00 except that mine has more bits of
DKIM in the cdkim signature so it can sign To and From to limit the
range of spoofage.
The
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos hsan...@isdg.net wrote:
While DKIM-BASE tried to clean up this separation of the author domain
policy, it could not because of all the past existing ADSP or SSP
references in the many DKIM related RFCs, see RFC6376, section 1.1. But
On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis doug.mtv...@gmail.com
wrote:
Our company has had extensive experience dealing with email spoofing.
While reputation is able to deal with bulk spamming, it is ineffective at
dealing with a phishing problem, the intent behind DMARC. It is a basic
701 - 800 of 838 matches
Mail list logo
