for pushing a group's agenda.
A common symptom is to declare objections to be from an aberrant individual,
even when also expressed by others. The IETF must remain critical of its
process and its leadership to better avoid future debacles.
Regards,
Douglas Otis
in the desired fashion.
Regards,
Douglas Otis
justifications. The tie-in may be limited, but nevertheless DMARC has become
the chosen alternative. It seems if any reasons are given for moving ADSP to
historic it also should conjecture why DMARC and not ADSP, unless your point is
nothing has been learned?
Regards,
Douglas Otis
Dear SM,
See comments inline.
On Sep 16, 2013, at 9:00 AM, S Moonesamy sm+i...@elandsys.com wrote:
Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Add to:
11.5.3. Macro Expansion
,---
It is not within SPF's purview whether IPv6 or DNSSEC is being used. IPv6
(RFC2460) increased
On Sep 14, 2013, at 1:57 PM, S Moonesamy sm+i...@elandsys.com wrote:
Hi Doug,
At 20:56 13-09-2013, Douglas Otis wrote:
If I have said something offensive, allow me once again to assure you this
was never my intent.
There isn't anything in your message which was offensive. I'll try
without experiencing any notable problem. AOL
began their support of SPF by saying they would use SPF to construct whitelists
prior to receipt of email. Clearly, such whitelisting practices tends to
preclude benefits derived from macro use.
‘---
Regards,
Douglas Otis
and NATs. As with PKI, there are too
many actors influencing routing's integrity.
Regards,
Douglas Otis
to their
impact on underlying infrastructure. There are limits on making it easy to
send messages since the Internet is not suffering from a message scarcity.
Regards,
Douglas Otis
!
On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote:
Use of DKIM offers a very poor authentication example
Thanks for the feedback. I don't recall you having made this point on
the repute mailing list. Did you, I missed it?
Dear Andrew,
Sorry for the delay. I have been
to safely assign reputation. As such, DKIM should never be referred
to as a message authentication protocol. StartTLS would represent a much
better example.
Regards,
Douglas Otis
On Aug 24, 2013, at 3:16 AM, S Moonesamy sm+i...@elandsys.com wrote:
Hi Doug,
At 13:07 23-08-2013, Douglas Otis wrote:
The SPFbis document improperly conflates DNS terminology with identical
terms invented by this document. Examples are terms used to describe
mechanisms having the same
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR is not constrained in the current
specification and can create erratic results. It would be far safer to
Perm error when
On Aug 26, 2013, at 4:29 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR
moving forward.
Regards,
Douglas Otis
is a very poor
replacement.
12) All video information in the form of slides and text must be available from
the Internet prior to the beginning of the meeting.
Regards,
Douglas Otis
access fee (that should be able to
avoid VAT) might be reasonable.
Regards,
Douglas otis
of the traffic rather than Lufthansa that handles about
one fifth, was not the best choice where a 6 hour layover extended an hour on
the tarmac in a hot plane.
Regards,
Douglas Otis
. This control should not need to be done at
the meeting venue, but in the cloud as well.
Regards,
Douglas Otis
that automatically recognize requests to speak. The meeting agenda
should already indicate who is to speak, with their presentations available
before the beginning of the meetings. Nothing could be done without
everything being recorded and available remotely.
Regards,
Douglas Otis
taken ended up being doomed which may have been the
ultimate goal and potentially represents a real fairness issue IMHO.
Regards,
Douglas Otis
. If the Internet is down, so
is the meeting. That may make venue selection more dependent upon the quality
of the Internet availability.
Imagine real time translations made possible actually enhancing regional
understanding.
Regards,
Douglas Otis
, and Steve Jobs proved genius makes a difference in
hardware as well. As Isaac Newton said If I have seen further it is by
standing on the shoulders of giants.
Regards,
Douglas Otis
be avoided. It seems the same can be said of those trading profiles or and
those offering protection from profilers. Motivation plays a critical role in
steering development. It is just not something easily discussed within an
international organization.
Regards,
Douglas Otis
!
Additional information is being acquired, but will not alter conclusions
reached.
http://tools.ietf.org/html/draft-otis-dkim-harmful-03
Regards,
Douglas Otis
On Jun 4, 2013, at 9:13 AM, Murray S. Kucherawy m...@blackops.org wrote:
On Tue, Jun 4, 2013 at 4:08 AM, Douglas Otis doug.mtv...@gmail.com wrote:
In its current form, DKIM simply attaches a domain name in an unseen message
fragment, not a message. The ease in which the only assured
review. We'll take your input and review how this draft can
be better clarified.
Regards,
Douglas Otis
to obtain Standard status can not be
justified. Getting this right is far far more important. Allowing this to
become a standard will make specification modification even more difficult.
Regards,
Douglas Otis
levels. In other
words, it is better not to make assumptions.
Regards,
Douglas Otis
the DKIM
specification would likely be implemented despite the precautions given, and
the level of growing abuse being received.
http://tools.ietf.org/html/draft-otis-dkim-harmful-01
Best Regards,
Douglas Otis
Dear ietf,
To better clarify elements within otis-ipv6-email-authent draft, a separate I-D
is focused primarily on DKIM.
http://tools.ietf.org/html/draft-otis-dkim-harmful-00
Regards,
Douglas Otis
Dear IETF,
Sorry for repeating this message, but the proper subject line had not been used.
http://tools.ietf.org/html/draft-otis-dkim-harmful-00
explains why this document should not be supported to proceed as currently
defined.
Feedback on this I-D is welcome.
Regards,
Douglas Otis
injection.
Regards,
Douglas Otis
a security concern, please read this
draft from that perspective.
Regards,
Douglas Otis
On May 3, 2013, at 12:21 PM, Scott Kitterman sc...@kitterman.com wrote:
On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
...
Over many years at attempting to change the course of the SPF process, this
effort appears to have been futile.
...
It does seem a bit odd for you to claim
On May 3, 2013, at 1:00 PM, Scott Kitterman sc...@kitterman.com wrote:
On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote:
On May 3, 2013, at 12:21 PM, Scott Kitterman sc...@kitterman.com wrote:
On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
...
Over many years at attempting
working code?
Perhaps registration forms could ask about roles as related to marketing,
engineering, management, or support. From this, perhaps needed outreach can be
better determined.
Regards,
Douglas Otis
endeavors at hand, a friend of mine would
exclaim squirrel!
Regards,
Douglas Otis
On Apr 11, 2013, at 8:11 AM, Ray Pelletier rpellet...@isoc.org wrote:
All
The IETF is concerned about diversity. As good engineers, we would like
to attempt to measure diversity while working on addressing
some signed message content independent of the
intended recipient or the actual source. Evidence must not rely on statistical
likelihoods. The stakes are far to high.
Regards,
Douglas Otis
On Apr 8, 2013, at 10:27 PM, joel jaeggli joe...@bogus.com wrote:
On 4/8/13 9:18 PM, Douglas Otis wrote:
On Mar 31, 2013, at 1:23 AM, Doug Barton do...@dougbarton.us
mailto:do...@dougbarton.us wrote:
On 03/30/2013 11:26 PM, Christian Huitema wrote:
IPv6 makes publishing IP address
.
Regards,
Douglas Otis
a risk. Are you really suggesting that sharing the same /48
carries a similar risk?
The goal should be to avoid guesswork and uncertainty currently plaguing email.
v6 BGP announcement growth graph is published at:
http://bgp.potaroo.net/v6/as2.0/
Regards,
Douglas Otis
, and there is progress being made in
respect to use of DANE and the like.
Regards,
Douglas Otis
.
Here is the link that illustrates the serious problem.
http://www.bungi.com/Dom-v6.pdf
And again, I call on the IETF to work on this problem.
Regards,
Douglas Otis
. It is within their capabilities.
We can not make everyone upgrade, but we can establish a path that has a chance
of offering a solution.
Regards,
Douglas Otis
. I can expand on
this if anyone is interested.
Regards,
Douglas Otis
Hello Hector,
On Mar 28, 2013, at 3:53 PM, Hector Santos hsan...@isdg.net wrote:
Hi Doug,
On 3/28/2013 2:13 PM, Douglas Otis wrote:
Dear IETF,
In response to various strategies to reject IPv6 email lacking either DKIM
or SPF, the non-negotiated approach suggests far greater review
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
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
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
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo
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, but that
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
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.
On 11/17/11 9:17 AM, Robinson Tryon wrote:
On Wed, Nov 16, 2011 at 8:56 PM, Melinda Shoremelinda.sh...@gmail.com 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
On 11/15/11 10:26 AM, Frank Ellermann wrote:
On 15 November 2011 18:56, Noel Chiappaj...@mercury.lcs.mit.edu 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,
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
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 providers
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
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.
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
On 7/27/11 4:31 AM, Mark Townsley wrote:
On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
Since 6to4 is a transition mechanism it has no long term future *by
definition*. Even if someone chooses to design a v2, who is going to implement
On 7/26/11 12:58 PM, SM wrote:
Hi Ron,
At 07:30 AM 7/25/2011, Ronald Bonica wrote:
draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
and convert their status to HISTORIC. It will also contain a new
section describing what it means for RFCs 3056 and 3068 to be
classified as
On 6/23/11 8:24 AM, John Levine wrote:
In article4e02ee24.2060...@gmail.com you write:
On 6/22/11 11:14 AM, Dave CROCKER wrote:
Folks,
The bottom line about Doug's note is that the working group extensively
considered the basic issue of multiple From: header fields and Doug is
raising
://trac.tools.ietf.org/wg/dkim/trac/ticket/24
Regards,
Douglas Otis
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 12/22/10 2:11 PM, Ben Campbell wrote:
Thanks for the response. Further comments below. I elided sections
that I think have been addressed.
On Dec 15, 2010, at 4:30 AM, Stuart Cheshire wrote:
[..]
Yes, IDNA is not needed for Multicast DNS.
I think it would be highly unfortunate if we
On 11/18/10 4:51 AM, RJ Atkinson wrote:
IESG Folks,
The IETF already has taken MUCH MUCH too long handling this document.
Each time this I-D gets revised, new and different issues are raised.
While I am generally OK with the way IETF processes work,
this document is an exception.
On 7/12/10 11:39 AM, Martin Rex wrote:
Personally, I'm heavily opposed to an approach along these lines.
It is a big plus that MAC addresses can be trivially changed,
and I regularly connect with random MACs in public places.
Russ and Ted discussed use of MAC addresses for access. I may
On 7/1/10 8:26 AM, Fred Baker wrote:
While it is new in IETF meetings, it is far from unusual in WiFi networks to
find some form of authentication. This happens at coffee shops, college
campuses, corporate campuses, and people's apartments. I think I would need
some more data before I
On 6/28/10 12:35 PM, Martin Rex wrote:
To me it looks like Obsolete: has been used with quite different
meanings across RFCs, and some current uses might be inappropriate.
Although it's been more than two decades that I read rfc821 (and
none of the successors), I assume that all those RFC
On 6/15/10 11:04 AM, ned+i...@mauve.mrochek.com wrote:
And since I'm not in the best of moods I'll also answer in kind by
saying us application engineers might also be waiting for someone
with half a clue as to how to design a proper standard API to come
along and do that.
Ned,
Agreed,
On 6/9/10 5:57 PM, Ned Freed wrote:
I note in passing that this might have played out differently had we
gotten SRV record support in place for all protocols a lot sooner.
But without it for HTTP in particular you're faced with the need for
multiple port 80s in a lot of cases.
Disagree.
On 6/10/10 3:12 PM, Ned Freed wrote:
On 6/10/10 2:48 PM Douglas Otis wrote:
Disagree. HTTP is a bad example, since it allows canonical names
to be replaced with a name offered by clients for supporting name
based virtual hosts. In other words, a single port supports
thousands
On 6/7/10 12:49 PM, John C Klensin wrote:
My belief is that we have a serious IPv6 marketing and
transition problem until and unless we can get a level of
functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of
the sorts that Ned's notes imply) at a level of investment
roughly equivalent
On 6/9/10 1:19 PM, Ned Freed wrote:
When IPv6 is available, each device becomes
accessible with unique IP addresses. A conservative approach for scarce
IPv4 addresses is to associate dedicated servers/services with specific
ports of a single global address, a feature supported by nearly all
On 6/2/10 12:39 AM, Yoav Nir wrote:
Nice to hear just worked in the context of IPv6. Did your router give you
just an IPv6 address, or also an IPv4 address? If both, does the IPv6 address ever get
anywhere on the Internet, or is it always NATted?
The router appears to use RFC3056, with
On 6/1/10 9:57 AM, Olivier MJ Crepin-Leblond wrote:
On 30/05/2010 23:52, Phillip Hallam-Baker wrote :
People are not going to use IPv6 if it takes the slightest effort on
their part. People are not going to switch their home networks over to
IPv6 if it means a single device on the network
On 5/17/10 10:06 AM, Joe Touch wrote:
My point here is that if you're discussing alternatives, you need to
address why this alternative was not used. There may be useful reasons
(in specific, using a separate command allows you to reuse some error
codes more usefully), but you're also incurring
On 5/12/10 9:34 PM, John C Klensin wrote:
Doug,
Let's separate two issues. One is whether or not this
particular proposal, with or without RFC 4217 (an existing
Proposed Standard), is appropriate. If it is not, or cannot
exist in harmony with 4217, then it reinforces my view that it
should not
On 5/12/10 9:38 AM, Joe Abley wrote:
On 2010-05-12, at 12:32, Paul Hoffman wrote:
The use of FTP dwarfs the use of SFTP by at least two orders of magnitude.
Sure.
To paraphrase my comment (or at least re-state it in a clearer way) from a
protocol perspective, setting aside
On 5/12/10 2:39 PM, John C Klensin wrote:
Others may disagree, but our success record when we tell people not
to do something that works well for them and, in their opinion, poses
no risks, is terrible. All saying FTP is dead, go use something
else can accomplish is to drive the work away
On 3/16/10 6:22 AM, Julian Reschke wrote:
Speaking of which: did we ever *measure* the acceptance of
draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support
for it.
The draft expired at rev 5, but can be found at:
http://tools.ietf.org/html/draft-hoffman-utf8-rfcs
-Doug
On Jul 12, 2009, at 4:42 PM, Doug Ewell wrote:
This thread has been headed down the wrong path from the outset, as
soon as Tony Hain wrote on July 1:
An alternative would be for some xml expert to fix xml2rfc to parse
through the xml output of Word. If that happened, then the
On Jul 7, 2009, at 9:19 PM, Doug Ewell wrote:
Douglas Otis dotis at mail dash abuse dot org wrote:
The concern is about the application accepting document
instructions and text and then generating document output. When
this application is proprietary, it is prone to change where
On Jul 3, 2009, at 3:16 PM, Doug Ewell wrote:
Douglas Otis dotis at mail dash abuse dot org wrote:
Reliance upon open source tools ensures the original RFCs and ID
can be maintained by others, without confronting unresolvable
compatibility issues.
Whether a tool is open source
On Jul 3, 2009, at 8:07 AM, Doug Ewell wrote:
As always when this discussion occurs, there are at least three
different issues swirling around:
1. ASCII-only vs. UTF-8
2. Plain text vs. higher-level formatting, for text flow and
readability
3. Whether it is a good idea to include
On Jul 2, 2009, at 9:22 AM, Marshall Eubanks wrote:
On Jul 2, 2009, at 12:16 PM, Ted Hardie wrote:
At 10:19 PM -0700 7/1/09, Douglas Otis wrote:
for wanting more than just plain text documents is to permit
inclusion of charts, graphs, and tables, for a visual society
It seems to me
On Jul 1, 2009, at 10:58 AM, Tony Hain wrote:
An alternative would be for some xml expert to fix xml2rfc to parse
through the xml output of Word. If that happened, then the
configuration options described in RFC 3285 would allow for wysiwyg
editing, and I would update 3285 to reflect the
On May 29, 2009, at 7:33 AM, Francis Dupont wrote:
I don't understand your argument: it seems to apply to UDP over SCTP
but here we have SCTP over UDP. BTW the easiest way to convert DNS
over UDP into DNS over SCTP is to use an ALG (application layer
gateway) which in the DNS is known as
On May 28, 2009, at 9:45 AM, David Conrad wrote:
On May 28, 2009, at 5:47 AM, Alessandro Vesely wrote:
I don't trust the data because it is signed, I trust it because the
signature proves that it originated from the authoritative server.
Not quite. The signature over the data proves that
On May 25, 2009, at 4:56 PM, John C Klensin wrote:
With a train, you have to pick the correct train, and then leave
the train at the correct stop. A bit more complicated to be honest.
By interacting with people, you often can handle the most
complicated train ride, but yes, it might be
Jim,
Telco has a goal of maintaining 5 9's where SCTP was developed to
carry their SS7 protocol. The FreeBSD stack for SCTP supports IPv4,
IPv6 and multi-homing. This protocol immediately recovers from
network path failures as it heartbeats against alternative paths. The
protocol can
On Mar 23, 2009, at 3:27 PM, Dave CROCKER wrote:
Steven M. Bellovin wrote:
It's happened to me twice, with two different lists of his. I've
complained to him, but to no avail. I wonder if the CAN SPAM act
applies.
IANAL but my impression is that it definitely does apply, possibly
On Feb 28, 2009, at 4:14 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
The safety of an assumption about an authorizing domain originating
a message depends upon the reputation of the SMTP client for its
protection of the PRA and Mail From. Unfortunately, identifiers
for the SMTP
On Feb 26, 2009, at 10:47 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
3) Separate SMTP clients share the same IP addresses.
(Unfortunately this is also a common practice. Brazil, Poland, and
other places have many ISPs that expect hundreds or thousands of
customers to run
On Feb 25, 2009, at 11:42 PM, Murray S. Kucherawy wrote:
Doug,
On Wed, 25 Feb 2009 00:10:21 -0800, Doug Otis wrote:
The Sender-Header-Auth draft clouds what should be clear and
concise concepts. Organizations like Google have already remedied
many of the security concerns through
. The
appeal was not taken lightly, but feedback from those within the email
community appears indicate a willingness to adopt this header standard.
Douglas Otis and Dave Rand
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Doug Otis wrote:
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP
client as a weakly authenticated origin identifier. The IP
address of the SMTP client is the input for Sender-ID or SPF
*authorization*
.
The IESG faces the hard decision of whether they are to act in the
greater interests of better protecting millions of recipients, or
acquiesce to the interests of influential providers acting out of self
interest.
Douglas Otis and Dave Rand
___
Ietf
On Jan 13, 2009, at 9:02 AM, SM wrote:
Hi Doug,
At 18:53 12-01-2009, Doug Otis wrote:
(see section 3.4.1 of [MAIL]) of an address, the pvalue reported
along with results for these mechanisms SHOULD NOT include the
local- part.
SHOULD NOT is not an recommendation to do something.
On Jan 12, 2009, at 6:53 PM, Murray S. Kucherawy wrote:
[Apologies for the double-send; the headers got munged by my editor.
-MSK]
Doug Otis wrote:
[...] while omitting the IP address of the SMTP client. This
prevents compliance with section 4.1 reputation check of an
authenticated
, 2009 at 1:14 PM, Douglas Otis do...@mail-abuse.org
wrote:
Murray,
There has been progress, but a few extremely critical security
related areas still need to be addressed.
I have posted a draft that reviews the sender-auth-header draft.
The text and html versions are available at:
http
1 - 100 of 245 matches
Mail list logo
