I hope this would be a consideration as a fix or method to address the
problem with DMARC's p=reject restrictive policy for 3rd party
signers, including mailing list.
Please correct any misunderstanding with the DMARC draft I may have.
DMARC by definition requires alignment for matching
On 4/21/2014 2:54 PM, Vlatko Salaj wrote:
On Sunday, April 20, 2014 9:00 PM, Hector Santos wrote:
This would be a simple first step consideration -- A new ATPS tag
this may fix DKIM 3rd party support, but does little to support
3rd party SPF. i think it's important to have a fix for all
n 4/24/2014 2:27 PM, Terry Zink wrote:
ADSP was brushed off because the same folks who believed ADSP's strong
reject/discard policy concept will ever get used, also believed DMARC's strong
p=reject will never be used as well, and certainly not by the likes of a AOL.COM
and YAHOO.COM, two aged
On 5/24/2014 4:10 PM, Matt Simerson wrote:
On May 24, 2014, at 12:50 PM, Hector Santos hsan...@isdg.net wrote:
Off hand, I think the DMARC draft needs to be updated for two basic fundamental
parts:
1) Separate Policy Handling and Reporting. If I read the draft right,
reporting
On 5/28/2014 9:47 PM, Arvel Hathcock wrote:
Anything that requires mailing list software to change won't work. If
mailing list software is changed, the right answer is for the mailing
list to re-sign the message. That doesn't help the DMARC situation
now, but DMARC could be given other
On 5/29/2014 3:09 AM, Murray S. Kucherawy wrote:
On Thu, May 29, 2014 at 12:06 AM, John R Levine jo...@taugh.com
mailto:jo...@taugh.com wrote:
By the way, to return to the original point, it still seems
vanishingly unlikely to me that if we invented per-sender
whitelists that the
On 5/29/2014 4:28 PM, J. Gomez wrote:
On Wednesday, May 28, 2014 10:13 PM [GMT+1=CET], Tim Draegen wrote:
I don't believe TPA-Label hits the mark between solving a big hurt
and simple. IOW, it's too complicated for the amount of pain it
would resolve. Just my opinion, take care,
I'm of the
that your mail is being displayed
with invalid indicators on a wide spread set of mail reading devices.
--
Hector Santos
http ://www.santronics.com
On Jun 4, 2014, at 10:39 AM, John Levine jo...@taugh.com wrote:
But that is not equivalent to putting non-resolvable gibberish on the right
side
On 6/8/2014 11:30 AM, Murray S. Kucherawy wrote:
On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj vlatko.sa...@goodone.tk
DMARC participating MTAs SHOULD include Authentication Results
for all underlying protocols (SPF/DKIM), as well as such results
for DMARC validation itself, among
On 6/9/2014 2:01 AM, Matt Simerson wrote:
I also fail to see how this is a security issue.
Agreed. It's *really* easy to filter and block delivery
for non-existent domains.
That is exactly what will be required to mitigate and close this new
security hole.
if mail.from.tld is .invalid
On 6/10/2014 9:55 AM, Stephen J. Turnbull wrote:
Hector Santos writes:
Are you oppose to any other domain using strong policies or just
certain ones?
Domains where users have until now felt free to use their mailboxes as
they see fit (posting to mailing lists, as From: in on-behalf
On 6/10/2014 6:55 PM, Dave Warren wrote:
I've been surprised how many otherwise-technically-competent people
use subject tags to filter mailing lists. However, I suspect much/most
of this could go away if MUAs started displaying List-* information in
a useful way, and made filtering on those
On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote:
One thing that is missing (and there's a placeholder for it) is
examples so you can see how it works. I'll make sure that's there for
-01.
Examples are good. Can we work it out here, a software walkthru?
Save some drafting time.
The
.
And that comes from two key concepts, it was historically never expected to be
altered (for any communication system past and present) and its the minimum
default identity for replying.
--
Hector Santos
http://www.santronics.com
___
dmarc mailing list
On Jun 14, 2014, at 5:25 AM, Patrick Rauscher lis...@prauscher.de wrote:
Hey,
On Fri, 2014-06-13 at 22:35 -0400, Hector Santos wrote:
Perhaps I'm oversimplifying, but it has seemed self-evident that you need a
single identifier that is displayed to the end user and 5322.From
to be problem for me, you and most domains. Most domains are not
going to need such scale or expect to be authorizing anyone else but
themselves. Besides, we are talking software -- let it do the work.
Personally, it's getting ridiculous. So much time being wasted.
--
Hector Santos
http
On 6/16/2014 4:17 PM, John Levine wrote:
Here's a draft that puts the forwarding thing into DKIM, with the
dread version bump. It defines a general syntax for conditional
signatures, with the forwarding signature the only condition defined
so far. (Since you asked, new conditions don't need
.
--
Hector Santos
http://www.santronics.com
On Jun 19, 2014, at 12:49 PM, S Moonesamy sm+i...@elandsys.com wrote:
Hi Matt,
At 18:58 15-06-2014, Matt Simerson wrote:
Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM
failure is frequently not a sufficient basis
reputation method doesn't exist in practice for everyone to use.
The DNS-based author domain defined policy is the only common approach we have
now.
--
Hector Santos
http://www.santronics.com
On Jun 19, 2014, at 2:45 PM, Murray S. Kucherawy superu...@gmail.com
wrote:
On Thu, Jun 19, 2014
On 6/20/2014 12:13 AM, Stephen J. Turnbull wrote:
Hector Santos writes:
The DNS-based author domain defined policy is the only common
approach we have now.
To a man with a hammer, every problem looks like a nail.
Yes, indeed, in this case, it is that simple -- Occam's razor. Quite
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. If this discussion is successful, we would like to also
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. At the conclusion we can
On 6/27/2014 3:26 PM, Jim Fenton wrote:
There's a proto-wg called dbound thinking about this topic. Marc
Blanchet and I are trying to write up a problem statement before the
Toronto cutoff, so we can at least try and see if there is any
agreement on what problem we're trying to solve.
That's
On 6/26/2014 9:13 PM, Chris Meidinger wrote:
So two questions to the group:
1: Regardless of whether it has simply always been that way, could list
operators forego modifying message bodies by adding footers?
But will operators forgo adding footers for this as a standard
practice? You
made into an STD document last year and already
there is consideration in changing.
Thanks
--
Hector Santos
http://www.santronics.com
On Jun 28, 2014, at 8:01 PM, Wei Chuang wei...@google.com wrote:
Hi Hector
On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos hsan...@isdg.net wrote:
On 6/28
So what are we looking for? A new RD effort? What about all the threat
analysis and functional requirement design done (RFCs)? Does this suggest new
or renewed signing authorization proposals are welcome?
--
Hector Santos
http://www.santronics.com
On Jul 2, 2014, at 2:01 PM, Barry Leiba
On 7/3/2014 11:04 PM, Pete Resnick wrote:
As the working group develops solutions to deal with indirect mail
flows, it will seek to maintain the end-to-end nature of existing
identifier fields in mail, in particular avoiding solutions that
require rewriting of originator fields.
It is simply
On 7/20/2014 12:27 AM, Douglas Otis wrote:
This is missing two citations that I thought were supposed to be
included, since they touch on indirect email flows:
Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
DKIM Third-Party Authorization Label -
That is should be expected when people monkey around with long time
mail infrastructure. Its a bad idea and sets a terrible precedent by
alluding to the idea its normal. No its not normal. It will be
exploited and probably its too late to put this one back if a few
mailing list packages are
. This is not good mail engineering. I
make no apology for having strong moral ethical feelings about it.
--
Hector Santos
http://www.santronics.com
On Sep 9, 2014, at 11:44 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Derek Diget writes:
How are such modifications RFC5321 compliant
On 9/13/2014 5:28 PM, Scott Kitterman wrote:
I'm confident we're going to end up with a portfolio of mitigations, similar to
what's in the Appendices of RFC 7208. I'm equally confident that despite the
distaste many of us feel when we consider it, rewriting From in the MLM is
going to be on the
it at a site because it is rewriting but he won't be able to use it
at other sites and in not in general.
--
Hector Santos
http://www.santronics.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
.
Have a good day Stephen
--
Hector Santos
http://www.santronics.com
On 10/6/2014 10:29 PM, Stephen J. Turnbull wrote:
Hector Santos writes:
The 2006 DSAP draft section 3.3 Mailing List Servers suggest some
simple basic concepts that I believe is near universal.
URL, please. I never heard
permission to do
so that all downlinks can verify. But then we will have a backward
compatibility loophole.
Thanks Murray. Have a good day.
--
Hector Santos
http://www.santronics.com
On 10/6/2014 8:03 PM, Murray S. Kucherawy wrote:
On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos hsan...@isdg.net
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 more, that is why we are lost here after 9 years.
We need policy and we
On 10/26/2014 10:10 AM, Murray S. Kucherawy wrote:
On Fri, Oct 24, 2014 at 2:17 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Hector Santos writes:
POLICY has been reestablished as the DKIM framework long ago.
I have no clue what this sentence means. What is POLICY? What is
the DKIM
On 10/28/2014 4:16 PM, Brett McDowell wrote:
Brett McDowell wrote:
I suspect there was a purpose for that argument that might still be
relevant to our work even though the argument doesn’t seem to be supported,
but I’m not seeing it yet.
Hector Santos hsan...@isdg.net wrote:
Thats
On 11/8/2014 8:29 PM, Franck Martin wrote:
Note that an email with no RFC 5322 field is not valid, as well as one with
more than 1. This header is mandatory as well as the Date header. These are the
only 2 headers mandatory in an email.
So rejecting an email with no RFC 5322 or more than one
On 11/9/2014 4:19 AM, Franck Martin wrote:
I'm not talking on how many mailboxes/domain there are in this header
It would be wrong to assume SMTP will reject messages based on possible
RFC5322 violations.
While SMTP implementations have been lenient, they have been lenient in a way
which
On 11/21/2014 12:56 PM, Tim Draegen wrote:
WG,
The work found here:
http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki
..is almost complete. However, there is a note (reinforced by
feedback during the recent in-person meeting) to recast the collected
issues in terms of RFC 5598.
On 11/29/2014 7:04 AM, José Ferreira wrote:
Like is said, they are rare but important. And some domain owners may not adopt
p=reject for that reason.
Jose Borges Ferreira
Domains that publish a p=reject and don 't understand its possible
outcomes, shouldn't be our (IETF protocol standards
I have two concerns.
It seems you jumped the gun to accept the RFC 4408 obsolete idea. Is
7208 backward compatible or not? Does DMARC require 7208 operations
or 4408 operations?
And is this -12 publication worthy of even considering for
implementation? Or should we wait for the more solid
on the unknown tag atps=y which is good and tells us
we are very ready for a DMARC extensions market.
Bye
--
HLS
On 1/27/2015 11:36 AM, Hector Santos wrote:
On 1/25/2015 10:03 AM, Anne Bennett wrote:
Hector Santos hsan...@isdg.net:
DMARC uses the result of SPF authentication of the MAIL FROM
On 1/23/2015 8:29 PM, Murray S. Kucherawy wrote:
For reasons not worth getting into now, this version of the base
specification is on track to be published not as a standard but as an
Informational document, kind of as a handoff step between the team
that first developed DMARC and the IETF,
On 1/24/2015 6:08 AM, eugene hayhoe wrote:
As an IT non-professional (in every sense of the word, I only joined this group
out of frustration at no longer having reliable access to several email lists I
had enjoyed for years previously, in an attempt to understand WHY that was so)
VERY
On 1/25/2015 10:03 AM, Anne Bennett wrote:
Hector Santos hsan...@isdg.net:
DMARC uses the result of SPF authentication of the MAIL FROM
identity.
Does that mean it gets return-path from the Authentication-Result:
header? or the Return-Path:, Sender: headers?
It doesn't say how it gets
As a long time total mail system product(s) developer, at this point,
IMV, we have a marketing problem.
We did have technical solutions laid out with 3rd party authorization
concerns. However, it hasn't been sold enough and if even if you
do work it, you have to champion it. One can't
On 3/9/2015 8:01 PM, Steve Atkins wrote:
But this seems contrary to information from OpenSPF:
http://www.openspf.org/Best_Practices/Webgenerated
The key component is to ensure that the SMTP MAIL FROM address is from your domain. After that,
adding Sender: or Reply-To: headers is good
-- there is not just one type
of course, even if there is a monopoly, there are far too many MUAs. This
includes the old school RFC-based MUAs. The current trend is to move users to
online MUAs, but that has always been a direction with the older methods still
viable. They are not going away.
--
Hector Santos
For nearly 10+ years we have discussed the same basic design issues.
Nothing has changed other than the fact it is DMARC, as it is
currently written as the replacement protocol for a DKIM POLICY
SSP/ADSP framework, is very lacking intentionally. We don't have
enough of the advocates we once
Murray,
Thanks for your comments. The key difference today is that we have
finally achieved the long term engineering considerations of:
1) Getting domains to publish DNS policy records,
2) Receivers performing the DNS policy record lookup,
3) Receivers honoring the mail handling.
We
Don't quite get it, Scott. There is no DMARC record so the
transaction would be DMARC indeterminate -- no DKIM signing policy.
If it did have a DMARC record, in order for this transaction to DMARC
pass, it would require relaxed alignments for SPF and DKIM:
adkim=r
aspf=r
Correct?
Mr. Gomez,
Traditionally, many in the IETF and the mail industry had an aversion
towards strong deterministic transport (system) level filtering ideas.
This is burned into RFC2821/5321:
7. Security Considerations
7.1 Mail Security and Spoofing
This specification does not further
On 4/2/2015 9:25 PM, John R Levine 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:
* Murray's opendkim C library: checks
No.
On 4/23/2015 1:46 PM, Scott Kitterman wrote:
Since the core lookup key off of which everything in DMARC is based is the
5322.From, if you change to use something different, is it even DMARC anymore?
Scott K
On Thursday, April 23, 2015 05:33:53 PM Terry Zink wrote:
I’ve played around a
On 4/27/2015 2:44 PM, Murray S. Kucherawy wrote:
So it seems to me the points of contention here are:
1) Is the MLM violation of the SHOULD NOT cited above the kind of
violation that we accept based on how SHOULD NOT is defined in
RFC2119? It seems to me that it is, especially given how long
On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote:
On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos hsan...@isdg.net
mailto: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
I think overall, there are two concerns I have:
1) The over estimated use of the idea for rewriting and
2) the word or term common is used for mitigation methods.
Common means most and its not the case. Rewriting is a major industry
taboo, in all mail or communications concept. Just because
On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote:
My personal opinion is that, on the contrary, people are already way
too quick to discard proposals simply because they involve changes to
MUAs. Of course, the reality that this is an IETF WG, and what we can
do that has effect with high
On 4/27/2015 4:23 PM, J. Gomez wrote:
Smooth operation?
Mediators don't really need to change, but their entry points need to
support DKIM+POLICY. For example, the Mediator receiver can simply
support honoring restrictive policies and it doesn't need to bother
with much else.
That is
On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote:
GNU Mailman, for example, provides several DMARC mitigations. The
traditionally available just forward configuration is still
available, but disliked strongly because users really like have
unsubscribe and archive links in the footer. The steal
On 4/27/2015 5:51 PM, Scott Kitterman wrote:
What? There is an spec for DMARC. With the current DMARC specification,
anyone can do almost anything and still claim to be DMARC-compliant. What
about if to claim being DMARC-compliant, Receivers could not reinject alien
messages into the email
On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote:
If OpenDKIM is popular among many big systems, it would make sense
to slightly update OpenDKIM so that the atps=y option is based
off a DMARC lookup. The change is small.
Sure, if that's consensus. That would also involve
With all the DKIM Signature Authorization Protocol (DSAP) proposals
and ideas being offered, I think we need to rewrite or re-establish
what are the DSAP goals and functional requirements.
What are we trying to accomplish? Under what conditions and requirements?
I think it has been
constraints. The
host isn't a resigner. If you can't setup a hard fail policy, its all going to
be wasteful and redundant processing anyway.
--
Hector Santos
http://www.santronics.com
On Apr 30, 2015, at 9:37 AM, John Mears john_me...@symantec.com wrote:
Hi.
I wonder if people on this list
On 5/2/2015 1:34 PM, John Levine wrote:
With List-Id becoming a more generic feedback channel, I suspect that its
value for indicating the participation of a MLM will further degrade.
This is news to me. Can you explain or give pointers?
The only application of List-ID with which I am
On 5/5/2015 11:24 PM, Scott Kitterman wrote:
No. It's fundamentally different.
For SPF, the managers of an ADMD need to determine their authorized outbound
email architecture. That's in the hands of the administrators. For these
email list registration proposals it's the mailing list
On 5/7/2015 4:27 PM, Scott Kitterman wrote:
On May 7, 2015 3:54:55 PM EDT, Hector Santos hsan...@isdg.net wrote:
Since 05/2014, I have published DMARC records for several of my
domains. Our mail receivers supports ATPS (rev04) where atps=y tag
extension was added to my records. For example
will work. I believe you wish
to add more complex semantics on the parsing of the lookup results, I believe
that's ok. But we need a basic yes/no query. Maybe it can be sold if we offer
more bang for the buck on each call but overall, it needs to be very simple.
--
Hector Santos
http
On 5/6/2015 2:13 PM, Douglas Otis wrote:
The real problem in using double signature schemes is expiry
will be long enough to support significantly large campaigns
that can't be stopped even after being detected unless DKIM
signatures are pulled. Then of course, this creates nasty
DNS handling
I don't think it correct to be implying we gave it an old college
try when in fact, everything was being done to kill policy ideas.
Murray, Crocker and Levine where the key IETF cogs working on the DKIM
project and all three were pushing a Trust Model, removing the author
domain from the
+1
I agree alternatives should not, nor has it even been required, to
offer criticism in reviews. However, in this case, for what its
worth, I didn't see/read Kurt's comment as criticism so I don't think
the outburst was warranted.
Kurt might explain what he meant but I believe the
On 5/5/2015 1:33 PM, Scott Kitterman wrote:
On May 5, 2015 1:25:43 PM EDT, Hector Santos hsan...@isdg.net wrote:
The main point would be that DSAP protocols can still be completed
making the registration part out of scope. It would be part of the
publishing and adoption, migration section
On 5/5/2015 2:01 PM, Murray S. Kucherawy wrote:
On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman skl...@kitterman.com
mailto:skl...@kitterman.com wrote:
Wrapping a 'somebody else's problem field' around the registration
piece of this doesn't make it any more feasible.
Is it sufficient
...@ietf.org] On Behalf Of Hector Santos
Sent: Saturday, May 9, 2015 10:13 AM
To: dmarc@ietf.org
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note
Your bar is too unrealistically high for typical IETF project work that is
still in the experimental stages. You should be thankful, we
On 5/9/2015 3:01 PM, Scott Kitterman wrote:
On May 9, 2015 1:13:15 PM EDT, Hector Santos hsan...@isdg.net wrote:
Your bar is too unrealistically high for typical IETF project work that
is still in the experimental stages. You should be thankful, we
didn't apply this bar to the SPF experiment
On 5/10/2015 2:14 AM, Murray S. Kucherawy wrote:
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett a...@encs.concordia.ca
mailto:a...@encs.concordia.ca wrote:
Hmm, Hector, I think you've forced me to convince myself that you're
on the right track: I think that the registration problem is a
The registration problem is not a red herring because it doesn't
exist, but because it is intractable. Thus, any response to the
third-party problem that relies on a solution to that problem
(which includes ATPS, DSAP, and TPA) is probably not viable.
I agree.
But I think that some of the
On 5/11/2015 10:33 PM, Scott Kitterman wrote:
On Tuesday, May 12, 2015 11:17:08 AM Stephen J. Turnbull wrote:
Scott Kitterman writes:
Actually, the idea behind MARID was to come up with a single
solution
Is there something we can learn from MARID? I don't see it in the
context of the
On 5/11/2015 2:56 PM, Douglas Otis wrote:
On 5/10/15 10:08 PM, Murray S. Kucherawy wrote:
On Sun, May 10, 2015 at 4:37 PM, Douglas Otis doug.mtv...@gmail.com wrote:
ATPS included an onerous task for any third-party service
likely used on a gratis basis. Each third-party was expected
to learn
On 5/12/2015 1:18 AM, Scott Kitterman wrote:
On Tuesday, May 12, 2015 12:16:19 AM Hector Santos wrote:
On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote:
Scott Kitterman writes:
Actually, the idea behind MARID was to come up with a single
solution
Is there something we can learn from
involved. If not, it didn't solve the problem and it just made the DKIM
integration design extremely more complex!
--
Hector Santos
http://www.santronics.com
On May 9, 2015, at 11:07 AM, Murray S. Kucherawy superu...@gmail.com wrote:
On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull step
Your bar is too unrealistically high for typical IETF project work that is
still in the experimental stages. You should be thankful, we didn't apply
this bar to the SPF experiment.
--
Hector Santos
http://www.santronics.com
On May 9, 2015, at 10:09 AM, Scott Kitterman skl...@kitterman.com
On 5/8/2015 1:29 PM, Anne Bennett wrote:
Murray S. Kucherawy writes (with respect to ATPS if I got this right):
There's still that pesky registration problem to address.
Hector Santos writes:
Separate issue. SPF would not be here if you used this same criteria.
None of the big domains
On 5/8/2015 8:19 PM, Murray S. Kucherawy wrote:
Punting on this as an
implementation issue leaves a pretty substantial hole in whatever
gets rolled out. To me it's like buying a car with a completely
absent steering mechanism, and you have to do the research to figure
out which one fits and
to use the
technology and more than likely hotmail.com won't be able to get their SPF nor
their ATPSrev4 network in order. But Microsoft.com and millions of other
domains can, and millions more won't need too.
It's a feature, an option.
--
Hector Santos
http://www.santronics.com
On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote:
Maybe, maybe not.
Sender is a RFC822 header (since the 80s). Its been around for a long time.
Our MLS added it along with the Error-To for MLM operations.
No option to disable that. I believe we stole the idea from the original
On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote:
This is one of the reasons I have held back from participating in the
discussions/attempts to come up with authorizations for unrelated 3rd parties. Even
recognizing the resistance from various quarters, 3rd parties and intermediaries
On 5/17/2015 2:29 PM, Hector Santos wrote:
Scanning and Reading DMARC reports, I see there are many reports from
an OpenDMARC Filter which includes testing for dkim-adsp and
dkim-atps protocols. An example Auth-Res:
Authentication-Results: .net;
dkim=pass (1024-bit key
Scanning and Reading DMARC reports, I see there are many reports from
an OpenDMARC Filter which includes testing for dkim-adsp and
dkim-atps protocols. An example Auth-Res:
Authentication-Results: .net;
dkim=pass (1024-bit key; unprotected) header.d=ietf.org
On 5/15/2015 11:52 AM, Dave Crocker wrote:
But it is not an operationally practical choice. The problem is that
when that identifier is different from the content identifier, we have
the task of figuring out whether the identity in the Sender: field is
'authorized' to operate on behalf of the
On 4/14/2015 12:53 PM, Douglas Otis wrote:
Dear Scott and Hector,
DMARC offers feedback to help identify where a listing is
needed. This list can be placed in DNS using hash labels
and TSIG, for example.
Sure Doug, yes, there are ways to automate this. The feedback is there
and scripts can
On 4/15/2015 2:08 PM, Murray S. Kucherawy wrote:
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
for, if they had to do it
every day. Most of them probably wouldn't even do it once.
That's the part that doesn't scale.
-- Terry
-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos
Sent: Tuesday, April 14, 2015 2:48 PM
To: dmarc@ietf.org
Subject: Re: [dmarc
On 4/15/2015 6:11 PM, Murray S. Kucherawy wrote:
Also, if one were to interpret the Pareto Principle correctly, it actually
favors the idea that the only things we should consider are the ones the
large operators are willing to adopt, which means it's abundantly clear
that registration
On 4/15/2015 4:39 PM, Scott Kitterman 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.
Right. I never said it was hard problem. This didn't stop the large
domain with SPF in adding INCLUDE and still have
On 4/15/2015 8:55 PM, Terry Zink wrote:
Hi, Hector,
For the umpteenth time, not everyone need 4000 domains. Most of the
domains that will or may utilize it, simply don't need this scale.
I'm not sure you get the point that the others are trying to make. While this
*may* scale for small
and also provide the opportunity for
sites to do registration RD.
--
Hector Santos
http://www.santronics.com
On Apr 16, 2015, at 10:11 AM, Scott Kitterman skl...@kitterman.com wrote:
I will probably regret this, but since people are throwing around things like
Pareto to argue in favor
On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote:
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.,
On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote:
Now I think Scott is right that we need to make a step back and his
analysis might help us to know on which solutions we'd best spend most
of our time. However, having said that, I'm afraid that we're biased
by our discussions around the
On 4/16/2015 8:16 PM, Scott Kitterman wrote:
+1 Extremely bias.
Lets keep in mind that there are two minimum receivers generally with
a MLM transaction that also need to be part of the cost and impact
analysis:
MDA1 -- receiver and resigner
MDA2 -- final user(s) receiver(s).
Another
1 - 100 of 394 matches
Mail list logo
