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
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
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 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
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/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 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 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
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
.
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
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
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
. 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
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
On 7/25/2014 6:41 PM, Mark Andrews wrote:
In message 53d2dbec.6060...@isdg.net, Hector Santos writes:
We will need to tweak the code or the retry frequency table for this
particular socket error, in this case 10061. To optimize, we will
need to specifically look for three conditions
On 7/25/2014 1:18 PM, Kevin Darcy wrote:
I remain skeptical that the methodology in the draft, as written,
requires no code changes, since I just performed a private experiment
with a recent version of sendmail, and delivery failed in a
spectacularly ugly way that made it appear much more like
On 7/23/2014 7:57 AM, Masataka Ohta wrote:
David Conrad wrote:
Since I mentioned it and some folks said where is it?:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
Masataka Ohta
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 -
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
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
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
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
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
.
--
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/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
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
.
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 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
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/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/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
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 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
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/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
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 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
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
wrote:
Not yet, but that us on the hit list for us.
On Wednesday, February 26, 2014, Hector Santos hsan...@isdg.net 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
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
from
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
On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote:
On Wed, Oct 2, 2013 at 7:41 AM, The IESG iesg-secret...@ietf.org 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
On 10/3/2013 11:11 AM, Scott Kitterman wrote:
Alessandro Vesely ves...@tana.it 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
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 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
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
On 10/3/2013 6:25 PM, Douglas Otis wrote:
On Oct 3, 2013, at 1:37 PM, Barry Leiba barryle...@computer.org 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
[
https://issues.apache.org/jira/browse/CB-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771966#comment-13771966
]
Hector Santos commented on CB-4391:
---
Somebody know a method to put a color background
+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/17/2013 1:55 PM, Michael Tuexen wrote:
On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote:
On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
michael.tue...@lurchi.franken.de wrote:
I was always wondering the authors can't get an @ietf.org address, which is
listed
in the
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
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/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 pragmatics of
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 evening I
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
On 9/6/2013 11:04 PM, Ted Lemon wrote:
On Sep 6, 2013, at 10:35 PM, Melinda Shore melinda.sh...@gmail.com 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
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
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
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
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
Phillip Hallam-Baker wrote:
On Fri, Aug 23, 2013 at 3:46 PM, manning bill bmann...@isi.edu 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
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
Scott Kitterman wrote:
Hector Santos hsan...@isdg.net 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
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
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
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
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,
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
On 8/19/2013 7:42 PM, S Moonesamy wrote:
At 14:10 19-08-2013, Hector Santos wrote:
I'm having a hard time with both sides of the argument, especially
the supposed existence of an interop problem which seems to only
highlight how to procedurally stump the SPF type advocates with a
error
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
Hi,
I'm having a hard time with both sides of the argument, especially the
supposed existence of an interop problem which seems to only highlight
how to procedurally stump the SPF type advocates with a error
correction standpoint. What is that error by the way?
I don't believe there was
On 8/4/2013 4:35 PM, Pawel Lesnikowski wrote:
There are few details I'd like to clarify.
Body hash for this message is correctly computed by the sender.
Entire signature of this message in fact valid - this is why Port25,
Gmail, and Mail.dll validate DKIM signature with 'pass' result.
The
Overall, I think the IETF has a marketing problem addressing its #1
customer base - electronic participants.
I was somewhat hoping to see more done in the mentor area of assisting
electronic participants. Of coarse, this sort of electronic mentoring it
could include an end goal to get folks
On 7/13/2013 2:20 PM, Yoav Nir wrote:
So finding your site is not that difficult for first-timers. But regardless,
the people who type in addresses or DNS names in full are rare and far between.
Agreed. Just to see again, I tried it on my wife's new computer with
Chrome and it showed:
On 7/14/2013 9:53 AM, Yoav Nir wrote:
On Jul 14, 2013, at 4:34 PM, Hector Santos hsan...@isdg.net wrote:
On 7/13/2013 2:20 PM, Yoav Nir wrote:
So finding your site is not that difficult for first-timers. But regardless,
the people who type in addresses or DNS names in full are rare
All the discussion details are overwhelming but I do seem to feel there
is a marketing and branding problem especially when it comes to
searching a domain at the USER DATA ENTRY LEVEL, i.e. slow keyboard input.
For example, I own WINSERVER.COM. Try typing WINSERVER in google (for
the first
On 7/13/2013 11:27 AM, Noel Chiappa wrote:
From: Livingood, Jason jason_living...@cable.comcast.com
FWIW, I think for most larger companies with multi-billion dollar
revenues streams it is less about the up-front fees to apply
operationalize a gTLD than the long term
On 7/10/2013 5:17 PM, Josh Howlett wrote:
Day passes have nothing to do with it.
I disagree. Day passes encourage the notion that it's normal to
parachute into the IETF to attend a single session. I think that the
IETF's strength is that we don't totally compartmentalise work items.
I am
On 7/10/2013 8:04 PM, Hui Deng wrote:
Hello all
We submitted two drafts to help people here to correctly call chinese
people names:
http://tools.ietf.org/html/draft-deng-call-chinese-names-00
http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00
Fantastic. Short and sweet!
well, for a moment, I did have to think about this draft being a joke or
not. But the acronym was perfect. :)
On 7/3/2013 1:30 PM, Warren Kumari wrote:
On Jul 2, 2013, at 1:58 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote:
This sounds a lot like prefetch in unbound, and the
On 7/2/2013 10:11 AM, Murray S. Kucherawy wrote:
On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann
mich...@talamasca.ocis.net wrote:
On Mon, 1 Jul 2013, Alessandro Vesely wrote:
Well, not really. MAIL FROM: is only visible after delivery, so to
avoid dangling signatures one should
I like the idea. A fews ago we needed to write a local cache for our
total system framework to create a single source API query for all of
our apps within the framework using DNS. The cache database was
prepared with a query frequency field (QFF) with the idea in the future
to come up with
I believe this is all part of improving the IETF Electronic Diversity
picture. Just like we have to deal with greater people personal
globalization diversity issues, there is also greater technology and
legal diversity issues to deal with. So many tools, so many languages,
so many OSes, so
What language, OS? There are plenty of rich hashing/encrypting C/C++
libraries out there. Windows has CAPI, even OPENSSL has these libraries.
On 6/27/2013 11:49 AM, Dearlove, Christopher (UK) wrote:
RFC 6234 contains, embedded in it, code to implement various functions,
including SHA-2.
Ok, other than time, it should be easy to extract, clean up and cross
your fingers that it compiles with your favorite C compiler. But I
would write to the authors to get the original source. Or google:
C source crypto libraries API hashing functions
among the first hit:
I want to know more what it translates to as a technical specification
for CODING. To me, it means this:
o Authorization Lift Time
[X] Send Notification
Time to send: __4__ mins (default)
The problem as I experienced thus far is whether one MUST IMPLEMENT this
protocol
Sounds like an never ending loop. 2119 is an RFC too and thus written in
RFCish as well.
To me, it only matters in terms of implementation - should we waste time
and money on implementing a SHOULD/RECOMMENDED feature? Is it required
to be coded? Can it be delayed, for version 2.0? Is it
that last that long.
On Jun 25, 2013, at 8:13 PM, Hector Santos hsan...@isdg.net wrote:
I want to know more what it translates to as a technical specification for
CODING. To me, it means this:
o Authorization Lift Time
[X] Send Notification
Time to send: __4__ mins (default
On 6/24/2013 8:39 AM, John C Klensin wrote:
--On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker
hal...@gmail.com wrote:
They are not synonyms
Lets go back to 1980:
Implementations SHOULD support DES
vs
RECOMMENDED encryption algorithms: DES, IDEA
Actually, that is the point. The
401 - 500 of 2144 matches
Mail list logo
