Re: IESG intends to publish conflicting RfCs causing loss of legit e-mails

Bill Sommerfeld <[EMAIL PROTECTED]> wrote: > > I have not been able to find a concise description of exactly what havoc > will ensue wayne <[EMAIL PROTECTED]> wrote: > > Also, one of the open issues with SPF is the ability to deal with > forwarded email. One of the most promising solutions to thi

draft-hutzler-spamops-04

I very much like the goals of this document, but I think there's a little room for improvement and clarification, as follows: Authentication vs. authorization The draft mostly talks about authentication (authn) rather than authorization (authz). I'm not sure whether the aim is to require actual

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Wed, 15 Jun 2005, Dean Anderson wrote: > > Had anyone bothered to ask, I would have reported that open relay abuse > has dropped off to nearly nothing since the open relay blacklists shutdown > in 2003. MXs are routinely probed by relay attempts: we see about 2000-4000 such attacks each day. A

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Wed, 15 Jun 2005, Dean Anderson wrote: > > What sort of mail volume to you handle? 2000-4000 attempts isn't a lot > for large volume domain handling millions of messages per day. About 250K legit messages each day, and about a million junk messages. Yes, it isn't a very large proportion of our

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

On Sun, 19 Jun 2005, Dean Anderson wrote: > > Neither open relays nor lack of email authentication are > problems that are exploited by spammers. Neither of those statements are true. I've already addressed the first. Regarding the second, we dealt with an incident last year where a spammer exploi

Re: IETF 63 On-line Survey

On Thu, 18 Aug 2005, Harald Tveit Alvestrand wrote: > > Forms that change their content based on the answers given look fancy, but > they can be almighty confusing if you're trying to scan the questions before > filling them in. The form didn't change at all when I filled it in. I may have had

Re: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards

On Fri, 26 Aug 2005, Keith Moore wrote: > > I think DKIM is fixable, but if it stays in its current form it will only > delay adoption of effective anti-phishing and anti-spam solutions by a few > more years. Has anyone published a description of an "effective anti-phishing and anti-spam solution"

Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822

On Mon, 29 Aug 2005, Frank Ellermann wrote: > > > incompatible with RFC2822 > > I'm still a bit lost how this could actually _break_ something. > For obvious reasons the author can't say "updates 2822", how > should he fix it ? As you said the 822 issue is mentioned in > the senderid-pra draft. R

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Tue, 30 Aug 2005, Margaret Wasserman wrote: > > The LLMNR document already includes an informative reference to > draft-cheshire-dnsext-multicastdns-05.txt, but it does so rather obscurely > (citing a need to use a TTL of 255 for "compatibility with Apple Bonjour"). That doesn't make sense. Why

Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

On Thu, 1 Sep 2005, Harald Tveit Alvestrand wrote: > > LLMNR allows me to treat names in a different way than mDNS does. > If I have a name that I'm certain I own (this box is, with high certainty, the > only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to > assert that na

Re: Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])

On Thu, 1 Sep 2005, Frank Ellermann wrote: > > > Regarding RFC 822, the S-ID draft doesn't mention the fact > > that a large proportion of software which does something > > useful with Resent- headers still implements the 822 syntax, > > not the 2822 syntax. > > Except from all PRA-purposes and may

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Thu, 1 Sep 2005, Iljitsch van Beijnum wrote: > > I don't understand how you can be in favor of LLMNR while at the same time > being opposed to confusion between local and global ("DNS") names. In theory, > I suppose it's possible that the information available over LLMNR and the > information av

Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

On Fri, 2 Sep 2005, Harald Tveit Alvestrand wrote: > > Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in > additional data?) would seem to be one possibility to "prove" that the data > being presented was "legitimate" under DNS delegation rules, even when you > don't have a pr

Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

On Fri, 2 Sep 2005, Steven M. Bellovin wrote: > >How can you verify the signature without an Internet connection with which > >to fetch the key? > > If you have the zone key, you can do the verification offline. How can you be expected to have the zone key of some random name that just turned up

Re: Resent-* oddities

On Sun, 4 Sep 2005, Frank Ellermann wrote: > > Where's the problem with an 2822 "resender" ? I'm not sure > about your term "submission server", as far as 2822 (excl. PRA) > is concerned a "resender" is a MUA controlled by a human user. RFC 2476 recommends server-side message header fix-ups, so t

Re: email "Common Operating Group"

On Mon, 14 Nov 2005, Keith Moore wrote: > > I haven't seen a need to include transit operations in either case, and > to me it seems like that would make it muddier. The whole assumption > behind discouraging third-party relaying is that a mail network should > only process messages that were eith

Re: bozoproofing the net, was The Value of Reputation

On Wed, 4 Jan 2006, Sam Hartman wrote: > > OK. If this is just an assumption and not backed by evidence, I would > suspect that outside of the web you see a lot less use of the big CAs. Web-style TLS is used for authenticating the server in other protocols too, such as IMAP, submission-mode SMTP,

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

On Fri, 20 Jan 2006, Sam Hartman wrote: > > What about suspending Jefsey from just the ietf-langugages list and > possibly the ltru list? Isn't that what the last call says? It allows other list mangers to ban him too, but doesn't require it. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dot

Re: ISO 3166 mandatory?

On Wed, 20 Feb 2008, Frank Ellermann wrote: > > The history of UK vs. GB is explained in RFC 3071 - for unrelated > reasons I read it yesterday again. RFC 3071's comments about the crown dependencies are now obsolete, since they have been added to ISO 3166. The ISO 3166 FAQ also has more informati

Re: ISO 3166 mandatory?

On Thu, 21 Feb 2008, Frank Ellermann wrote: > Stephane Bortzmeyer wrote: > > > Do not worry, David Conrad, IANA, reads this list and he will > > certainly resolve the discrepancy today by renaming the TLD > > ".uk" to ".gb". > > LOL, is that something they should do with DNAME ? I always preferr

draft-duerst-iana-namespace-00.txt

The latest RISKS gibes an example of the magnitude of the problem of unwanted traffic caused by using URLs instead of URNs for protocol identification URIs. Perhaps the security considerations section of the draft should describe some ways of mitigating it? http://catless.ncl.ac.uk/Risks/25.07.htm

Re: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard

On Tue, 18 Mar 2008, Ned Freed wrote: > > Not really. The information environment supplies is, as the name implies, > about > the environment things are operating in. This includes information about the > Sieve interpreter, the host it is running on, and the network. The last item > includes conne

Re: Last Call: draft-klensin-rfc2821bis

On Wed, 26 Mar 2008, John C Klensin wrote: > > At the time 974 and 1123 were written, the only sort of address record > in Class=IN was an A RR, and those documents used "A RR" terminology. > The change in 2821bis essentially substituted the phrase "address > record" (or "address RR") for "A record

Re: Implicit MX and A RRs

On Thu, 27 Mar 2008, Matti Aarnio wrote: > > There will be lots of legacy codes using legacy APIs for long future. > I do use getaddrinfo() API myself, and permit it do all queries to > get addresses. Thus it will also query for A in addition to . > It can even be ordered to ignore IPv4 or I

Re: Last Call: draft-klensin-rfc2821bis

On Sat, 29 Mar 2008, John Levine wrote: > > Getting rid of the fallback flips the default to be in line with > reality -- most hosts don't want to receive mail directly, so if > you're one of the minority that actually does, you affirmatively > publish an MX to say so. I agree that this is th

Re: RFC 3484 Section 6 Rule 9

On Mon, 2 Jun 2008, Mark Andrews wrote: > > This rule should not exist for IPv4 or IPv6. Longest match > does not make a good sorting critera for destination address > selection. In fact it has the opposite effect by concentrating > traffic on particular address rather tha

Re: RFC 3484 Section 6 Rule 9

On Tue, 3 Jun 2008, Ralph Droms wrote: > Without some way to choose which rule to use and when to use it, how > can a recommendation that has conditional rule usage be implemented? The Kame/BSD IPv6 stack has a system-wide address selection policy. http://www.freebsd.org/cgi/man.cgi?query=ip6addr

Re: RFC 3484 Section 6 Rule 9

On Tue, 3 Jun 2008, Michael StJohns wrote: > Can I suggest this discussion be transferred off the main list and to > either the 6man list or the v6opts list (or both) please? It causes operational problems for IPv4 too. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ WIGHT POR

Re: RFC 3484 Section 6 Rule 9

On Tue, 3 Jun 2008, Michael StJohns wrote: > The particular document at issue is "Default Address Selection for IP > version 6". If you want to raise a similar issue for IPv4, I'm sure > that there is an appropriate WG list for that as well. The RFC covers IPv4 too, as it says in the abstract.

Re: 64bit time_t

On Sat, 21 Jun 2008, Chad Giffin wrote: > > We currently (normally) store time as the number of elapsed seconds > since January 1st 1970 GMT. NTP represents time as an unsigned 32 bit integral number of seconds since 1900-01-01 00:00:00 plus 32 bits of fraction, i.e. the whole timestamp is 64 bit

Re: Update of RFC 2606 based on the recent ICANN changes ?

On Mon, 30 Jun 2008, Stephane Bortzmeyer wrote: > On Mon, Jun 30, 2008 at 05:49:18AM -0700, > David Conrad <[EMAIL PROTECTED]> wrote > a message of 11 lines which said: > > > Speaking technically, how would you distinguish the top-level domain > > "127.0.0.1" from the IP address 127.0.0.1? > > A

Re: Update of RFC 2606 based on the recent ICANN changes ?

On Mon, 7 Jul 2008, [EMAIL PROTECTED] wrote: > > So who's going to explain to the Vatican that, sorry, > > [EMAIL PROTECTED] doesn't work any more? Or will the US take > > issue when addresses @as, which is part of the US, > > don't work? Or France about @gp and @mq, which are > > as much part o

Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08

On Wed, 6 Aug 2008, Lisa Dusseault wrote: > > Before that failure, there's the problem that a GET to a HELD server requires > a custom body. RFC 2616 says "A message-body MUST NOT be included in a request if the specification of the request method does not allow sending an entity-body in requests.

Re: IETF copying conditions

On Wed, 17 Sep 2008, Joe Abley wrote: > > I think the *whole point* of a standard is to restrict how things are > done, in order to promote interoperability. Standards are recommendations not restrictions. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ NORTHWEST SHANNON: SOUTH

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Sun, 9 Nov 2008, Tony Hansen wrote: > > Does anyone have issues with the use of this protocol for WHITE lists? DNSWLs already exist and are used by e.g. SpamAssassin. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ TYNE DOGGER FISHER: SOUTHWEST 6 TO GALE 8, BACKING SOUTH 5 O

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Mon, 10 Nov 2008, Keith Moore wrote: > > I suspect it will be very difficult to make IPv6 DNSxLs work anywhere > nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use > a different address for every SMTP conversation. I expect that attack will make /48 or /64 listings common.

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Mon, 10 Nov 2008, Keith Moore wrote: > Tony Finch wrote: > > > In any case, DNSBLs should scale roughly according to the size of the > > routing table, not the size of the address space. > > What does it mean for a DNSBL to "scale"? I was referring to the

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Mon, 10 Nov 2008, Keith Moore wrote: > > okay. I found myself wondering if the change in address space size, and > in granularity of assignment, might make DNSBLs less reliable. Which is > a different kind of scalability. IPv6's bigger address space affects more security mechanisms than just

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Tue, 11 Nov 2008, Theodore Tso wrote: > > Questions like, "so how does this work in the face of the expanded > IPv6 address space", ideally should be addressed earlier during the > standardization process, and not in last call (where, "oh well, we'll > just block the whole /48 or /32" might have

Re: IP-based reputation services vs. DNSBL (long)

On Sun, 9 Nov 2008, Keith Moore wrote: > > It is worth repeating that just because the notion of a reputation > service has value, and such services are widely used, does not imply > that using IP addresses as identifiers or the DNS protocol as a means of > transmitting reputation are technically s

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Tue, 11 Nov 2008, Andrew Sullivan wrote: > > In addition, the document proposes to continue using the existing > mechanism in order to support IPv6 hosts. There is little evidence of > a widespread deployment of such use, Exim has had support for IPv6 DNS lists as described by this draft for m

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Wed, 12 Nov 2008, Andrew Sullivan wrote: > On Wed, Nov 12, 2008 at 05:23:12PM +0000, Tony Finch wrote: > > On Tue, 11 Nov 2008, Andrew Sullivan wrote: > > > > > > In addition, the document proposes to continue using the existing > > > mechanism in order to

Re: Comments on Draft IRTF ASRG DNSBL - 07

On Wed, 12 Nov 2008, Mark Andrews wrote: > > It also stops the small sites being able to use cryptography to stop man > in the middle attacks as they are forced to insert a middle man. SMTP over TLS to an MX does NOT protect against man in the middle attacks. Tony. -- f.anthony.n.finch <[EMAIL

SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07

On Thu, 13 Nov 2008, Mark Andrews wrote: >In message <[EMAIL PROTECTED]>, Dave CROCKER writes: >>Mark Andrews wrote: >>>In message <[EMAIL PROTECTED]>, Tony Finch writes: >>>> >>>> SMTP over TLS to an MX does NOT protect against man in the m

Re: uncooperative DNSBLs, was several messages

On Thu, 13 Nov 2008, John C Klensin wrote: > > If there were a BCP on the table that would permit us to talk > about DNSRBLs that conform and those that don't, rather than > about subjective opinions of "behaving badly", we would, IMO, be > having a rather different discussion. http://www.ietf.org

Re: uncooperative DNSBLs, was several messages

On Thu, 13 Nov 2008, Ted Hardie wrote: > > Thanks for the pointer. I had missed this technical comment in the > crowd, and I think it is very important indeed. By re-using RRs with > context-specific semantics, the proposal does serious harm to > interoperability. Is there any evidence for that?

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

On Thu, 13 Nov 2008, Ted Hardie wrote: > > That's an example in which an A record in this zone has the standard DNS > meaning and the expectation is that you can use it construct a URI. > The other A records have a specific meaning in which the data returned > indicates that indicates something abo

RE: Context specific semantics was Re: uncooperative DNSBLs, was several messages

On Fri, 14 Nov 2008, Hardie, Ted wrote: > > Since you now have two different meanings for what an A record is, you > now need two different code trees that understand what A records are, > and those code trees are not interoperable. What do you mean by "interoperable" here? What would it mean for

RE: [BEHAVE] Lack of need for 66nat : Long term impactto applicationdevelopers

On Mon, 1 Dec 2008, Christian Huitema wrote: > > have we seriously consider flat host based routing in a corporate > network? A combination of DHT and caching technologies ought to make > that quite scalable. http://100x100network.org/papers/myers-hotnets2004.pdf "Rethinking the Service Model: Sca

Re: sockets vs. fds

On Fri, 5 Dec 2008, Dave CROCKER wrote: > Melinda Shore wrote: > > > > Not to go too far afield, but I think there's consensus among us old > > Unix folk that the mistake that CSRG made wasn't in the use of > > addresses but in having "sockets" instead of using file descriptors. > > This was actual

Re: The internet architecture

On Fri, 5 Dec 2008, Keith Moore wrote: > Stephane Bortzmeyer wrote: > > > > For a good part, this is already done. You cannot use IP addresses for > > many important applications (the Web because of virtual hosting and > > email because most MTA setup prevent it). > > you're generalizing about the

Re: The internet architecture

On Mon, 29 Dec 2008, Noel Chiappa wrote: > > I have been thinking this for some time too, and it's especially > true/clear when the multi-homing in question is site multi-homing, and > not host-multihoming (which is much rarer, is my impression). Most networkable consumer electronics ships with at

Re: The internet architecture

On Mon, 29 Dec 2008, Marshall Eubanks wrote: > On Dec 29, 2008, at 10:02 PM, Tony Finch wrote: >> On Mon, 29 Dec 2008, Noel Chiappa wrote: >>> >>> I have been thinking this for some time too, and it's especially >>> true/clear when the multi-homing in q

Re: The internet architecture

On Tue, 30 Dec 2008, Michael Richardson wrote: > Tony Finch wrote: > > > > The kind of multihoming I am talking about is where you are > > using multiple links for redundncy or resilience - i.e. the > > same reasons for site multihoming. > > I think it says som

Re: The internet architecture

On Thu, 1 Jan 2009, John Leslie wrote: > >I'm not at all clear what "support" of "multihoming" Tony is asking > for... I'm not clear either, because I don't know what mechanisms could make it work, especially not mechanisms that are deployable. But what we need is an addressing architecture t

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

On Thu, 12 Feb 2009, Jari Arkko wrote: > > I agree that there are problematic case, but I believe I hope everyone > realizes this is only the case if the RFC in question has code. > Otherwise it really does not matter. Only some RFCs have code. Except that it prevents using the text of an RFC as c

Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)

On Thu, 12 Feb 2009, Harald Alvestrand wrote: > > actually that's intended to be permitted by RFC 5377 section 4.2: Oh, that's nice :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

Re: Is round-trip time no longer a concern?

On Mon, 20 Feb 2006, Dave Cridland wrote: > > For IMAP, where connection setup time is, in principle, a very small part of > the total session time, it seems odd you're advocating that nobody should > worry about adding round-trips when there's been substantial effort in > reducing round-trips in p

RE: Best practice for data encoding?

On Mon, 5 Jun 2006, David Harrington wrote: > CERTR Advisory CA-2001-18 Multiple Vulnerabilities in Several > Implementations of the Lightweight Directory Access Protocol (LDAP) > Vulnerability Note VU#428230 Multiple vulnerabilities in S/MIME > implementations Oh yes, I forgot those were ASN.1

Re: Best practice for data encoding?

On Mon, 5 Jun 2006, Steven M. Bellovin wrote: > On Mon, 5 Jun 2006 16:06:28 -0700, "Randy Presuhn" > <[EMAIL PROTECTED]> wrote: > > > > I'm curious, too, about the claim that this has resulted in security > > problems. Could someone elaborate? > > See http://www.cert.org/advisories/CA-2002-03.html

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'ProposedExperiment: Normative Format in Addition to ASCII Text' toExperimental RFC (draft-ash-alt-formats))

On Thu, 22 Jun 2006, Iljitsch van Beijnum wrote: > > As someone else observed, my server adds an ISO-8859-1 header (thank you > Apache for guessing (wrong) what the file contains and then overwrite > what's specified in the file or what the client may guess correctly, > wasting a little bandwidth f

Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)

On Mon, 26 Jun 2006, Iljitsch van Beijnum wrote: > On 25-jun-2006, at 6:18, Keith Moore wrote: > > > Trouble is, in our current process, there's rarely any formal request > > for feedback, and little external visibility of a WG's output, until > > Last Call. > > But I see your point. When I first a

Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)

On Sat, 24 Jun 2006, Tim Bray wrote: > > When standards orgs go out to invent stuff in unexplored territory you get > disasters like OSI networking, CORBA, and in the current landscape, WS-*. I > suppose there are exceptions but I don't know of any. Speaking of CORBA: http://www.acmqueue.com/mod

Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

On Sun, 25 Jun 2006, Stephen Sprunk wrote: > Thus spake "Carl Malamud" <[EMAIL PROTECTED]> > > > > "RFC authors MUST NOT use calculus or matrix algebra. Addition and > > subtraction MAY be expressed as formulas but authors SHOULD NOT > > use formulations sufficiently complex to make a reader's hea

Re: security features.... (Re: Facts, please)

On Tue, 19 Sep 2006, Harald Alvestrand wrote: > > In fact TLS + HTTP Basic Auth is pretty interoperable, secure against quite a > few attacks, and widely deployed. But mostly ignored, because the user interface is dreadful. Practically all websites use one of the ad-hoc mechanisms that Russ referr

BCCed messages, was Re: IANA XML registries

Is anyone else being BCCed jefsey's messages, rather than receiving them via the mailing list? This is extremely irritating because I have had to adjust my killfile to block him more effectively. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GA

IETF-related spam from JFC Morfin

I have again received spam from JFC Morfin similar to the messages I complained about last week: http://www1.ietf.org/mail-archive/web/ietf/current/msg43675.html See the attached message whose headers claim that it has been sent to a couple of IETF lists, but which was actually BCCed as unsolicited

Re: IETF-related spam from JFC Morfin

On Thu, Sep 28, 2006 at 04:15:01PM +0200, Jefsey_Morfin wrote: > This mail was only sent to people I thought competent in language > issues. I apologise indeed for having counted you as one of them. > This will not happen again. Thanks for promising to desist. However you appear to have broken yo

Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys

On Wed, 22 Nov 2006, [EMAIL PROTECTED] wrote: > > SMTP, on the other hand is an operational failure and even today, no one > really knows how to properly implement and properly maintain an SMTP > service. The actions of criminals exploiting weaknesses in the SMTP > architecture have led to a series

Re: The 'failure' of SMTP RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys

On Wed, 22 Nov 2006, [EMAIL PROTECTED] wrote: > > Mail servers will still exchange messages with known and trusted peers. > A new mail server operator will have to arrange a trusted peer > relationship with one or more existing operators at some point in the > hierarchy. A mail user will have a tru

RE: SRV records considered dubious

On Wed, 22 Nov 2006, Hallam-Baker, Phillip wrote: > > For example every ISP has to spend time and money helping their > customers to configure their email clients to locate their POP3, IMAP > and SUBMIT servers. > > Those costs could be eliminated if email clients looked at the relevant > SRV recor

Re: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

On Thu, 11 Jan 2007, Dave Crocker wrote: > > As has been clear for some time, the OPES topic is both important and > difficult. That sort of combination always makes want to look for some > history of exerience with ways to solve the current problem. In the case > of OPES, I do not know of a quali

Re: submitting an ID

On Tue, 23 Jan 2007, Edward Lewis wrote: > > http://www.ietf.org/ietf/1id-guidelines.html > > In the section on IPR it says: > > # 9. Intellectual Property Rights > > Where in there is there a requirement to include the text mentioned below? Try looking at sections 3 and 4 which are also about IP

Re: Identifications dealing with Bulk Unsolicited Messages (BUMs)

On Sun, 18 Feb 2007, Harald Tveit Alvestrand wrote: > > If this was effective, blacklists would have solved the spam problem. They are 90% effective which I think is pretty good. You can't expect to eliminate spam, so using 100% effectiveness as a criterion for "solving the spam problem" is pointl

Re: Identifications dealing with Bulk Unsolicited Messages (BUMs)

On Wed, 21 Feb 2007, Brian E Carpenter wrote: > > Blacklists at the level of sending domains (or reputation systems > that function like blacklists) are a failure. I was talking about IP address blacklists. Perhaps 90% was a bit over-optimistic - my stats from cam.ac.uk show more than 80% of spam

RE: Identifications dealing with Bulk Unsolicited Messages (BUMs)

On Wed, 21 Feb 2007, Hallam-Baker, Phillip wrote: > The question Brian raised is not the percentage of spam that blacklists > catch, it's the false positive rate. Yes, you have to be careful about which blacklists you use and how you use them. The reputable ones (e.g. Spamhaus) have a negligible

Re: Identifications dealing with Bulk Unsolicited Messages (BUMs)

On Thu, 22 Feb 2007, Brian E Carpenter wrote: > > Interesting. Do they also run content filters? SpamAssassin deals with most of the rest. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ PLYMOUTH BISCAY FITZROY SOLE: SOUTH OR SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH

RE: Fwd: Pingsta Invitation

On Mon, 26 Mar 2007, John C Klensin wrote: > > In particular, none of [the "social network" tools] permit me to > maintain, with a single nominal identity, different circles of > acquaintances for different purposes and with different trust and > influence relationships between and within each, an

Re: Remote participation (re: identifying yourself at the mic)

On Tue, 27 Mar 2007, Nicolas Williams wrote: > It'd be nice if there was a way for remote participants who are able to > speak to do so. I've found that it's generally OK if someone is nominated to speak pertinent comments made by remote participants on jabber. Tony. -- f.a.n.finch <[EMAIL PRO

problems with I-D submissions

Would it be possible for the people who process I-D submissions to provide helpful error reports when bouncing a submission? Whenever I ask for clarification from them they just repeat the same unhelpful error message or close the ticket and ignore my emails. For example, draft-fanf-smtp-quickstar

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

On Wed, 11 Apr 2007, Jari Arkko wrote: > > Do you have examples of licenses/IPR declarations that work better with > GPL and other forms of open source? Something for Mark and the rest > of us to use as a model, perhaps? A recent slap given by Apache to Sun

Re: Use of LWSP in ABNF -- consensus call

On Mon, 14 May 2007, Dave Crocker wrote: > > "Could cause problems in other places"... The DKIM hiccup was the first > one I'd heard about. > > By contrast, "linear-white-space" was defined in RFC733, in 1977, with > RFC822 retaining that definition. It is defined in those places as > e

Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

On Tue, 15 May 2007, Dave Crocker wrote: > > So that is a total of at most 2 documented cases in 10-30 years. > And keep in mind that the issue is not that the rule "does not work" but that > it is very rarely mis-used. Did you miss my post linking to a description of LWSP-related interop problems

Re: Use of LWSP in ABNF -- consensus call

On Wed, 16 May 2007, John C Klensin wrote: > > 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 document. > > (2) From tha

Re: Design of metalanguages (was: Re: Use of LWSP in ABNF -- consensus call)

On Wed, 16 May 2007, John C Klensin wrote: > > I find grammatical metalanguages more understandable (and readable) when > there is exactly one way to write a given construction (for example, no > implied terms in ranges), when the constructions are very precisely > defined, and when the number of c

Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

On Thu, 17 May 2007, John C Klensin wrote: > > Is this construction dangerous if used in inappropriate > contexts? Sure. Does that justify a warning note to the > unwary? Probably. Is it possible to implement other things and > call them by the same name (i.e., create a non-conforming > impleme

Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

On Thu, 17 May 2007, John C Klensin wrote: > > (1) Other specifications that use the term "LWSP" to > refer to something different from what is unambiguously > defined in the ABNF spec. > > [This] group is, IMO, just broken. I agree with your sentiment but sadly there's a lot of

Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

On Thu, 17 May 2007, John C Klensin wrote: > > After all Thing could case similar problems if > some construction permitted it ... This is not news. There have for a long time been problems with significant trailing space, which is why CRLF 1*WSP CRLF in a header is part of the obs- syntax of 28

Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

On Fri, 18 May 2007, John C Klensin wrote: > On Friday, 18 May, 2007 09:00 +0100 Tony Finch <[EMAIL PROTECTED]> > wrote: > > > > NTWSP = [CRLF] 1*WSP ; non-trailing white space > > Sure. Except that much, if not most, of our textual > descriptions of these pr

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

On Fri, 8 Jun 2007, Stephane Bortzmeyer wrote: > > Side note: on Unix, will cron be forced to authenticate to send emails > at 2 am? :-) cron sends email by invoking sendmail, which knows the user that invoked it. authentication is therefore automatic and has been the norm for ever. Tony. -- f.a

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

On Sun, 10 Jun 2007, william(at)elan.net wrote: > > Sendmail does not authenticate automatically or otherwise. What it does > is to use as RFC2821 MAIL FROM account of the user that invoked it or > when "-f" option is used puts out account of the user in the trace data. > > This is not authenticati

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

On Sun, 10 Jun 2007, Ned Freed wrote: > > My one concern is with the recommendation that MSAs by default try the > submit port first and if that fails fall back to port 25. I have no > problem with recommending a submit port configuration - it's the > fallback process that concerns me. In my ideal

Re: Withdrawing sponsorship of draft-housley-tls-authz-extns

On Tue, 12 Jun 2007, Dave Crocker wrote: > > Nothing prevents the document from being submitted directly to the RFC Editor, > for publication as a non-IETF document. ... except that TLS extensions require IETF consensus ... Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FORTIES CROM

Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)

On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote: > > Cases like managesieve. Managesieve is almost a decade old and in real > use at many sites. Tens of thousands? Even more? No idea. The port it > uses was allocated to another purpose about four years after managesieve > was deployed. The smtps port

Re: Last Call: draft-ietf-lemonade-rfc2192bis (IMAP URL Scheme) to Proposed Standard

On Mon, 18 Jun 2007, Ted Hardie wrote: > > I think we're in real danger of going down a very deep rathole. We can start > dancing on the "what is code" pin-head and hope to avoid it, but it's a pretty > faint hope. The solution to that is to grant the same freedoms to all kinds of text in RFCs.

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

On Thu, 21 Jun 2007, John C Klensin wrote: > > (2) Section 3.1 contains a MUST requirement for availability of the > message submission port (RFC 4409). While I am a firm believer in RFC > 4409 and look forward to the point at which we can put out a document > that deprecates the use of SMTP (RFC

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

On Thu, 21 Jun 2007, John C Klensin wrote: > > But, as an illustration of my problem, let's compare the above with the > later text about Submission servers (MSAs) supporting both Submit and > SMTP. I suggest (and I hope my comments made clear) that the *best* > practice there is for the MSA opera

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

On Thu, 21 Jun 2007, John C Klensin wrote: > > Hmm. Since a few providers, at least one of them quite large, > have already imposed "find an MUA that supports authentication > or go elsewhere" requirements without being driven out of the > marketplace or even suffering any noticeable pain, I didn'

Re: e2e

On Wed, 15 Aug 2007, 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. Of course, all reputation services are equally incompetent. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA:

Re: e2e

On Thu, 16 Aug 2007, Gunnar Lindberg wrote: > > Only accept incomming SMTP from hosts/networks you trust and/or have > some kind of formal agreement with. The difference between a whitelist model and a blacklist model is just toggling a billion bits. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> ht

  1   2   3   >