http://www.ist-ipv6.org/modules.php?op=modloadname=Newsfile=articlesid=567
**
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
May I suggest that a URL like:
http://www.ietf.org/std/std0051.txt
be made that can refer to the STD series of documents?
- --
] ON HUMILITY: to err is human. To moo, bovine. [
] Michael Richardson,
... HREF=http://sa.vix.com/~vixie/mailfrom.txt;MAIL-FROM/A.
I do not see a draft in the ietf process anyplace . Was this
ever submitted ? I do notice that several of the other
proposal's make mention of this work , But in none of them do
they mention it as a
The headline is misleading. The recommendation is to support
IPv6 registration of TLD servers in the root zone. The root
servers themselves still need some testing before registration
of their IPv6 capabilities.
--bill manning
Iljitsch van Beijnum wrote:
On 27-mei-04, at 16:56, [EMAIL PROTECTED] wrote:
(I've yet to see a proposal that works if the spammers start
utilizing zombie machines that snarf the already-stored credentials
of the user
to send mail)
The question is whether spammers can obtain new credentials
Your_complaint.cpl
Description: Binary data
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
From: John Stracke [EMAIL PROTECTED]
(I've yet to see a proposal that works if the spammers start
utilizing zombie machines that snarf the already-stored credentials
of the user
to send mail)
The question is whether spammers can obtain new credentials (stolen or
otherwise)
Greetings again. I was at a conference this week that offered WiFi.
They had the same problems we had at the past two IETFs with a few
folks doing ad-hoc mode, thereby knocking out access for many of us.
Was there any writeup from the IETF NOC teams about the problem and
how we fixed it? If
Paul,
MARID was formed to merge Microsoft Caller-ID with SPF and so far has
been successfully used by Microsoft to bully us to submit to their own
proposal or else ... There are better ways to implement mail-from (i.e.
as from Paul's draft which is basicly still the basis for MARID) which
1. block port 25 to external IP addresses for all of your customers
except those with what draft-klensin-ip-service-terms-01.txt calls
Full Internet Connectivity.
... and receive a flood of complaints because 10% of your users are
using a mail service provided by someone else than
At 9:17 PM + 05/27/2004, Paul Vixie wrote:
MARID is basically a layer 9 exercise, uninterested in engineering as
such. it was formed to merge two ill considered ideas, one from yahoo
and one from microsoft, in a way that would cause either no loss of face,
or equal loss of face, for those two
From: Christian Huitema [EMAIL PROTECTED]
1. block port 25 to external IP addresses for all of your customers
except those with what draft-klensin-ip-service-terms-01.txt calls
Full Internet Connectivity.
... and receive a flood of complaints because 10% of your users are
* From [EMAIL PROTECTED] Fri May 28 05:58:39 2004
* To: [EMAIL PROTECTED]
* Date: Thu, 27 May 2004 16:19:15 -0400
* From: Michael Richardson [EMAIL PROTECTED]
* X-Mailman-Approved-At: Fri, 28 May 2004 08:19:57 -0400
* Subject: STD series of documents
* X-BeenThere: [EMAIL
On 28-mei-04, at 15:06, John Stracke wrote:
(I've yet to see a proposal that works if the spammers start
utilizing zombie machines that snarf the already-stored credentials
of the user to send mail)
The question is whether spammers can obtain new credentials (stolen
or otherwise) faster
Since mid March I have been leading a private mail list and came out
with a conclusion last weekend that there can be no telecom recovery
as long as the industry relies solely on the best effort business
model which I believe is not economically sustainable.
This has led to two articles on my
A new Request for Comments is now available in online RFC libraries.
RFC 3757
Title: Domain Name System KEY (DNSKEY) Resource Record
(RR) Secure Entry Point (SEP) Flag
Author(s): O. Kolkman, J. Schlyter, E. Lewis
Status: Standards
A new Request for Comments is now available in online RFC libraries.
RFC 3786
Title: Extending the Number of
Intermediate System to Intermediate System (IS-IS)
Link State PDU (LSP) Fragments Beyond the 256
Limit
17 matches
Mail list logo
