On Dec 22, 2005, at 12:06 PM, Frank Ellermann wrote:
Douglas Otis wrote:
DKIM should be seen as aspect of the SMTP transport.
It could also work for news if we get the FWS canonicalization right.
Agreed. The presents of the signature should not impose limitation
upon what content
On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote:
>
> Far from trying to "leave only one authorization method," the DKIM
> effort is an attempt to show, by example, how an arbitrary number of
> such methods might eventually be elaborated and standardized.
There is danger viewing
On Dec 27, 2005, at 7:33 AM, Nathaniel Borenstein wrote:
I'm sorry, the "authorization method" was an echo of the term used
in the mail I was replying to (which is why it was in quotes). I
was really trying to generalize to a whole range of technologies
without making my wording too awkw
On Dec 27, 2005, at 5:20 PM, Frank Ellermann wrote:
Douglas Otis wrote:
The response was specifically against the use of "authorization."
With respect to SPF/Sender-ID or SSP, these are indeed email-
address "authorization" schemes.
There's no "burden shif
On Fri, 2005-12-30 at 09:35 +0100, Frank Ellermann wrote:
> Douglas Otis wrote:
>
> > This back-scatter problem can be resolved by implementing
> > BATV at the cost of two additional wafer-thin packets.
> "Simplified SES" (or whatever BATV is) is _more_ restricti
On Jan 1, 2006, at 8:35 AM, John C Klensin wrote:
--On Sunday, 01 January, 2006 04:35 + John Levine
<[EMAIL PROTECTED]> wrote:
I hope the message here is not that we should restrict ourselves
to developing technology that is idiot-proof, since a sufficiently
determined idiot, of which
On Dec 31, 2005, at 10:31 PM, Frank Ellermann wrote:
Douglas Otis wrote:
The BATV draft seems to be a good start. Perhaps it can be
further simplified. Could this satisfy both camps?
Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or
something else ? For the former I&#
On Mon, 2006-01-02 at 10:58 -0500, Tony Hansen wrote:
> This thread was begun by the last call on the chartering of DKIM.
> Can we please get back to the question of chartering DKIM?
The concern raised was not specifically in regard to the base DKIM
draft. There was concern with respect to the u
On Mon, 2006-01-02 at 06:41 +0100, Frank Ellermann wrote:
> Douglas Otis wrote:
>
> AFAIK it's a way to check if mail claiming to be from [EMAIL PROTECTED]
> was originally sent from [EMAIL PROTECTED] - if that's correct nothing is
> wrong with the idea so far, domain y
On Mon, 2006-01-02 at 22:27 +, John Levine wrote:
> PDF is a fine display format, but it is a rather poor editing format
> since it's hard to do any more with PDF (even PDF/A) than either to
> print it or to extract the text from it. XML on the other hand is a
> putrid display format but it i
On Jan 4, 2006, at 9:59 AM, Dave Crocker wrote:
E> AS I understand it the concern is that people who don't use DKIM
will eventually not be able to send e-mail to people who are using
it. I'm not sure that this is something that people should be
concerned about, indeed, the logic of this kin
On Jan 5, 2006, at 11:31 AM, John Levine wrote:
Quite frankly, I believe we can address the second step (which of
the requirements are not met today?) with a firm "none."
One is that ASCII doesn't permit adequately beautiful pictures. If
that's the problem to be solved, it seems to me tha
On Jan 10, 2006, at 5:47 PM, Dave Crocker wrote:
Lucy, I suspect that they merely were making a spelling error,
since I'm sure they were referring to folk who are truly essential,
and therefore qualify as linch pins...
I have never heard of a linching party. RFCs filled with base64
enc
On Jan 11, 2006, at 1:52 PM, John C Klensin wrote:
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
<[EMAIL PROTECTED]> wrote:
Your knowledge is apparently incomplete. The RFC Editor has been
actively experimenting with using xml2rfc for publication, and we
have been passing our p
On Jan 13, 2006, at 12:07 PM, Dave Crocker wrote:
What is important is not the files used to tailor the production
service, but the prevalence of expertise and tools for that service.
In reality, nroff expertise is isolated in a tiny community. In
reality, xml expertise has become global.
On Jan 25, 2006, at 2:08 PM, Harald Tveit Alvestrand wrote:
We had a discussion on this back in May 2003, and I created a
mailing list for it called "ietf-moderation" - you can subscribe to
the list by http://eikenes.alvestrand.no/mailman/listinfo/ietf-
moderation, or the usual -request spi
,
|1.2. Document Structure
|...
|
| The sections dealing with attacks on DKIM each begin with a table
| summarizing the postulated attacks in each category along with their
| expected impact and likelihood. The following definitions were used
| as rough criteria for scoring the attacks:
|
|
Sorry about getting this wrong twice it would appear.
-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Sat, 2006-06-10 at 09:17 +0200, Brian E Carpenter wrote:
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt
,---
|The three possible ways forward are:
|
| 1. Agree that, apart from day to day efforts to improve efficiency,
| t
On Sun, 2006-06-11 at 09:04 -0400, Keith Moore wrote:
>
> The general circumstances under which IETF has trouble designing new
> protocols are either or both of these: 1. When there are substantial
> conflicts between major industry players about strategic direction in
> that area. 2. When the
On Sun, 2006-06-18 at 22:05 -0700, C. M. Heard wrote:
> [ follow-ups to IETF discussion list please]
>
> Of the three possible ways forward suggested by this draft, I think that
> the only one that's likely to get done is this one:
>
>1. Agree that, apart from day to day efforts to improve e
On Jun 27, 2006, at 8:48 PM, Keith Moore wrote:
I also believe that creating an authentication system that favors
large domains over small ones, and inflexible signing policy over
flexible signing policy, is bad for society. The trick is getting
a balance between these. Some of my conce
On Jul 13, 2006, at 3:25 PM, Eliot Lear wrote:
We are in this position because we are not today documenting
existing practice, having not properly understood the lack of
desire to do what you class as "minor amount of work".
The SRD approach generates Name.Serial references to sets of
do
On Jul 14, 2006, at 9:59 AM, C. M. Heard wrote:
Very well said. As I said in my message of 18 June, my advice
would be to make a relatively minor set of clarifications to BCP 9
(RFC 2026) and move on. It would also be OK for newtrk to refocus
on its original charter of simplifying the s
On Jul 21, 2006, at 8:27 AM, Dave Crocker wrote:
David Harrington wrote:
Why not start everything at Experimental, and if it gains market
success then it moves to Full.
why not make the smallest change we can, rather than alter the
existing, basic mechanism for entering standards track (a
On Sat, 2006-07-22 at 06:51 -0700, todd glassey wrote:
> The question as to why that initiative's process was stalled would
> have to be answered to be fair. One would have to take into
> consideration whether the underlying technologies were the issue,
> those undertaking the effort abandoned it,
On Jul 24, 2006, at 8:06 AM, Todd Glassey wrote:
On Jul 24, 2006, at 7:24 AM Douglas Otis wrote:
The completion of documents, and the closing of WGs remains within
the competence of the IETF. Beyond describing the intended use
and the vetting initially achieved, there is little benefit
On Oct 3, 2006, at 4:00 AM, Brian E Carpenter wrote:
Brian Carpenter has written draft-carpenter-rfc2026-
critique-02.txt which does exactly that, and he has repeatedly
solicited comments on it. If you think that it would be helpful
to have it published as an informational RFC before under
On Oct 7, 2006, at 10:42 AM, Lakshminath Dondeti wrote:
At 01:42 AM 10/7/2006, Harald Alvestrand wrote:
Many universities require their students to buy their own laptops,
but prohibit certain types of activity from those laptops (like
spamming, DDOS-attacks and the like). They would love
On Tue, 2006-10-10 at 20:01 -0700, Narayanan, Vidya wrote:
> I am rather confused by this attempt to make NEA fit into some kind of
> a network protection mechanism. I keep hearing that NEA is *one* of a
> suite of protocols that may be used for protecting networks. Let's dig
> a bit deeper into wh
On Oct 12, 2006, at 2:27 PM, Darryl ((Dassa)) Lynch wrote:
Am I mistaken or is NEA intended to be a compliance check before a
node is allowed onto the network?
It seems impractical to specify system requirements or expect a
suitable examination be done realtime prior to obtaining access.
On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote:
I would think that five or six values are appropriate:
1. Vendor name (string)
2. Vendor engine version (integer)
3. Vendor virus definitions version (integer)
4. Enabled? (binary)
5. Buggered? (binary)
6. Other gobbledigook the vendo
On Tue, 2006-11-21 at 21:28 -0800, Dave Crocker wrote:
> The MX record was, in fact, a great leap forward (after a number of
> false starts.) I can tout its success vigorously because I had
> nothing to do with it but have always marveled at how profound its
> benefit has been. Indeed I'd be hap
On Nov 22, 2006, at 9:22 AM, Paul Robinson wrote:
All DKIM gets you fundamentally is SPF with the ability for an MTA
to determine "you are who you say you are, but some people think
you're a prick". That doesn't help as much as you think it will.
While greatly reduces false-positive filter
On Nov 22, 2006, at 7:42 AM, Pekka Savola wrote:
On Tue, 21 Nov 2006, Keith Moore wrote:
DNS is getting very long in the tooth, and is entirely too
inflexible and too fragile. The very fact that we're having a
discussion about whether it makes more sense to add a new RR type
or use TXT
On Nov 27, 2006, at 7:48 AM, John C Klensin wrote:
On the other hand, if one is going to have a network in which all
resources are publicly available and unambiguous without prior
negotiations between each client and server and in which one
doesn't want to allow the time and resources for
On Nov 28, 2006, at 4:31 PM, Emin Gun Sirer wrote:
Stephane & Phillip,
I'm thinking of writing a short report that summarizes the
invaluable discussion here and beefing up the system sketch. I
think we now agree that it is possible to have multiple operators
manage names in a single, sha
On Nov 29, 2006, at 8:53 AM, Hallam-Baker, Phillip wrote:
I don't think that would be the only patent you would need
Here is a somewhat more complete list:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01076.html
-Doug
___
Ie
On Fri, 2007-01-12 at 00:42 -0500, Barry Leiba wrote:
> Eliot Lear said...
> > I'd have to go further than what you wrote. I believe the document
> > should explicitly discuss interactions with DKIM, as that document is in
> > front of the IESG at this time for approval as a Proposed Standard.
On 9/9/11 6:33 PM, Thomas Narten wrote:
I am surely going to regret posting, because I have largely tuned out
of this discussion due to the endless repetition, etc. I am not
supportive of the current document, because I don't think it solves
anything. To me, it smack a bit of "change for changes
Dual-Stack Lite, RFC6333 that makes these conversions using a single NAT
by combining IPv6 address space with a common 192.0.0.0/29. This
approach does not suffer from scaling limitations other than
constraining access points to 6 IPv4 interfaces where IPv6 provides the
native IP protocol. W
On 10/4/11 9:09 AM, J.D. Falk wrote:
"About MAAWG
>>
>> MAAWG [1] is the largest global industry association working against
>> Spam, viruses, denial-of-service attacks and other online
>> exploitation. Its' members include ISPs, network and mobile
>> operators, key technology
On 9/4/11 7:23 AM, todd glassey wrote:
There are any number of IETF RFC's which were published and then
accepted in the community under the proviso 'that they would become
IETF standards' which in many instances they do not. Further many of
them are abandoned in an uncompleted mode as standards
On 10/4/11 11:43 PM, Eliot Lear wrote:
For the record, I tend to dislike pollution of the RFC series with PR
blurbs as well. This having been said, I would be far more interested
in a discussion about the actual substantive content of the document.
Eliot
Eliot,
Thank you for asking.
In addit
On 11/15/11 10:26 AM, Frank Ellermann wrote:
On 15 November 2011 18:56, Noel Chiappa wrote:
Gee, I don't see my OS listed on that page. What do I do know?
Let DuckDuckGo tell you what it knows about "Powerpoint viewer ubuntu".
FWIW I like ppt(x) better than pdf, "anything pdf" is huge. For
On 11/17/11 9:17 AM, Robinson Tryon wrote:
On Wed, Nov 16, 2011 at 8:56 PM, Melinda Shore wrote:
On 11/16/2011 01:45 PM, Christian Huitema wrote:
Just saying, but if we want to ensure that presentations are readable 50
years from now, and do not embed some kind of malicious code, we might stic
On 11/17/11 4:14 PM, Randy Bush wrote:
PDF/a is something browsers and natively by different OSs that can
directly display. When submitting formats that are not PDF/a, convert
and automatically link to the converted output with a prompt requesting
approval.
http://www.digitalpreservation.gov/fo
I support adoption of dkim-atps as an experimental RFC. It would have
been clearer to use the term Author-Domain rather than Author. Clearly,
it is not the Author offering Authorization.
-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
On 1/5/12 9:13 AM, Dave CROCKER wrote:
On 1/5/2012 7:01 AM, Dave Cridland wrote:
> On Thu Jan 5 14:48:54 2012, Dave CROCKER wrote:
>> If protocol corresponds with program or algorithm, then what is
>> the communications term that corresponds to process?
>>
>> It's tempting to say "port number",
anuals
reading revolutionary literature
writing program code
watching attack coverage
looking at stadium seating maps
--might be a terrorist.
Call (888) 705-JRIC and mention "redneck". :^)
Regards,
Douglas Otis
___
Ietf mailing list
Ie
nly
tangible data represents the source IP address made available by LSN
services. Both of which touch upon the changes you recommend. At some
point, authentication reporting also needs to be updated as well.
Regards,
Douglas Otis
tems for
the purpose of subsequent isolation. Attempts to track ports in the
presence of LSN overlooks the highly transitory translations. However,
the LSN scheme provides a means to determine the source IP address.
Regards,
Douglas Otis
The IP address of the SMTP client can be found within an ASN to uncover
a network provider. Helos might verify, which may then also identify a
domain used by a network provider's customer. Of course the host names
within the reverse PTR may also verify as well. Identifying the network
provider i
On Sun, 2007-02-18 at 12:51 +0100, Harald Tveit Alvestrand wrote:
> On second thought, I know that you know this field well enough that I
> *must* have misunderstood your message.
>
> Could you please restate your missive in such a way that it's clear:
>
> - What problem you think the IETF can h
On Sun, 2007-02-18 at 13:20 -0800, Douglas Otis wrote:
---
The safe way forward would be to demand that security be considered
first and foremost. In a store and forward scheme, start the chain of
identification from the transmitting entity, where the originating
entity is then able to
On Feb 21, 2007, at 4:31 AM, Brian E Carpenter wrote:
On 2007-02-18 13:46, Tony Finch wrote:
On Sun, 18 Feb 2007, Harald Tveit Alvestrand wrote:
If this was effective, blacklists would have solved the spam
problem.
They are 90% effective
You what? Which Internet would that be?
Blacklists
On Feb 22, 2007, at 1:41 AM, Brian E Carpenter wrote:
The level of bulk unsolicited messages exceed more than 90% of the
volume in many cases
I estimate 95% of moderated non-member mail that hits the IESG list
to be b.u.m.
Much that slips past somewhat static (and not very effective) lis
On Mar 1, 2007, at 9:57 AM, John C Klensin wrote:
I continue to believe that, until and unless we come up with models
that can satisfy the underlying problems that NATs address in the
above two cases and implementations of those models in mass-market
hardware, NATs are here to stay, even i
On Mar 4, 2007, at 11:11 AM, Brian E Carpenter wrote:
But irrelevant - the problems that NAT causes, and that having
sufficient address space (a.k.a. IPv6) solves, are orthogonal to
security. That is the whole point in this thread.
Of course stateful firewalls and NATs offer protection, wh
On Mar 5, 2007, at 5:51 PM, Hallam-Baker, Phillip wrote:
Quite, the technical part of my proposal is essentially a
generalization of the emergent principle of port 25 blocking. While
people were doing this before SUBMIT was proposed the SUBMIT
proposal made it possible to do so without neg
On Mar 6, 2007, at 1:39 PM, Jeff Young wrote:
For better or worse, the "centralized means of control" you mention
may well come in the form of the latest IPTV networks being built
by large telco providers. As telco battles cable for couch
potatoes, they've realized that mucking with telev
On Mar 7, 2007, at 9:01 AM, John C Klensin wrote:
It is true that I tend to be pessimistic about changes to deployed
applications that can't be "sold" in terms of clear value. I'm
also negative about changing the architecture to accommodate short-
term problems. As examples of the latter,
On Mar 7, 2007, at 3:00 PM, Harald Tveit Alvestrand wrote:
Here I was thinking that the DNS needs to be an useful name lookup
service for the Internet to function, and now PHB tells me it's a
signalling layer.
Either I have seriously misunderstood the nature of "signalling",
seriously mi
On Mar 8, 2007, at 2:13 AM, Brian E Carpenter wrote:
On 2007-03-08 02:06, Hallam-Baker, Phillip wrote:
OK I will restate. All connection initiation should be exclusively
mediated through the DNS and only the DNS.
Would that include connections to one's DHCP server, SLP server,
default gat
On Mar 9, 2007, at 2:41 AM, Brian E Carpenter wrote:
Phill,
I'm not playing with words. The style of 'connection' involved in a
SIP session with proxies is very different from that of a classical
TCP session or a SOAP/HTTP/TCP session, or something using SCTP for
some signalling purpose.
On Mar 9, 2007, at 10:17 PM, David Morris wrote:
In the low end bandwidth space I play, a extra 192 bits on every
packet is significant to end user performance. As others have
noted, it seems like the fairly effective anti-spam technique of
associating reputations with network addresses wi
On Apr 11, 2007, at 4:54 AM, Brian E Carpenter wrote:
Ted,
Well, if IPR owners don't actually care, why are they asking
people to
send a postcard? It would seem to be an unnecessary administrative
burden for the IPR owners, yes?
My assumption is that they care if the party that fails to
On May 15, 2007, at 10:16 AM, John Leslie wrote:
I did some research, and found the following mentions of LWSP:
rfc0733 obs-by rfc0822
rfc0822 defs LWSP-char = SPACE / HTAB obs-by rfc2822
rfc0987 refs rfc0822
rfc1138 refs rfc0822
rfc1148 refs rfc0822
rfc1327 refs rfc0822
rfc1486 refs rfc08
On May 15, 2007, at 1:10 AM, Clive D.W. Feather wrote:
Tony Hansen said:
I share your concerns about removing rules that are already in
use --
that would generally be a bad thing. However I'm interested in the
consensus around whether a warning or a deprecation statement
would be a
good
On May 16, 2007, at 5:19 AM, John C Klensin wrote:
Doug, John,
It seems to me that we have two separate issues here (I'm not even
going to go so far as "problems"):
(1) Some documents have used the term LWSP in a way that is not
strictly conformant with the definition in the ABNF docume
In response to off-line comments,
Although LWSP has been placed within "core rules", LWSP is _not_ a
rule core to the ABNF definition of ABNF. LWSP is _not_ essential.
Deprecating this macro does _not_ impact the definition of ABNF.
This macro can be deprecated to ensure it will not pro
On May 16, 2007, at 5:47 PM, John C Klensin wrote:
I would
have no problems if that note made it clear that use of LWSP in a
context in which it could end up on a line by itself (in a context
in which "lines" are significant) can be particularly problematic.
I see those options as very di
On May 17, 2007, at 9:29 AM, Tony Finch wrote:
It would help future users of ABNF if the specification did not
implicitly endorse syntax that we now know to be unwise.
+1
Especially when not germane to ABNF definitions. The construct
should stand on its own when used. Perhaps labeled as
On May 17, 2007, at 2:27 PM, Dave Crocker wrote:
I think you are assuming a more constrained discussion than what
I've been seeing on this thread. The thread has discussed
everything from removing the rule, to redefining it, to declaring
it "deprecated", to adding some commentary text.
This draft lays out what is destine to become email acceptance
criteria based upon DKIM signing practices. DKIM depends upon public-
key cryptography and uses public keys published under temporary
labels below a _domainkey domain that must be at or above the
identity being signed to meet "s
I have been asked to rewrite this for those not familiar with DKIM.
I'll try to keep it short.
The SSP requirements draft defines what is expected of SSP resource
records. Specifics are then to be defined within an upcoming SSP
draft. Simply stated, SSP DNS resource records are seen as
On Jul 2, 2007, at 8:14 AM, Hallam-Baker, Phillip wrote:
My point here is that the principal objection being raised to NAT,
the limitation on network connectivity is precisely the reason why
it is beneficial.
There is no other device that can provide me with a lightweight
firewall for $
On Jul 2, 2007, at 11:06 AM, John C Klensin wrote:
Of course, almost none of the issues above are likely to go away,
or even get better, with IPv6... unless we make some improvements
elsewhere. And none of them make NAT a good idea, just a
"solution" that won't easily go away unless we h
On Jul 3, 2007, at 8:34 AM, Joel Jaeggli wrote:
Arnt Gulbrandsen wrote:
IMNSHO, the sensible time is to do it when the relevant RIR runs
out of addresses. I'm sure the IETF can get a couple of thousand
IPv4 addresses for temporary use even years after that time, but
it would seem a litt
There is weakness in Mailman being exploited to send spam, and this
is affecting IETF mailing lists. A response "as-if" a DSN per RFC
3464 should help curtail this exploit.
-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/li
On Jul 3, 2007, at 3:44 PM, Hallam-Baker, Phillip wrote:
The point about eating dog food is not to order the salespeople to
eat the dog food or else. If the salespeople refuse to eat the dog
food you are meant to go back and fix it. The approach being
suggested here is to tell the salespeo
On Thu, 2007-07-05 at 09:29 +0200, Brian E Carpenter wrote:
> I posted draft-carpenter-rfc2026-changes-00.txt at
> Russ Housley's request. Obviously, discussion is very much
> wanted.
>
> Brian
>
> http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-changes-00.txt
>
> This docum
On Jul 6, 2007, at 3:07 AM, Iljitsch van Beijnum wrote:
And from an architectural perspective, address translation is
clearly a dead end. One of the reasons we argue against NATs is
not that there aren't other major problems, it's that people
haven't managed to get the message on NATs yet.
On Jul 6, 2007, at 1:52 PM, John C Klensin wrote:
--On Friday, 06 July, 2007 11:53 -0700 Douglas Otis
<[EMAIL PROTECTED]> wrote:
...
How will SMTP servers vet sources of inbound messages within an
IPv6 environment? Virtually every grain of sand can obtain a
"new" IPv6 a
On Jul 7, 2007, at 11:19 AM, Iljitsch van Beijnum wrote:
On 6-jul-2007, at 20:53, Douglas Otis wrote:
How will SMTP servers vet sources of inbound messages within an
IPv6 environment? Virtually every grain of sand can obtain a
"new" IPv6 address.
Simple: look at prefixes r
On Jul 8, 2007, at 10:53 PM, Lars Eggert wrote:
On 2007-7-5, at 19:07, ext Tom.Petch wrote:
If we had a range of transports (perhaps like OSI offered), we
could choose the one most suited. We don't, we only have two, so
it may become a choice of one with a hack. But then that limited
ch
On Jul 9, 2007, at 3:47 AM, Stephane Bortzmeyer wrote:
Designers of applications and higher-layer protocols still have a
tendency to ignore SCTP and DCCP
Because experience shows them that, unfortunately, they do not
cross most firewalls and NAT devices?
This is, sadly, yet another case
On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well
managed.
In all but a single instance I have no evidence to the contrary.
The one case of an exploit was extremely wel
On Jul 10, 2007, at 1:51 PM, Stephen Kent wrote:
At 1:13 PM -0700 7/10/07, Douglas Otis wrote:
On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well
managed.
In all but a
On Wed, 2007-07-11 at 09:55 +0200, Eliot Lear wrote:
> Doug,
>
> >
> > When short cuts are taken in PKI as with SMTP, there should be some
> > concern.
> >
> > DKIM voids vetted CAs, as the public key is obtained from DNS, this
> > provides the URL association directly.
>
> It's really not the
On Jul 12, 2007, at 8:33 AM, Iljitsch van Beijnum wrote:
On 12-jul-2007, at 16:57, JORDI PALET MARTINEZ wrote:
So I instruct here the secretariat to *automatically* take the
appropriate measures with this case and any other similar one in
the future, such as restricting (only) postings fro
On Jul 13, 2007, at 9:54 AM, Ken Raeburn wrote:
On Jul 13, 2007, at 09:05, John C Klensin wrote:
However, I think the IETF benefits from policies whose effect is
to keep the clueless and inconsiderate off our mailing list until
they can be educated.
I think most organizations or lists wou
On Jul 13, 2007, at 10:57 AM, Hallam-Baker, Phillip wrote:
I think we need to look beyond whether NAT is evil (or not) and
whether NATPT is the solution (or not) and look to see how we might
manage a transition to IPv6 in a way that is not predicated on
holding ISP customers hostage.
Peo
On Jul 16, 2007, at 4:51 AM, Melinda Shore wrote:
Another problem is the lack of naming and lookup facilities. DNS
SRV records are probably going to be as good as it gets. VoIP
protocols and others that make use of embedded addresses actually
do have an advantage here, because they're ab
On Jul 16, 2007, at 2:27 PM, David Harrington wrote:
Don't overlook 5.1 #1:
---
The author is the first-party sender of a message, as specified in
the [rfc2822].From field.
---
Per RFC2822:
---
3.6.2. Originator fields
... The "From:" field specifies the author(s) of the message, that
is,
On Tue, 2007-07-31 at 17:24 -0400, Keith Moore wrote:
> IMHO, "running code" gets more credit than is warranted. While it is
> certainly useful as both proof of concept and proof of
> implementability, mere existence of running code says nothing about
> the quality of the design, its security, sca
On Jul 31, 2007, at 5:16 PM, Peter Sherbin wrote:
The current business model does not bring in enough cash. How do
we bring in more in a way that furthers ietf goals?
E.g. other standards setting bodies have paid memberships and/or
sellable standards.
IETF unique way could be to charge a
On Jul 31, 2007, at 6:30 PM, John C Klensin wrote:
And, while I'm picking on DHCP because I personally had more
problems with it, I see IPv6 authconfig as being exactly the same
issue: we are telling the world that these things work and they
should be using them; if we can't make them work
On Aug 2, 2007, at 4:27 PM, Iljitsch van Beijnum wrote:
NAT isn't the only answer to the question "I can't get IPv4
addresses, what do I do?" Using IPv6 and a proxy to reach the IPv4
world is much, much cleaner. And it also works from v4 to v6. We
really should start advocating this as the
On Aug 3, 2007, at 11:24 AM, Dave Crocker wrote:
My point was about the failure to make sure there was large-scale,
multi-vendor, in-the-wild *service*. Anything that constraint [in]
what can go
wrong will limit the ability to make the technology robust and usable.
There are currently m
101 - 200 of 260 matches
Mail list logo
