On Dec 9, 2008, at 2:42 PM, Keith Moore wrote:
when the reputation is based on something (like an address or
address block) that isn't sufficiently fine-grained to reliably
distinguish spam from ham, as compared to a site filter which has
access to more criteria and can use the larger set
On Dec 11, 2008, at 1:51 PM, John C Klensin wrote:
As soon as one starts talking about a registry of legitimate
sources, one opens up the question of how legitimate is
determined. I can think of a whole range of possibilities -- you,
the ITU Secretary-General, anyone who claims to have
Recent changes did not correct concerns described in:
http://tools.ietf.org/id/draft-otis-dkim-adsp-sec-issues-03.txt
--o-- Changes meaning of DKIM's on-behalf-of:
A highly detrimental aspect of this draft is its change to the meaning
of RFC 4871's signature header's i= (on-behalf-of) value.
On Nov 21, 2008, at 11:02 AM, SM wrote:
At 20:00 20-11-2008, Douglas Otis wrote:
It is rather startling that adoption of an experimental RFC is
being presumed by this draft. As such, those not adopting this
experimental PRA RFC run the risk of being
There are existing implementations
Last call for
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-17.txt
The intent of this posting is to generate broader discussion.
Browser and MUA plugins may soon annotate email messages with
identifiers contained within Authentication-Results headers. For
Apple
On Nov 14, 2008, at 1:38 PM, Ted Hardie wrote:
If we are documenting practice and nothing more, then the
publication stream can move to informational and text can be added
on why a new RR, which would normally be expected here, is not being
used (essentially, inertia in the face of 15
New email headers' misuse of the term authentication will prove
highly deceptive for recipients and damaging for domains!
The Random House dictionary definition of authenticate says:
1. to establish as genuine.
2. to establish the authorship or origin of conclusively or
unquestionably,
This draft introduces several areas where the vouching services
results could be exploited.
Section 3. Validation Process
2. Verifies legitimate use of that domain using one or more
_authentication_ mechanisms as described herein
This draft incorrectly describes Sender-ID and SFP as a
On Oct 28, 2008, at 8:03 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Interoperability of standards is a hard-won prize, whether in the
IETF or elsewhere. The cost of producing documents is a mere drop in
the bucket. In addition, cost is a very slippery thing to get ahold
of because
Here is a draft that outlines a few concerns for draft-ietf-dkim-ssp-06:
http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-sec-issues-03.txt
These concerns were not fully discussed on the DKIM list expect for
voting for an as is. Unfortunately a voting process offers little
clarity.
an assurance
that the reasoning was principled. You can always add two
signatures sounds too much like Let them eat cake from my
perspective.
-Doug
Stephen.
[1] http://mipassoc.org/pipermail/ietf-dkim/2008q3/010706.html
Douglas Otis wrote:
Here is a draft that outlines a few concerns for draft
There is a growing stream of spam being emitted from 64.170.98.32.
This appears to be the outbound server for IETF mailing-lists. Some
of the spam has had headers added that indicate the message was
originally received from an open relay or an IP address on several
block-lists (with
On Jul 7, 2008, at 10:49 AM, John C Klensin wrote:
--On Monday, 07 July, 2008 17:19 + John Levine
[EMAIL PROTECTED] wrote:
John,
While I find this interesting, I don't see much logical or
statistical justification for the belief that, if one increased (by
a lot) the number of TLDs, the
On May 3, 2008, at 3:44 PM, Frank Ellermann wrote:
SM wrote:
SenderID and SPF does not authenticate the sender.
For starters they have different concepts of sender, PRA and
envelope sender, and RFC 4408 section 10.4 offers references (AUTH +
SUBMIT) for folks wanting more.
Agreed.
On Apr 14, 2008, at 7:33 PM, Tony Hansen wrote:
The SMTP implementations that have made the transition to support
IPv6 appear to already have done it in a way that supports
records for the implicit MX case. In some cases they are following
RFC 3974, and other cases they are just
On Mar 27, 2008, at 8:31 PM, Keith Moore wrote:
David Morris wrote:
Perhaps you could help us out and share a reference to
documentation of such problems. I for one have not personally
observed any problems related to using the A record to locate a
mail server when there is no MX.
On Mar 24, 2008, at 11:42 AM, Ned Freed wrote:
John C Klensin [EMAIL PROTECTED] wrote:
--On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
[EMAIL PROTECTED] wrote:
The update of RFC2821 is making a _significant_ architectural
change to SMTP by explicitly stating records
On Mar 20, 2008, at 3:30 PM, John C Klensin wrote:
--On Friday, 21 March, 2008 09:03 +1100 Mark Andrews
[EMAIL PROTECTED] wrote:
I think Doug is saying don't let domains with just
records be treated as valid RHS of email. Today we
have to add records to domains with
While this response may be a bit late, the change in section 5.1
indicating SMTP server discovery now explicitly supports IPv6 address
records represents a significant change from RFC2821.
While a desire to retain current practices has some justification,
extending an already dubious and
On Dec 18, 2007, at 9:29 AM, Stephen Farrell wrote:
While I think the original idea of doing this during a plenary is
fine, doing it in the meeting areas on Tuesday evening does sound
like a better option. Awarding success with real beer at the social
iff you can print the coupon would
On Oct 16, 2007, at 5:00 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Do you expect everyone to use inbound servers to send?
No. Of course I'd expect that mail to postmaster to the IP of an
MTA talking to an MX I care about works. BTW, it would be nice if
only the MXs
On Oct 15, 2007, at 5:51 AM, Frank Ellermann wrote:
Douglas Otis wrote:
By using the local-part in a spam campaign, one cached SPF record
is able to reference an unlimited sequence of MX records.
In theory IANA could publish one _spf.arpa v=spf1 mx a -all
record, and everybody
On Oct 15, 2007, at 5:18 PM, Brian E Carpenter wrote:
Joel,
The volunteers built a model that was sustainable with a modest
amount of capital and time. both jabber and and streaming audio.
For which many thanks from many of us, I'm sure. Also, the
Secretariat built a tool so that all
On Oct 11, 2007, at 2:23 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Macro expansion and text strings can be combined with any SPF
record mechanism and CIDR mask. Any email-address differing in
just the local-part must then be iteratively processed across the
SPF record set (up
On Oct 10, 2007, at 12:12 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Due to the macro nature of SPF, full processing is required for
each name evaluated.
If what you call full processing is the procedure to fetch the
policy record of the domain in question, and match the connecting
On Oct 9, 2007, at 3:59 AM, Frank Ellermann wrote:
Douglas Otis wrote:
There is a real risk SPF might be used as basis for acceptance
You can combine white lists with SPF PASS as with DKIM PASS, the
risk is very similar.
Due to the macro nature of SPF, full processing is required
On Oct 8, 2007, at 4:54 PM, Keith Moore wrote:
Tony Finch wrote:
On Thu, 4 Oct 2007, Keith Moore wrote:
the vast majority of domains won't be able to use DKIM without
seriously impairing their users' ability to send mail.
You seem to be assuming that the vast majority of domains have
On Oct 8, 2007, at 4:37 AM, Frank Ellermann wrote:
SM wrote:
TMDA may cause backscatter.
After an SPF PASS, the backscatter by definition can't hit an
innocent bystander. By the same definition any backscatter after
an SPF FAIL hits an innocent bystander, and therefore is net abuse.
On Oct 3, 2007, at 2:59 PM, Hallam-Baker, Phillip wrote:
There is more we can do here but no more that we should feel
obliged to do - except for the fact that we are a standards
organization and should eat the dog food.
In particular, sign the messages with dkim and deploy spf.
Few
On Oct 2, 2007, at 6:14 PM, John Levine wrote:
The Secretariat tells me that Spammers are responding to TDMA
queries so that their mail goes through. They have made the
suggestion that we clear the list of people once per year.
Isn't there an engineering principle that if something is
On Aug 23, 2007, at 3:33 AM, John C Klensin wrote:
Marginal and criminal elements are _always_ the most innovative
people around if there is profit in stretching the boundaries of
the rules. In normal environments, the consequences of those
innovations are limited by effective
On Aug 21, 2007, at 4:59 PM, John C Klensin wrote:
I'm not convinced that is worth it --and strongly suspect it is
not-- but, if Doug believes otherwise, I'm looking forward to
seeing a proposal.
I hope to have a draft ready in the near future. When SMTP was
developed, HTTP did not
On Aug 16, 2007, at 3:10 PM, Keith Moore wrote:
I also think there might be some merit in holding mail on the
sender's outgoing mail server until the receiver's MX is willing to
deal with it, thus pushing more of the costs toward the sender of a
message.
The concept of holding messages
On Fri, 2007-08-17 at 09:27 -0400, John C Klensin wrote:
I'm not convinced of the merits of the general idea you are
pushing here, mostly because I still believe in the value of
mail systems with relay (or, if you prefer, store-and-forward)
capability. If one requires that one be online to
On Aug 16, 2007, at 6:54 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Such a document could help frame the discussion and identify
weaknesses that need further work such as the SPF/DKIM bandaids. We
have gotten to the present situation because various people doing
work on the problem
On Aug 16, 2007, at 12:30 PM, SM wrote:
If we get rid of the anonymity for relays delivering to final
destination, i.e. gmail.com sending a message for [EMAIL PROTECTED]
to an aol.com mailserver, then most of the spam stream goes away.
At that point, we only have to worry about spam which
On Aug 15, 2007, at 12:16 PM, Fred Baker wrote:
in that context, here's one that one could use to dramatically
reduce spam intake.
That suggests a simple approach - in one's firewall, null route the
addresses reported by the reputation service as spam spews. It's a
network layer
On Aug 15, 2007, at 2:06 PM, Keith Moore wrote:
and I've had more than my share of legitimate mail fail to be
delivered (in either direction) because of such measures. you may
consider that legitimate for your or cisco's purposes. whether to
throw away mail that can potentially be from
On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote:
What happened to draft-hain-1918bis-01, which tried to get more
address space for private Internets, but expired back in 2005?
I see the point about regarding 240.0.0.0/4 as tainted space and
therefore being less than useful on the
On Aug 8, 2007, at 10:52 AM, Marshall Eubanks wrote:
On Aug 8, 2007, at 1:35 PM, Douglas Otis wrote:
On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote:
What happened to draft-hain-1918bis-01, which tried to get more
address space for private Internets, but expired back in 2005?
I see
On Aug 8, 2007, at 1:22 PM, David Conrad wrote:
Hi,
On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote:
Which widespread IPv4 stacks?
I think it might be easier to identify stacks that don't disallow
240/4. I don't actually know of any widespread ones.
Rather than wall off 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
On Aug 3, 2007, at 2:54 PM, Hallam-Baker, Phillip wrote:
I don't see a duty of care here. There is no general obligation in
law to give up an economic interest just to help others.
Rather than allowing IP addresses to be traded, an annual per IP
address use fee could be imposed. This fee
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 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,
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
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
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 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.
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
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
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 same. The
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
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
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
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 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 rather than
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 document
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
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 address. An IPv6
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
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
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
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
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
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
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
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.
I
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
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
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
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
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 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
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
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
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
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
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
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,
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
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)
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?
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
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
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 help
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 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
___
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,
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 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 happy
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
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
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
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 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 what
On Oct 7, 2006, at 10:42 AM, Lakshminath Dondeti wrote:
At 01:42 AM 10/7/2006, Harald Alvestrand wrote:
snip
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
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
101 - 200 of 245 matches
Mail list logo
