ed, modern
SMTP receiver, it could perform 3-6 or more DNS redundant lookups for each
transaction, and they are not flexible enough to be lumped together.
--
Hector Santos
http://www.santronics.com
> On Jul 20, 2014, at 2:23 PM, Eric Burger wrote:
>
> I will not comment on the 85 mes
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 - draft-otis-dkim-tpa-
implementations supporting rfc6541. All of our installations
have DKIM+ADSP+ATPS out of the box with their primary domain used for automated
first time setup plug and play readiness.
--
Hector Santos
http://www.santronics.com___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On 7/5/2014 3:20 PM, Pete Resnick wrote:
The current text is now in front of the IESG for internal review.
Assuming we approve it for external review on Thursday, you will see a
announcement soliciting comments. A simple comment, with specific
suggested textual changes, would be welcomed.
R
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 simpl
On 7/3/2014 8:32 PM, Pete Resnick wrote:
On 7/3/14 12:20 PM, Pete Resnick wrote:
On 7/3/14 at 11:26 AM, Andrew Sullivan wrote:
On Thu, Jul 03, 2014 at 11:22:18AM -0500, Pete Resnick wrote:
Oh, I forgot one thing:
The working group will seek to maintain
the viability of stable domain-level id
So what are we looking for? A new R&D 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 L
imentation. DKIM was just 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 wrote:
>
> Hi Hector
>
>> On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos
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 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/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 ha
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
sites especially when it's well
known a common 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.
s realized.
--
Hector Santos
http://www.santronics.com
> On Jun 19, 2014, at 12:49 PM, S Moonesamy 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 no
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 ano
h 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://www.santronics.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> On Jun 14, 2014, at 5:25 AM, Patrick Rauscher 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 e
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
On Jun 8, 2014, at 5:31 PM, Terry Zink wrote:
>> Hector Santos wrote:
>>
>>> It is mentioned in Section 6, but the mention there doesn't even say
>>> that it's the DMARC result that's supposed to be recorded. That bit
>>> at least
On 6/12/2014 7:57 PM, Stephen J. Turnbull wrote:
Sure, but as soon as the spammers adapt and start spoofing lists, you
need to check the list's signature anyway.
And I don't think customers who sign up for a list will be happy with
losing mail for a month.
RECOMMENDATION:
In principle, the L
Please define "fault". Also "lookup". I doubt I'm the only one who
doesn't understand what you mean by these words.
A lookup is a callout, a shim, a hook, a "blackbox" query, a "function
generator" and so on. In this case, the lookup is a DNS-based query.
We can today offer a practical funct
Restrictive 1st Party (Author Domain) Signing Policies
- No Mail Expected
That's not in scope here. You could use draft-ietf-appsawg-nullmx for
that if you really want.
The NULLMX proposal only applies on the SMTP client, sending, callout
side. This one can be folded with the others, but a
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 m
Dave wrote:
>
> Everything gets much easier if we specify guidance for filtering
> engines, before humans come into the picture.
>
+1
--
Hector Santos
http ://www.santronics.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf
Preference should be given to the author domain explicitly authorized
resigners, how ever that black box functionality is achieved. Currently, there
are three DNS-based authorization proposals on the table. From Murray's
follow-up comments, the DKIM-delegate is basically an optimizer to avoid
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 hea
On 6/10/2014 4:21 PM, Stephen J. Turnbull wrote:
Hector Santos writes:
> Will you implement it? You need to implement it as part of the LSP
> integration.
What LSP integration? DMARC is an agreement between Author Domains
and destination hosts. Mediators are not party to it.
On
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-beh
On 6/10/2014 10:00 AM, Murray S. Kucherawy wrote:
On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj
mailto:vlatko.sa...@goodone.tk>> wrote:
"introducing new ML requirements" has already been
characterised as not an ML solution. we have a few
of them already, and all much simpler than an
On 6/10/2014 7:27 AM, Barry Leiba wrote:
>The premise of your proposal is that users will notice that there's
> extra information, know what to do with it, and do the right thing,
> with reasonable consistency.
...
> Each of those conditionals will not actually be satisfied. User's
On 6/9/2014 10:38 PM, Barry Leiba wrote:
Putting as much value on RFC5322 From as DMARC does follows
conventional wisdom, but I believe that wisdom is flawed.
Of course, that speaks to the advice you want to give: tell UIs that
they should show the From addr-spec to users always. But be clear
a
On 6/10/2014 2:16 AM, Stephen J. Turnbull wrote:
I'm not proposing additional validation. As I've said before, I have
no quarrel with the DMARC protocol or its component protocols (at
least I've not found a reason to dislike it yet), although I strongly
dislike Yahoo!'s policy use of "p=reject"
On 6/9/2014 5:30 PM, J. Gomez wrote:
On Monday, June 09, 2014 11:12 PM [GMT+1=CET], Terry Zink wrote:
To repeat, UI/UX design is a specialty requiring extensive
training in cognitive, memory and attention psychology, testing
methodology and, oh yes, computer science.
So I guess we will wait
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
ke it was done for DKIM's Double From
situation with RFC5322 validation checks done at receivers.
Consider it a "to-do" note for when the anticipated official DMARC WG
begins.
Thanks
--
Hector Santos, CTO
http://www.santronics.com
__
On 6/8/2014 1:00 PM, Stephen J. Turnbull wrote:
Phillip Hallam-Baker writes:
> NNTP was designed 30 years ago. We should consider moving on.
> The modern protocol world is JSON/REST
That's off-topic for this list, IMO, and I don't intend to discuss it
unless the moderator(s) make clear that
On 6/8/2014 11:30 AM, Murray S. Kucherawy wrote:
On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj
Only that it goes back to the similar SPF thing regarding dynamic
rejections. So to be consistent for DMARC:
DMARC POLICY A-R Trace Guideline
REJECT --> N/A see 55x reply codes.
QUARANTI
On 6/8/2014 5:13 AM, Vlatko Salaj wrote:
i consider my 3rd party alignment support for DMARC
easy to understand, trivial enough to deploy and
useful enough to cover many use cases, so i would
like to move it to IETF as a, probably, independent
RFC.
does anybody here see interest in helping me ou
As. You have no
control over offline RFC-based store and forward MUAs. The only control you
have is what the backend provides via the 5322 format.
--
Hector Santos
http ://www.santronics.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
I might be interested in remote participation at the next IETF 90
meeting if there are any DKIM/DMARC related meetings scheduled.
I have not seen any announcements for any such DKIM/DMARC related
activity.
--
HLS
___
dmarc mailing list
dmarc@ietf.
Stephen, I hope the DMARC List moderators/chairs recognized your
antagonistic "first strike" responses to concerned comments here. It
isn't helpful.
This is a long time issue and I have been there since day one, since
MARID when all these integrated design concepts and issues began. I
don't r
This idea is repeating the same thing again.
What would "DKIM-Delegate compliant" systems do when the "new
information" is missing? What do you do when there are protocol
faults? What are the protocol faults?
Mr Crocker, you have been leading the DKIM project since day one. You
have always
On 6/4/2014 3:16 PM, J. Gomez wrote:
On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
I prefer to update my software with the above script for our MTA
receiver rather to add logic to rewrite the 5322.From to bypass a
security protocol
Rewriting the Header-From field in
t like the idea 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" wrote:
>> But that is not equivalent to putting non-resolvab
But it does know. It is not legitimate mail per the proposed security protocol.
The problem and conversation should be focused on resolving the 9 years old
mail integration dilemma -- the dearth of resigners not wanting to check for
bad DKIM-secured transactions via a policy layer protocol. Kee
But why would you accept emails from invalid domains in the first
instance?
Because the email is legitimate, of course.
Until it isn't.
The purpose of the ".invalid" TLD was not for bypassing a proposed
security protocol. This is a malicious hack that will ultimately help
break down on
I'm a list software product developer. I believe our list package was
among the
first to implement domains controls with restrictive domains. In our
case, we used the then IETF Proposed Standard ADSP. It followed the
guidelines written in the 2006 DSAP (DKIM Signature Authorization
Protocol) I
On 5/30/2014 5:49 PM, J. Gomez wrote:
Ah, but "just like" is a complete misstatement of the situation.
There's a big difference. Users on a mailing list think of the
poster, not the mailing list, as responsible for the content. So
according to RFC 5322, the poster's mailbox belongs in From:.
R
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
On 5/29/2014 3:09 AM, Murray S. Kucherawy wrote:
On Thu, May 29, 2014 at 12:06 AM, John R Levine 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 two mail provi
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 option
On 5/24/2014 4:10 PM, Matt Simerson wrote:
On May 24, 2014, at 12:50 PM, Hector Santos 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 is mandatory. Reporting
I've begun looking at adding DMARC support into our existing DKIM,
ADSP, ATPS, ASL framework. To explore all this, I converted our
public ADSP/ATPS/ASL Zone Record Creator web-based wizard to use DMARC
with the ATPS/ASL extensions at:
DMARC Policy Zone Record Generator and Test Simulator
On 5/3/2014 12:23 PM, Dave Crocker wrote:
On 5/2/2014 1:05 PM, Fred Baker (fred) wrote:
3. The limitations of DMARC have been well understood, including
by both Yahoo and AOL. There is never any way for the IETF community
to protect against an organization's choosing to apply a protoco
On 5/2/2014 1:09 PM, Douglas Otis wrote:
Dear Hector,
I hope you are willing to review a TPA draft.
Doug, I did go over your drafts in 2009 when it was rev3. I see I
even explored compiling your C code under Windows to create labels:
Directory of M:\rfc\dkim
10/12/2009 10:45 PM
Hi Fred,
We have already did all this. Over the last 9 years, we have produced
all these DKIM related documents:
RFC4686 Analysis of Threats Motivating DKIM
RFC4870 DomainKeys
RFC4871 DKIM (RFC5672.TXT, RFC6376.TXT)
RFC5016 Requirements for a DKIM Signing Practices Protocol
On 4/25/2014 2:16 AM, Vlatko Salaj wrote:
On Thursday, April 24, 2014 8:20 PM, Hector Santos wrote:
Take a look at the 2006 DSAP I-D proposed author domain policy
protocol which provided tags to covered the complete 1st vs 3rd party
boundary conditions for DKIM signing practices:
seems
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 a
On 4/22/2014 3:20 AM, Vlatko Salaj wrote:
On Tuesday, April 22, 2014 1:18 AM, Hector Santos wrote:
I think the DKIM 3rd party resigner issue is the more important issue
at this point.
i hold both are important.
...
i really see no reason why DMARC can't be flexible enough to inclu
On 4/24/2014 12:44 PM, Terry Zink wrote:
On Apr 24, 2014, at 3:46 AM, Hector Santos wrote:
change ADSP to DMARC below at the IETF RFC Status change link.
Technically, it is still almost no deployment, just a few BIG guys!!
Hector
I challenge your assertion that there is "almo
On 4/23/2014 8:59 AM, Michael Storz wrote:
Just saw it in my logs. You find the announcement at
http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/
So much for the theory that DKIM ADSP-like strong policies would never
be used by big operations! And the irony,
On 4/21/2014 6:08 PM, Vlatko Salaj wrote:
On Monday, April 21, 2014 11:32 PM, Hector Santos wrote:
How do you define a 3rd party SPF condition that isn't already defined
and authorized by the 1st party?� IOW, by virtue of the 1st party
adding the 3rd party information into a SPF recor
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 fo
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 domain
wrote:
Not yet, but that us on the hit list for us.
On Wednesday, February 26, 2014, Hector Santos wrote:
Is there is a plug and play 32 bit and/or 64 bit Windows version?
On 2/26/2014 1:46 PM, Wiley, Glen wrote:
Verisign and NLnet Labs are pleased to announce the first beta release
(0.1.0
Is there is a plug and play 32 bit and/or 64 bit Windows version?
On 2/26/2014 1:46 PM, Wiley, Glen wrote:
Verisign and NLnet Labs are pleased to announce the first beta release (0.1.0) of an
open source implementation of the getdns API specification. The project's home page
is at http://getd
On 2/7/2014 10:31 AM, John Levine wrote:> An acquaintance notes that
many of his clients still have t=y in their
> DKIM records. Do any DKIM implementations pay any attention to it?
>
> RFC 6376 still says:
>
>y This domain is testing DKIM. Verifiers MUST NOT treat messages
>
Youtube URL.
http://www.youtube.com/watch?v=2UWRuIXXzYs
On 10/13/2013 3:16 PM, Brian E Carpenter wrote:
I know we don't normally do movie plugs on this list, but anyone
who's planning to attend the technical plenary in Vancouver
could do worse than watch "Terms and Conditions May Apply".
It c
On 10/3/2013 6:25 PM, Douglas Otis wrote:
On Oct 3, 2013, at 1:37 PM, Barry Leiba wrote:
To both Doug and Hector, and others who want to drift in this direction:
As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we d
Please accept my apology as I do not mean to be disrespectful. I find
it impossible to separate all design considerations that are involved
in this decision you are requesting us to consider regarding a near
7-8 years DKIM + POLICY investment.
DKIM originated with POLICY support built-in and i
On 10/3/2013 1:51 PM, Douglas Otis wrote:
Dear Hector,
Indeed, more should be said about underlying reasons. The reason for abandoning ADSP is
for the same reason few providers reject messages not authorized by SPF records ending in
"-all" (FAIL). Mailing-List software existed long before e
I agree, the problem IMV is the illusion that DMARC will replace it
has some domains has already done by switching their strong exclusive
mail operations declaration from _ADSP TXT record policy to a _DMARC
policy. Like FACEBOOK.COM. The REJECTING/DISCARD concept is still the
same and active,
On 10/3/2013 11:11 AM, Scott Kitterman wrote:
Alessandro Vesely wrote:
On Wed 02/Oct/2013 16:52:38 +0200 John Levine wrote:
The IESG has received a request from an individual participant to
make
the following status changes:
- RFC5617 from Proposed Standard to Historic
The supporting doc
On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote:
On Wed, Oct 2, 2013 at 7:41 AM, The IESG wrote:
The IESG has received a request from an individual participant to make
the following status changes:
- RFC5617 from Proposed Standard to Historic
The supporting document for this request can be
[
https://issues.apache.org/jira/browse/CB-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13771966#comment-13771966
]
Hector Santos commented on CB-4391:
---
Somebody know a method to put a color backgroun
On 9/17/2013 4:52 PM, Yoav Nir wrote:
Having an IETF identity is OK if all you ever publish is in the IETF. Some of
our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a
few publish Academic papers. Using the same identifier for all these places
would be useful, and
On 9/17/2013 3:24 PM, Melinda Shore wrote:
On 9/17/13 11:14 AM, Michael Tuexen wrote:
For example
http://www.ietf.org/rfc/rfc3237.txt
has 7 authors. I know that at least 4 affiliations have changed
and at least you can't reach me anymore via the given e-mail
address or telephone number.
This i
On 9/17/2013 1:55 PM, Michael Tuexen wrote:
On Sep 17, 2013, at 7:48 PM, Scott Brim wrote:
On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
wrote:
I was always wondering the authors can't get an @ietf.org address, which is
listed
in the RFC and is used to forward e-mail to another account.
+1 Thank you for your input. Seems to me to be a conflict of
interest issue. I support the basic concept but why not use a IETF
registry instead? Solves several of the conflict of interest
concerns, including about 3rd party entities disappearing, losing
support, etc.
--
HLS
On 9/17/2013
On 9/16/2013 3:07 PM, David Morris wrote:
On Mon, 16 Sep 2013, Melinda Shore wrote:
On 9/16/13 6:49 AM, Dave Cridland wrote:
That's not to say you can't put any particular URI against your name in
an RFC, mind, but I'd be rather hesitant to leap at mandating a
registration procedure for auth
On 9/12/2013 3:28 PM, Dave Crocker wrote:
>
> There seems to be a pattern that has developed, of demanding that
> failure mean literally no adoption. It doesn't mean that. It means
> that it has no community traction. ADSP more than qualifies on the
> pragmatics of failure.
>
> d/
>
The pragmat
This will require a substantial review before any change of status is
done and should be done as part of WG working on Domain Policies.
There is already substantial work with ADSP and APIs implemented and
deployed. We continue to get world wide usage of our ADSP zone record
generator wizard:
On 9/9/2013 4:09 PM, Brian E Carpenter wrote:
> On 10/09/2013 01:58, Ted Lemon wrote:
> ...
>> Seriously, this perfectly illustrates the reason why PGP hasn't seen
>> widespread deployment: it doesn't address a use case that anybody
>> understands or cares about,
>
> True story: Last Saturday e
On 9/6/2013 11:04 PM, Ted Lemon wrote:
On Sep 6, 2013, at 10:35 PM, Melinda Shore wrote:
I actually don't think that pgp is likely to be particularly
useful as a "serious" trust mechanism, mostly because of
issues like this.
It's not at all clear to me that "serious" trust mechanisms should b
On 9/6/2013 10:35 PM, Melinda Shore wrote:
One of the useful things that PKI provides is some agreement,
at least, about what we expect from certification authorities
and what it means to issue and sign a certificate. That is
to say, the semantics are reasonably well sorted-out, which is
not th
Along with the other recent drafts for streamlining the RFC process, I
get the feeling even this new drafting on conduct is simply going to
be a new rubber stamping tool to shut down the process of due diligent
engineering discussions, required cross areas reviews, including
increasing conflict
On 8/30/2013 4:09 PM, Andrew Sullivan wrote:
On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:
archives of the Repute WG to find or extract these very real and
practical integration considerations. The document should have
these general considerations summarized.
But your
On 8/30/2013 10:46 AM, Tony Hansen wrote:
The document describes a model for reputation services, particularly those
being produced by the Repute WG. It follows the recommendations of RFc4101 for
describing a protocol model, which requires answers to 1) the problem the
protocol is trying to
have these general
considerations summarized.
Thanks
On 8/30/2013 3:20 PM, Andrew Sullivan wrote:
On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
For example, DKIM-REPUTE product designers would need to consider
SPF reputons product models. Simple text as follows can resolve
John,
I don't think it would of been fun designing and testing a text-based
hosting protocol manually with your terminal/telecommunication/telnet
client "New Line Mode" (add LF to CR) option disabled or server text
responses only issue CR or LF.
It would of been very hard or confusing to do
Scott Kitterman wrote:
PS: I am not trying to change anything about the PTR 4408BIS status.
Just pointing out that a change was made that does touch base with
operations and thus not supporting (or delaying, forever) this part of
4408BIS is highly possible.
You might change what you recommend
Scott Kitterman wrote:
Hector Santos wrote:
I should add:
5- Deprecate PTR by removing PTR publishing support
We won't advocate this because for our small to mid size market, this
is the lowest cost setup for them - using a PTR. For all our domains,
we use PTR as well. No ne
Hector Santos wrote:
Phillip Hallam-Baker wrote:
Putting a statement in an RFC does not mean that the world will
automatically advance towards that particular end state.
Thats correct. No one is forced to support RFC 4408bis. From my
perspective, there are four basic major changes to BIS
Phillip Hallam-Baker wrote:
On Fri, Aug 23, 2013 at 3:46 PM, manning bill wrote:
the question is not that "nobody" checks type 99, the question is
"is the rate of adoption
of type 99 -changing- in relation to type 16?
As John pointed out, support for checking type 99 has dec
Dave Crocker wrote:
On 8/23/2013 11:06 AM, Scott Brim wrote:
We don't have to be like the ones we all know who sneer at anyone
presuming to get in the way of their code going into production.
Since this is such a fundamental point, I'm sending this reply to
emphasize:
The concern I exp
Andras Salamon wrote:
On Thu, Aug 22, 2013 at 11:53:29PM -, John Levine wrote:
If you think it's important to move it to full standard, why don't you
do somthing about it? A quick look suggests that 3597 meets the
requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard
to per
Hi SM,
Besides the SPF type issue, I believe there are still a number of
integrated protocol issues to address. How does the following RFCs
play into SPFBIS output, the SPF type and the overall BIS document?
Should RFC4408BIS update any of these documents?
[1] RFC4405 SUBMITTER SMTP Servic
Scott Kitterman wrote:
On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote:
What I want the IESG to add a note to the document is that says something
like the following: "The retirement of SPF from specification is not to be
taken that new RRtypes can not be used by applications, the
Eliot Lear wrote:
Patrik,
First, I appreciate that you and Dave are bringing data to the table.
However, in this case, it is not in dispute that queries are happening.
What *is* in dispute is whether there are answers. I must admit I am
having a difficult time understanding the logic, even
On 8/20/2013 1:12 AM, S Moonesamy wrote:
There is a message from the Responsible Area Director at
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which
might shine some light about that part of the charter.
Both RR Type 16 and RR Type 99 are in use on the Internet. Tony Han
501 - 600 of 2714 matches
Mail list logo
