From owner-ietf-mta-filters@mail.imc.org Wed Sep 5 21:18:42 2007 X-mallorn-MailScanner-Watermark: 1189646321.88024@yBK6JKs0NAEChonQX2UZWQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l861IYpa015549 for ; Wed, 5 Sep 2007 21:18:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8615hjZ071950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2007 18:05:43 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8615hA9071949; Wed, 5 Sep 2007 18:05:43 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8615f0t071943 for ; Wed, 5 Sep 2007 18:05:42 -0700 (MST) (envelope-from fluffy@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Sep 2007 18:05:40 -0700 X-IronPort-AV: i="4.20,213,1186383600"; d="scan'208"; a="520924253:sNHT109719220" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8615fVx008244; Wed, 5 Sep 2007 18:05:41 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l8615JxK001625; Thu, 6 Sep 2007 01:05:23 GMT In-Reply-To: <01MKSZDVMDIG00005F@mauve.mrochek.com> References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3146F85A-44F2-426F-9320-960D50A43E6B@cisco.com> Cc: ietf-mta-filters@imc.org, Lisa Dusseault , iesg@ietf.org, Alexey Melnikov , Philip Guenther Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt Date: Wed, 5 Sep 2007 18:03:50 -0700 To: Ned Freed X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23464; t=1189040741; x=1189904741; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Suggested=20changes=20to=20address=20Cullen's=20DISCU SS=20on=20draft-ietf-sieve-3028bis-12.txt |Sender:=20; bh=dQf96CS5PIF62ntxU3SwwTRaKS2FWsSk6GGKhMzWN8c=; b=oj6GWsMLcL8fSENktGXDWiwdvygtjLo53W71uRtjKl7zSwo1HApBuwZ+qM/ARd4CmMtxncmH IpFUnIjz47Z0jA8uhSjHRD3onKsCoJzmzP3iuq2rn+ucgVxcEfP8oUt9v5729ntAiHAw8kp/zk EtbRZNi1mC9zTXWUx65uTlB7k=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean X-Deliver-To: ehood Content-Length: 22868 Lines: 598 I think we are talking past each other a bit so it might be very helpful to have a phone call at some point. Let me make sure that I got what you are saying here at the high level - I think your position is roughly the following: If implementors follow the advice that Lisa put in the RFC Ed note (what Alexey and you had sent), then it is still possible to have massive mail bomb style attacks using SIEVE but in practice this is not an issues because of a few things including 1) it is not the weakest link of the email infrastructure and other things are attacked first 2) it is no worse than currently deployed things 3) logging can help with removing the the offending accounts after the fact. By massive here I mean something more like 2^100 not 100 messages. Do I have that about right? On Aug 30, 2007, at 7:37 PM, Ned Freed wrote: >> > As a specific example, I have >> > email accounts at Sun, on my home systems, Gmail, and a bunch of >> > other places. >> > All, I repeat _all_, of these services allow me to easily configure >> > autoforwarding to multiple destinations. > >> Uh - you sure. > > Yes, as a matter of fact I am sure. I try very hard not to make > assertions > without the facts to back them up. > >> I'm not aware how to make gmail go to multiple system > > It's trivial. Hit the settings tab at the top right and then create > two > filters. Use whatever critera you like and have one that forwards > to address A > and the other to address B. Before I included gmail in my response > I tested > this with two non-gmail accounts I have elsewhere and gmail happily > forwarded a > test message to both. No warnings, no problems, just two copies of > the mail. I > just checked my account again just now and the both forwards are > still in place > and working. Here's approximately what my settings page has to say > about it: > > The following filters are applied to all incoming mail: > Matches: subject: vvv > Do this: Forward to xxx.xxx@yyy.yyy > > Matches: subject: vvv www > Do this: Forward to zzz.zzz@aaa.aaa > > I can't really talk about the specific ISPs we have as customers > and their > policies, but I can assure you gmail is not alone in offering this > capability > to their users. To the extent offerings differ, the difference > seems to be > whether or not users are allowed to configure custom filters at > all, not > whether or not setups that allow custom filtering configuration can > forward. > Hotmail, for example, effectively doesn't offer custom filter > settings, so it > is hardly surprising that they don't offer forwarding. > >> which is of course the important one because the others systems have >> relationships with you and other ways to secure things by causing bad >> consequences for you if you abuse the system. > > I don't believe this is as much of a difference as you seem to > think. Quite a > few of the cases of mailbombing I've seen have been disgruntled > employees and > the like attacking their own company's systems. (AFAIK none of them > involved > the use of sieve redirect, but that's really beside the point.) > Apparently > nothing says "I quit" quite like a mailbox with 10 million pieces > of hate mail > in it. > >> > If memory serves, your suggested way to prevent it was to allow at >> > most one redirect operation to be done during the execution of a >> sieve >> > script. > >> Well, what I have in my notes from the prague meeting was "Told them >> I was OK with SHOULD not redirect to more than one location outside >> the domain". > > And I responded that I think that goes too far and isn't > reasonable. In > particular, a SHOULD that fails to take into account that there are > legitimate > use-cases for mutlple redirects makes the entire specification look > incompetent > and serves to weaken the effectiveness of all the other advice we > give. > >> We may have different ideas about what domain means but >> roughly I would mean administrative domain - certainly I would call >> an enterprise or large bank one domain even thought they might have >> separate DNS domain names for different locations or something. You >> might use the term "onsite" where I used domain. > > I don't think the restriction to a single domain, regardless of > what domain > means, accomplishes nearly as much as you seem to think it does. > Again, to the > extent mailbombing is an issue, in my experience it's as much of > one within an > ADMD as outside of it. Perhaps more. > >> > And you've been told that this is simply not acceptable - there >> are too >> > many use cases for forwarding email to two different places at >> once. > >> Actually, I have received very little comment on if this is >> acceptable or not. I have mostly recieved something that loosely >> translated to "the WG disagrees with your discuss". I would be very >> happy to talk what my concerns are and have folks figure out if their >> is a solution that addresses them and still meets the bulk of users >> needs. > > Then there has been a disconnect getting WG comments back to you. > Several > comments were in fact made, including but not limited to one from me. > >> > In fact this is an >> > incredibly common thing for people to do for all sorts of >> > legitimate reasons, >> > including but not limited to: > >> I suspect what I had proposed meets all these use case but don't >> claim to really know. Glad to be educated. > > OK, let's go down the list and see how ADMD restrictions fare: > >> > (1) Making messages accessible in multiple ways, e.g. send one >> copy to >> > my email account and another to my pager. Or voice mail. Or >> printer. >> > Or FAX. > > A very common case is for pager, fax, or voice mail services to be > outsourced > to an external service provider. Often as not different people in > the org will > use different providers for this stuff. This is especially true if > we're > talking about a hosted setup. ADMD restriction cannot possibly work > here. > >> > (2) Secretaries who need copies of their boss's email. > > ADMD restriction are mostly compatible with this use-case. > >> > (3) Maintaining multiple mailboxes during a service transition >> > period. Or two pagers. > > This would depend on the nature of the transition. I've seen > transitions to > another ADMD as well as transitions within an ADMD. Domain > restrictions are > problematic in this case. > >> > (4) Making backup copies of mail to address reliability issues (IMO >> > this is not the best way to solve this problem but it is >> commonly done >> > this way regardless of what I think). > > In many cases the entire point of doing this sort of thing, > especially at the > user level, is to get a copy of your mail to a place that has separate > administative controls. ADMD restrictions would be hugely problematic > for this use-case. > >> > (5) Making copies of stuff for law enforcement use (garden variety >> > forwarding is a piss-poor way to implement this but it is >> nevertheless >> > something people do fairly often). > >> (uh, yah, laughing about how well this will meet some US Law >> enforcement requirements :-) > > I can't get into details, but the truly amazing thing is that I've > seen > situations where law enforcement _insisted_ on it being done this > way even > when a technically superior solution was available. (I'm actually > writing a > response to a proposal that's basically a variant of this idea in > another > window.) > > I don't actually know if the cases where this has been done involve > forwarding > outside the ADMD or not. (To be honest, I try very hard to learn as > little > about the operational details of interception activities as I > possibly can.) > But given the complete lack of clue needed to even consider using > this approach > I would not be at all surprised if such forwarding has been done in > this case. > >> > (6) Vacation-time forwarding of important messages to the "next >> > tier" of handlers. > > This is usually done inside the ADMD but not always. > > Tallying up, restricting autforwarding by domain didn't fare so > well against > this list of use-cases. So we're talking about a mechanism that is > ineffective > against a significant subset of actual attacks as well as being > incompatible > with a lot of completely legitimate things people like to do. > > Yet another problem with domain restrictions is that it is easy for > them to > turn into a violation of the least astonishment principle. ADMD > boundaries can > be complex - I've seen setups that consider thousands or tens of > thousands of > domains as local - and asking users to understand complex > boundaries is in > effect asking for a lot of support calls. And SPs will do almost > anything to > lessen the number of support calls they get. > >> ... > >> I'm not surprised - this all seems very consistent with my >> discussions to these types of folks. I assume you also have the >> discussions with the people like Yahoo, MSN, gmail, around the >> policies they put in place to stop their servers from being used in >> DOS attacks? > > The people I talk to tend to be large ISPs rather than these sorts > of SPs, but > yes, we talk about DOS attacks a fair amount. However, the issue of > the ISPs > own infrastructure being used in the ways you envision for DOS > attacks has > almsot never come up, for the simple reason that it is not a > significant issue > for them. > >> I know I have been dragged into a few theses - can you >> provide some insight around policies there? > > OK, let's look at email DOS attacks in a bit more detail. Let's > start with what > sounds like a silly question: What does an MTA do? The answer, of > course, is > that it transfers messages around. It follows that if an MTA is > good at its job > it has to be able to accept and process messages fairly quickly. > And this is in > fact the case: It isn't at all difficult to get performance of 50 > messages/second on a single box. With a little more effort you can > kick things > up into the 500 messages/second realm (the main issue at this point > is spam and > virus scanning performance) and MTAs have been built that can > handle well over > 2000 messages/second (at this point threads and filesystem > performance become > the bottleneck, requiring a bunch of exotic tricks to deal with). > > MTAs are also built defensively, and the primary defensive stategy > is to try > and stop the bad stuff as close to the security perimeter as > possible. The > further in stuff gets the more resources have to be expended > dealing with it. > For example, when a user goes seriously over quota the best thing > to do is turn > back mail with a 4yz (temporary) error, not accept it and hold it > until they go > under quota again. Various rate limiting strategies are useful here > as well and > in practice are widely deployed. So unless your attack has both a > distributed > source and destination there's a very good chance it will be > quickly detected > and blocked. > > The bottom line is that modern MTAs are very good at handling lots > legitimate > SMTP transactions and take all sorts of steps to prevent themselves > from being > overwhelmed by too many of them. So attacking the email > infrastructure by > performing lots of real transactions is in effect a frontal attack > against the > most heavily fortified part of the entire system. This is not a > recipe for > success. > > So if frontal attacks don't work very well, what does? What we > commonly see are > attacks on various server resources: Connections, threads, > processes, memory > and disk. If an attacker can consume enough of some resource they > can bring the > servers down or at least make them very slow. For example, one > attack we saw a > while back was to send an infinitely long message - some MTAs > buffer messages > in memory and done right this could consume all available swap > space and hang > the server. Or there's the trick of opening lots of connections but > never > sending any data. Or stopping in the middle of the transaction. > (This one is > apparently popular right now - I have no idea why.) Or sending > commands R E A L > L Y S L O W L Y. Or attacking the network stack with malformed > packets, > incomplete TCP exchanges, and so on. Or simply overwhelming the > network itself > with data. Or causing the MTA to overlaod some other service, e.g. > kill the > directory server by sending lots of RCPT TOs and forcing lots of > lookups. Or > exploiting some known flaw in a particular implementation, e.g. > blowing a vital > cache by doing something to invalidate its content. The list is > long, and if > the attacker is highly distributed some of these are very difficult > to defend > against. > > But now let's consider where autoforwarders fit into this attack > tree. First of > all, since email is store and forward you cannot get an > autoforwarder to > perform anything but an actual transaction, corresponding to a > direct frontal > attack - exactly the attack MTAs are best at preventing. Even worse > (for the > attacker), autforwarders don't provide an attacker with much > flexibility in > terms of either distributing either the source or destination of > the attack: > Automating account and filter creation is in most cases difficult > if not > impossible, making the task of getting enough autoforwarders in > place very time > consuming and error prone, and most autoforwarders, including Sieve > redirect, > can only forward to a fixed set of destinations - the redirection > cannot go to > an address that's pulled out of the message itself. (The sieve > variables > extension changes this, but the topic at hand is what's possible in > the Sieve > base specification, not what some extension allows.) Finally, the > people who > offer autoforwarding as part of their service are as a general rule > not morons > and will probably notice if a large volume of email starts coming > in only to be > forwarded right back out. > > The bottom line is that, your beliefs to the contrary notwithstanding, > autoforwarders just aren't that interesting of a tool for > attackers. This has > been largely true throughout the history of email, and in the > present world of > botnets it is more true than ever. The folks at Cloudmark (who know > far more > about the attack landscape than I do) told me a couple of weeks ago > that the > botnets out there are now so large that devastating results can be > had even if > each infected system only sends out 5-6 messages a day. Given this > why would > any attacker even bother making autoforwarders part of their attack > toolkit? > >> >> I believe that >> >> the IETF has clear consensus that it does not want to deploy >> >> technology that could trivially be used for large scale DOS and >> >> message amplification attacks with very little safeguards or >> >> traceable ways of dealing with this. >> > >> > This presupposes that there's a real risk here and that the >> necessary >> > safeguards are not in place. I don't believe either of these are >> true. > >> So far no one as sent me any information arguing these are not true. > > Say what? My responses have contained exactly this sort of > information and > argument. And AFAICT you have yet to effectively refute a single > point I have > made. > >> > > Now my current judgement call is >> > > that this is in that category and could cause harm to the >> internet. > >> > But we're not dealing with a new protocol with zero operational >> experience here >> > where such judgement calls are our only means of assessing >> possible risk. >> > Rather, we're not only dealing with a protocol that has >> signifcant deployment >> > and operational experience, we're talking about a particular >> feature that's >> > been an integrall part of email for decades and is accessible in >> all sorts of >> > ways besides Sieve. > >> Sure - and clearly if it is not a problem, it is stopped somehow, I'm >> asking the Security section to provide some advice about how this is >> all stopped. > > Leaving aside that this is a fairly significant change in position > on your > part, the problem with this is that your reasoning rests on an > unwarranted > assumption: That the reason it is not a problem is because people > have taken > specific steps to prevent autoforwarder abuse. The fact of the > matter is they > haven't done this. What has happened instead is that the myriad of > other > measures people have taken to prevent attacks on the email > infrastructure have > collectively managed to make autoforwarders a fairly uninteresting > tool for > attackers. > >> > First, nobody is claiming that autoforwarders cannot be used as >> an amplifying >> > component in various sorts of attacks. They can be used this >> way. This was true >> > for email decades before Sieve came along and it will continue >> to be true no >> > matter what we do in this document. > >> yet somehow widespread message amplification attacks from email are >> mitigated to an currently acceptable level. > > Yes, because the measures people take to defend against other, far > more > pernicious attacks end up defending against autoforwarders > vicariously. > Defending against mail loops, for example, does more to limit the > effectiveness > of autoforwarders as an attack mechanism than any other step you > can take. But > if you don't have reasonable loop detection in place you will > quickly find that > autoforwarders are the least of your problems. > >> > Second, nobody is claiming that script analysis can be used to >> prevent people >> > from abusing Sieve as part of such attacks. It simply cannot be >> done. > >> agreed - let's make sure the draft does not suggest people do it > > I have no problem with that. > >> > More generally, the days where email systems can get away >> without producing >> > comprehensive logs and audit trails ended a long time ago. I >> have no idea >> > what you're basing your assertions that such attacks would >> not be tracable >> > in modern email systems, but it runs absolutely contrary to >> all of my >> > recent experience. > >> Certainly agree with you in enterprise case but in a public provider >> such as yahoo, sure they have logs but they may not have any way to >> tying that to an actually human associated with the account. > > But even if they had the information they still aren't going to go > after most > abusers - law enforcement could not care less about this stuff and > a civil suit > is way too much trouble for way too little gain. All they're going > to do is > shut down the account. > > BTW, the same is often true in the enterprise case: If some guy > uses a mailbomb > to say "I quit" the odds are pretty good the company will simply > clean up the > mess and move on. > > In any case, the point of having good logs is to be able to > identify and stop > bad behavior. Catching and punishing the person responsible is a whole > different matter. > >> This is great - few bits inline below... > >> > Allowing a single script to redirect to multiple destinations >> can be >> > used as a means of amplifying the number of messages in an >> attack. >> > Moreover, if loop detection is not properly implemented it >> may be possible >> > to set up expontentially growing message loops. Acording, Sieve >> > implementations: >> > >> > (1) MUST implement facilities to detect and break message >> loops. See >> > RFC 2821 section 6.2 for additional information on basic >> loop >> > detection strategies. > >> My discuss did not ask for this but it certainly seems like a good >> idea. > > Alexey already pointed out that you did in fact ask for this. > >> > >> > (2) MUST provide the means for administrators to limit the >> ability of >> > users to abuse redirect. In particular, it MUST be >> possible to >> > limit the number of redirects a script can perform. >> Additionally, >> > if no use cases exists for using redirect to to multiple >> destinations, >> > this limit SHOULD be set to 1. Additional limits, such >> > as the ability to restrict redirect to local users MAY >> also be >> > implemented. > >> We are very close here. If you changed the "Additionally if no use >> cases exists for using redirect to to multiple destinations this >> limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most >> one redirect that is not 'onsite'". And define onsite somewhere. I'd >> point out that this is a SHOULD not a MUST and that it could be >> ignored if people understood the security implications of what they >> were about to do. This could also possibly be coupled with idea after >> next point to explicitly allow multiple redirects in some cases. > > My problem with this is that "onsite" or "within the domain" or > whatever should > not be conflated with limiting the extent to which users are > allowed to use > redirect. I actually think you have substantially weakened the > impact of this > guidance by over-emphasizing domain restrictions. > >> > (3) MUST provide facilities to log use of redirect in order >> to facilitate >> > tracking down abuse. > >> I would ask if this mean that they MUST know what human the script >> was associated with. If yes, it is way beyond what I am asking for >> and if no then hard to see how it helps. > > On the contrary, this is arguably the most useful advice we have to > offer. Real > time as well as offline analysis of logs is in practice one of the > primary > tools that's used to find and eliminate email abuse. We actually > spend at least > as much time advising our large ISP customers on how to do this more > effectively than we do on how to set up rate limiting or any other > sort of > defense. (And as I mentioned previously, our ISP customers have > demonstrated no > interest whatsoever in administrative limits on redirect. And we'd > know because > it turns out the limit option wasn't documented.) > >> When I mentioned months ago >> I could imagine many ways to solve this, coupling this type of thing >> to the ability to do more than one redirect was one of the things >> that seemed like a possible solution (and corresponds to my >> understanding of at least some current deployments). > > In conclusion, Alexey has proposed new text in a separate messagage > which > I find completely acceptable. Please take a look at that and let's see > where we are. > > Ned From owner-ietf-mta-filters@mail.imc.org Fri Sep 7 18:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=4.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.1.7 X-mallorn-MailScanner-Watermark: 1189818347.9065@y5FjPr5yfLVB9AQcu5XsSg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Fri, 07 Sep 2007 18:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8815gj3002936 for ; Fri, 7 Sep 2007 21:05:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l880sOWE036019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 17:54:24 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l880sOu6036018; Fri, 7 Sep 2007 17:54:24 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l880sLcj036012 for ; Fri, 7 Sep 2007 17:54:22 -0700 (MST) (envelope-from Chris.Newman@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l880sLA1004089 for ; Sat, 8 Sep 2007 00:54:21 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO000M01YAYTG00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ietf-mta-filters@imc.org; Fri, 07 Sep 2007 18:54:21 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO000I5YYIHK000@mail-amer.sun.com>; Fri, 07 Sep 2007 18:54:21 -0600 (MDT) Date: Fri, 07 Sep 2007 17:55:14 -0700 From: Chris Newman Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt In-reply-to: <3146F85A-44F2-426F-9320-960D50A43E6B@cisco.com> To: Cullen Jennings , Ned Freed Cc: ietf-mta-filters@imc.org, Alexey Melnikov , Lisa Dusseault , iesg@ietf.org, Philip Guenther Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> <3146F85A-44F2-426F-9320-960D50A43E6B@cisco.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Cullen Jennings wrote on 9/5/07 18:03 -0700: > I think we are talking past each other a bit so it might be very helpful to > have a phone call at some point. Let me make sure that I got what you are > saying here at the high level - I think your position is roughly the > following: > > If implementors follow the advice that Lisa put in the RFC Ed note (what > Alexey and you had sent), then it is still possible to have massive mail > bomb style attacks using SIEVE but in practice this is not an issues because > of a few things including 1) it is not the weakest link of the email > infrastructure and other things are attacked first 2) it is no worse than > currently deployed things 3) logging can help with removing the the > offending accounts after the fact. By massive here I mean something more > like 2^100 not 100 messages. > > Do I have that about right? [speaking as a technical contributor, not an AD] I believe you have that about right. Indeed if you delete the first phrase and the text "using SIEVE" it states the present and historical behavior of the email system with .forward files, procmail and various other MTA-level forwarding/filtering mechanisms that have existed for decades and continue to be widely deployed and widely used. This is one of the many cases where customers demand power tools that can be used to cause harm. Quick and dirty attempts to make those tools harmless will also make them unacceptable to customers. If our security considerations make unrealistic recommendations that vendors must ignore, that makes vendors that much more likely to ignore all the security considerations we write. I consider our specifications higher quality if we limit ourselves to realistic recommendations and avoid the impractical ones. For now, we have years of real world experience demonstrating that received counting and logging are sufficient mitigation for this threat in today's world. Here's an analogy: Cars are very dangerous. It would save thousands of lives if we banned cars from driving on highways. Is that a good mitigation for the threat? - Chris From owner-ietf-mta-filters@mail.imc.org Sun Sep 23 07:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.7 X-mallorn-MailScanner-Watermark: 1191160783.8985@dhaHGarZzaisjh0P/cYKhw X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 23 Sep 2007 07:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8NDxbTI014268 for ; Sun, 23 Sep 2007 09:59:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDgxNx065176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 06:42:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8NDgxOo065175; Sun, 23 Sep 2007 06:42:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDgvhj065168 for ; Sun, 23 Sep 2007 06:42:58 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:42:53 +0100 Message-ID: <46F58579.70701@isode.com> Date: Sat, 22 Sep 2007 22:13:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf-mta-filters@imc.org CC: Ned Freed , Cullen Jennings , Lisa Dusseault , iesg@ietf.org Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> In-Reply-To: <01MKSZDVMDIG00005F@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ned Freed wrote: >> When I mentioned months ago >> I could imagine many ways to solve this, coupling this type of thing >> to the ability to do more than one redirect was one of the things >> that seemed like a possible solution (and corresponds to my >> understanding of at least some current deployments). > > In conclusion, Alexey has proposed new text in a separate messagage which > I find completely acceptable. Please take a look at that and let's see > where we are. Here is the proposal Ned was referring to: In section 4.2, add a sentence to the end of 3rd paragraph: OLD: The envelope sender address on the outgoing message is chosen by the sieve implementation. It MAY be copied from the message being processed. NEW: The envelope sender address on the outgoing message is chosen by the sieve implementation. It MAY be copied from the message being processed. However, if the message being processed has an empty envelope sender address the outgoing message MUST also have an empty envelope sender address. In section 4.2, last paragraph: OLD: Implementations SHOULD take measures to implement loop control, ^^^^^^ possibly including adding headers to the message or counting Received headers. If an implementation detects a loop, it causes an error. NEW: Implementations MUST take measures to implement loop control, ^^^^ possibly including adding headers to the message or counting Received headers as specified in section 6.2 of [SMTP]. If an implementation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ detects a loop, it causes an error. Add to the end of section 4.2 two new paragraphs: Implementations MUST provide means of limiting the number of redirects a Sieve script can perform. See Section 10 for more details. Implementations MAY ignore a redirect action silently due to policy reasons. For example, an implementation MAY choose not to redirect to an address that is known to be undeliverable. An ignored redirect MUST NOT cancel the implicit keep. In section 10, replace 2nd paragraph: OLD: It is equally important that implementations sanity-check the user's scripts, and not allow users to create on-demand mailbombs. For instance, an implementation that allows a user to redirect a message multiple times might also allow a user to create a mailbomb triggered by mail from a specific user. Site- or implementation-defined limits on actions are useful for this. NEW: Allowing a single script to redirect to multiple destinations can be used as a means of amplifying the number of messages in an attack. Moreover, if loop detection is not properly implemented it may be possible to set up exponentially growing message loops. According, Sieve implementations: (1) MUST implement facilities to detect and break message loops. See RFC 2821 section 6.2 for additional information on basic loop detection strategies. (2) MUST provide the means for administrators to limit the ability of users to abuse redirect. In particular, it MUST be possible to limit the number of redirects a script can perform. Additionally, if no use cases exist for using redirect to multiple destinations, this limit SHOULD be set to 1. Additional limits, such as the ability to restrict redirect to local users MAY also be implemented. (3) MUST provide facilities to log use of redirect in order to facilitate tracking down abuse. From owner-ietf-mta-filters@mail.imc.org Sun Sep 23 07:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.7 X-mallorn-MailScanner-Watermark: 1191160880.37931@BMgNMP2G4avuOdpa5swhsg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 23 Sep 2007 07:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8NE1EHT014426 for ; Sun, 23 Sep 2007 10:01:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDhaZl065232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 06:43:36 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8NDhafw065231; Sun, 23 Sep 2007 06:43:36 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDhZGY065225 for ; Sun, 23 Sep 2007 06:43:36 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:33 +0100 Message-ID: <46F59450.8060603@isode.com> Date: Sat, 22 Sep 2007 23:16:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf-mta-filters@imc.org CC: Cullen Jennings , Ned Freed , Lisa Dusseault , iesg@ietf.org Subject: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2 References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> <46F58579.70701@isode.com> <46F587A2.1030804@isode.com> In-Reply-To: <46F587A2.1030804@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean After talking to Cullen Lisa thinks that one or two of the following changes should address Cullen's DISCUSS (I assume that the text I've suggested earlier should be included in some form into 3028bis anyway, this is in addition to this): 1). Limit applicability of SIEVE, e.g. to deployments where administrators can disable accounts abusing scripts. 2). Add text with helpful guidance about script analysis or forking detection. 3). Add requirements for use of mail headers to more reliably detect forking. ======= So here is some background on the three choices and are my comments on them (strictly as an individual contributor). 1). This is really no brainer. Any deployed mail system should have a way to disable accounts. I would suggest adding the following: Sieve implementations MUST provide facilities to allow administrators to disable accounts abusing scripts. Cullen, does this satisfy you? 2). Ned wrote in a separate email about # 2: > Script analysis is one of those tri-state things. It can conclude that: > > (1) A script is harmless. > (2) A script is harmful. > (3) The script cannot be analyzed. > > Now, in practice the _overwhelming_ majority of actual scripts will > fall into > one of the first two categories. This is especially true when scripts are > created by a GUI - GUIs tools tend to construct straightforward > scripts without > any of the complexities that hinder analysis. > > And even when the conclusion is (3), that actually tells you something. A > really sophisticated system might even note the presence of a highly > complicated script and watch even more carefully for abuse. > > Heck, even a very naive analysis can be useful. For example, to the > extent > redirect offers capabilities beyond those of a .forward file, they > only arise > when the address redirect sends the message to can be controlled by > the message > itself. For that you really need Sieve variables (and hence this is > out of > scope for the Sieve base specification). So one very simple thing you > can do is > look for the use of variables and the presence of ${} constructs in > redirects. > A setup that allows users to configure arbitrary sieves might want to > check for > this combination and either disallow or flag it in some way. I don't think the discussion about looking for variables in the redirect address belongs to the 3028bis, because 3028bis itself has no variables. Apart from that something along the lines of Ned's text can be included. 3). [I hope that the following is not too cryptic for people to understand. If it is, I can try to provide a more detailed explanation later.] Lisa has suggested in a private email a new header field (Mail-Fork-Estimation) that can be used to convey the estimated total number of redirects that happened so far as estimated at the previous hop. The value of this header is multiplied by the number of redirects that happens at the current hop and if it is bigger than 100, the message is going to be dropped at the next hop. So this is similar to counting Received headers, but compensates for multiple redirects. While I think this might be a neat research idea and should be published as a draft, I have a problem with mandating this in 3028bis: 1). If this is mandated in 3028bis, this would take some time to deploy. This would also render *all* existing implementations non-compliant, which is not a good thing. While I can see that this might help in the future, I don't think it is necessary and 2 other approaches (script analysis and abuse detection+script disabling) already work quite reasonably 2). This proposal changes how redirect has to be implemented by many implementations. Currently for some implementations a redirect can be a fire-and-forget operation (after adding it to logs). The actual message submission is performed asynchronously. Your proposal will require that all redirects for all users (a single message can be destined to multiple recipients and all of them can have Sieve scripts) are to be performed by an MTA at one moment, because all of them will have to have the same Mail-Fork-Estimation header field. In Sieve WG we have many different implementations and we were trying vary carefully not to put unnecessary requirements on implementations. ==== To summarize: I personally disagree that # 3 is a solution suitable for 3028bis. I agree that some combination of 1 and 2 is reasonable. I would need some help to come up with text covering # 2. Regards, Alexey From owner-ietf-mta-filters@mail.imc.org Sun Sep 23 07:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.7 X-mallorn-MailScanner-Watermark: 1191161042.83666@uhb9+exg0GoEdXdDSVxdqQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Sun, 23 Sep 2007 07:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8NE3rIX014831 for ; Sun, 23 Sep 2007 10:03:58 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDh7aE065197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 06:43:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8NDh7Q3065196; Sun, 23 Sep 2007 06:43:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDh6qT065188 for ; Sun, 23 Sep 2007 06:43:06 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 14:43:00 +0100 Message-ID: <46F587A2.1030804@isode.com> Date: Sat, 22 Sep 2007 22:22:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf-mta-filters@imc.org, Cullen Jennings CC: Ned Freed , Lisa Dusseault , iesg@ietf.org Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> <46F58579.70701@isode.com> In-Reply-To: <46F58579.70701@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Alexey Melnikov wrote: > Ned Freed wrote: > >> In conclusion, Alexey has proposed new text in a separate messagage >> which >> I find completely acceptable. Please take a look at that and let's see >> where we are. > > Here is the proposal Ned was referring to: And considering that the issue about Turing-completeness keep coming back, I suggest one more additional change: In Section 1, 2nd paragraph, replace last sentence: OLD: The base language is intentionally not Turing-complete: it provides no way to write a loop or a function and variables are not provided. NEW: The base language was not designed to be Turing-complete: it does not have a loop command or function syntax. From owner-ietf-mta-filters@mail.imc.org Mon Sep 24 23:27:07 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,FORGED_RCVD_HELO,SUBJ_HAS_SPACES autolearn=no version=3.1.7 X-mallorn-MailScanner-Watermark: 1191303723.65969@kXYcwLvg2S2guZVjSBL/sA X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 24 Sep 2007 23:27:07 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8P5fuQM019703 for ; Tue, 25 Sep 2007 01:42:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8P5UqEi009853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 22:30:52 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8P5Uqjv009852; Mon, 24 Sep 2007 22:30:52 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8P5UnFl009836 for ; Mon, 24 Sep 2007 22:30:51 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from [192.168.1.146] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 4D8383D06; Mon, 24 Sep 2007 22:32:29 -0700 (PDT) Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt From: Aaron Stone To: Alexey Melnikov Cc: ietf-mta-filters@imc.org, Ned Freed , Cullen Jennings , Lisa Dusseault , iesg@ietf.org In-Reply-To: <46F58579.70701@isode.com> References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> <46F58579.70701@isode.com> Content-Type: text/plain Date: Mon, 24 Sep 2007 09:23:58 -0700 Message-Id: <1190651039.11509.39.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote: > Ned Freed wrote: > > >> When I mentioned months ago > >> I could imagine many ways to solve this, coupling this type of thing > >> to the ability to do more than one redirect was one of the things > >> that seemed like a possible solution (and corresponds to my > >> understanding of at least some current deployments). > > > > In conclusion, Alexey has proposed new text in a separate messagage which > > I find completely acceptable. Please take a look at that and let's see > > where we are. > > Here is the proposal Ned was referring to: > > In section 4.2, add a sentence to the end of 3rd paragraph: > OLD: > The envelope sender address on the outgoing message is chosen by the > sieve implementation. It MAY be copied from the message being > processed. > NEW: > The envelope sender address on the outgoing message is chosen by the > sieve implementation. It MAY be copied from the message being > processed. However, if the message being processed has an empty > envelope sender address the outgoing message MUST also have an > empty envelope sender address. If this is correct behavior (thinking back again to the original reference to .forward files), then my implementation is incorrect (it tries to construct an envelope sender when one is not already present). > In section 4.2, last paragraph: > > OLD: > Implementations SHOULD take measures to implement loop control, > ^^^^^^ > possibly including adding headers to the message or counting Received > headers. If an implementation detects a loop, it causes an error. > NEW: > Implementations MUST take measures to implement loop control, > ^^^^ > possibly including adding headers to the message or counting Received > headers as specified in section 6.2 of [SMTP]. If an implementation > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > detects a loop, it causes an error. +1 > Add to the end of section 4.2 two new paragraphs: > > Implementations MUST provide means of limiting the number of redirects a > Sieve script can perform. See Section 10 for more details. > > Implementations MAY ignore a redirect action silently due to policy > reasons. > For example, an implementation MAY choose not to redirect to an address > that > is known to be undeliverable. An ignored redirect MUST NOT cancel the > implicit keep. > > > In section 10, replace 2nd paragraph: > > OLD: > It is equally important that implementations sanity-check the user's > scripts, and not allow users to create on-demand mailbombs. For > instance, an implementation that allows a user to redirect a message > multiple times might also allow a user to create a mailbomb triggered > by mail from a specific user. Site- or implementation-defined limits > on actions are useful for this. > > NEW: > Allowing a single script to redirect to multiple destinations can be > used as a means of amplifying the number of messages in an attack. > Moreover, if loop detection is not properly implemented it may be > possible to set up exponentially growing message loops. According, > Sieve implementations: Accordingly, ^^ > (1) MUST implement facilities to detect and break message loops. See > RFC 2821 section 6.2 for additional information on basic loop > detection strategies. > > (2) MUST provide the means for administrators to limit the ability of > users to abuse redirect. In particular, it MUST be possible to > limit the number of redirects a script can perform. Additionally, > if no use cases exist for using redirect to multiple destinations, > this limit SHOULD be set to 1. Additional limits, such > as the ability to restrict redirect to local users MAY also be > implemented. > > (3) MUST provide facilities to log use of redirect in order to facilitate > tracking down abuse. +1. (2) is a rather stern new requirement. It provides clarity on what was meant by "Site- or implementation-defined limits on actions are useful for this" in the original text. I don't see any problems with this text myself, unless it precludes some other mechanisms that I haven't thought about. Aaron From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 03:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191319354.13568@+Imlzd+C6ePbs1Y5D/iR9g X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 03:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PA2O9U013911 for ; Tue, 25 Sep 2007 06:02:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8P9mtQQ035946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 02:48:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8P9mtpH035944; Tue, 25 Sep 2007 02:48:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8P9mr63035936 for ; Tue, 25 Sep 2007 02:48:54 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D63D44AC96; Tue, 25 Sep 2007 11:48:52 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 11:50:51 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: a conflict between 3598(bis) and the base specification Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hi, 3598 and 3598bis contain this (which I apologise for not spotting while reviewing 3598bis): The ":detail" argument specifies that sub-part of the local-part which lies to the right of the separator character (e.g., "sieve" in "ken+sieve@example.org"). If no separator character exists, the test evaluates to false. If nothing lies to the right of the separator character, then ":detail" ":is" the null key (""). Otherwise, the ":detail" sub-part contains the null key. Why is the second sentence there? It seems to add a new value or throw an exception which aborts the surrounding test and attempts to override its result. Consider this test and header fragment: if address :detail ["to", "cc"] "sieve" { fileinto "sieve"; } From: someone@example.org To: arnt+sieve@example.org Cc: someone@example.org The specification for the "address" test lead me to think that since I'm addressed as arnt+sieve, the test should hit. But no separator character exists on the Cc field, so the second sentence quoted above says the address test fails. I don't like the way the address and :detail specifications conflict in this case. Arnt From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 05:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191325164.09901@7WITAABro5rSttRj3ufO+Q X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 05:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PBdGtb026557 for ; Tue, 25 Sep 2007 07:39:21 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBS3KV050664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:28:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PBS3jx050663; Tue, 25 Sep 2007 04:28:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBS11Y050656 for ; Tue, 25 Sep 2007 04:28:02 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C84524AC94; Tue, 25 Sep 2007 13:28:00 +0200 (CEST) Message-Id: <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> Date: Tue, 25 Sep 2007 13:29:59 +0200 From: Arnt Gulbrandsen To: Ned Freed Subject: sieve vacation draft, :mime Cc: ietf-mta-filters@imc.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hi, The sieve vacation draft doesn't say as much about :mime as it should. IMO, it should specify precisely which header fields must, may and must not be included in the :mime response. I suggest that a) content-type MUST be included (since if it's not included, what's the point of :mime?) b) content-transfer-encoding MAY be included, and if it's not included, the c-t-e is 7bit c) header fields defined in 2822 MUST NOT be included (e.g. received, to, subject) d) other header fields MAY be included (e.g. x-loop, x-message-flag, content-disposition) Arnt From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 05:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191326269.41999@0hDiUo4eg3YVc/LIKfl+0Q X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 05:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PBvhwI029582 for ; Tue, 25 Sep 2007 07:57:49 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBl6Uj053714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:47:06 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PBl6wi053713; Tue, 25 Sep 2007 04:47:06 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBl4Dd053707 for ; Tue, 25 Sep 2007 04:47:05 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 57C3D4ACE2; Tue, 25 Sep 2007 13:47:04 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 13:49:03 +0200 From: Arnt Gulbrandsen To: Ned Freed Subject: sieve vacation draft and 3834 Cc: ietf-mta-filters@imc.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hi, I think section 4.6 is good, but it would be even better if it referred to RFC 3834 section 2, perhaps at the end of the first paragraph. Some of the later paragraphs could be deleted since 3834 says the same things. Arnt From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 05:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191326451.37127@VRsnriJfM3PdJ+CYFgLckQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 05:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PC0ii3030615 for ; Tue, 25 Sep 2007 08:00:49 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBniuB054128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:49:44 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PBniXB054126; Tue, 25 Sep 2007 04:49:44 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBnhPr054118 for ; Tue, 25 Sep 2007 04:49:43 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 8435C4ACE0; Tue, 25 Sep 2007 13:49:42 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 13:51:41 +0200 From: Arnt Gulbrandsen To: Ned Freed Subject: Re: sieve vacation draft, :mime Cc: ietf-mta-filters@imc.org References: <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> In-Reply-To: <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Oops. Arnt Gulbrandsen writes: > I suggest that > ... e) MIME-Version MUST NOT be included Arnt From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 05:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191326938.87705@0gAMaL/Zg4IqU5KwIVLY5Q X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 05:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PC8qek031763 for ; Tue, 25 Sep 2007 08:08:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PButSU054927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:56:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PButRU054926; Tue, 25 Sep 2007 04:56:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (SMTP.andrew.cmu.edu [128.2.10.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBurwc054919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Sep 2007 04:56:54 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id l8PBupPO023335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 07:56:51 -0400 Message-ID: <46F8F77D.6090102@andrew.cmu.edu> Date: Tue, 25 Sep 2007 07:56:45 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-mta-filters@imc.org Subject: Re: a conflict between 3598(bis) and the base specification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.85 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Arnt Gulbrandsen wrote: > > Hi, > > 3598 and 3598bis contain this (which I apologise for not spotting while > reviewing 3598bis): > > The ":detail" argument specifies that sub-part of the local-part > which lies to the right of the separator character (e.g., "sieve" in > "ken+sieve@example.org"). If no separator character exists, the test > evaluates to false. If nothing lies to the right of the separator > character, then ":detail" ":is" the null key (""). Otherwise, the > ":detail" sub-part contains the null key. > > Why is the second sentence there? It seems to add a new value or throw > an exception which aborts the surrounding test and attempts to override > its result. > > Consider this test and header fragment: > > if address :detail ["to", "cc"] "sieve" { > fileinto "sieve"; > } > > From: someone@example.org > To: arnt+sieve@example.org > Cc: someone@example.org > > The specification for the "address" test lead me to think that since I'm > addressed as arnt+sieve, the test should hit. But no separator character > exists on the Cc field, so the second sentence quoted above says the > address test fails. True, the test against the Cc field fails, but when given a list of headers/strings, a logical OR is applied, so matching against To is sufficient for the test to succeed. In fact, the implementation SHOULD short-circuit the test after the To, and never test against Cc. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 06:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191329075.85051@OaZYTiP7k2oQKRW17Wuxjg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 06:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PCiOP2004242 for ; Tue, 25 Sep 2007 08:44:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PCTFmR058565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 05:29:15 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PCTFRi058564; Tue, 25 Sep 2007 05:29:15 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PCTDEB058526 for ; Tue, 25 Sep 2007 05:29:14 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F0B754ACA3; Tue, 25 Sep 2007 14:29:12 +0200 (CEST) Message-Id: Date: Tue, 25 Sep 2007 14:31:12 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: a conflict between 3598(bis) and the base specification Cc: Ken Murchison References: <46F8F77D.6090102@andrew.cmu.edu> In-Reply-To: <46F8F77D.6090102@andrew.cmu.edu> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ken Murchison writes: > True, the test against the Cc field fails, but when given a list of > headers/strings, a logical OR is applied, so matching against To is > sufficient for the test to succeed. Ah, now I see what you're saying. But 3028 consistently talks about "address" as a single test with multiple arguments, not as a collection of single-argument tests, so "the test evaluates to false" is less than ideal phrasing. 3598bis is in the RFC-Editor's queue, isn't it? Too late to change anything substantive. I suppose a minor rephrasing could be done during auth48. Perhaps ", then the :detail doesn't match anything" or something like that. Not terribly important. Change it if you think that's both appropriate and permissible. > In fact, the implementation SHOULD short-circuit the test after the > To, and never test against Cc. That's irrelevant. If the example test were address :detail ["cc", "to"] or the example header's Cc field were before its To field, this argument would not apply. Much too fragile to matter. Arnt (noncompliant implementer) From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 08:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191336946.09571@zMblW6eZtGxwfk0kdnv6BQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 08:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PEtaN7023876 for ; Tue, 25 Sep 2007 10:55:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PEawjH074470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 07:36:58 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PEaw1Z074469; Tue, 25 Sep 2007 07:36:58 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (SMTP.andrew.cmu.edu [128.2.10.212]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PEauXX074463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Sep 2007 07:36:57 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id l8PEatxN018679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 10:36:55 -0400 Message-ID: <46F91D01.3010501@andrew.cmu.edu> Date: Tue, 25 Sep 2007 10:36:49 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf-mta-filters@imc.org CC: Alexey Melnikov Subject: Re: a conflict between 3598(bis) and the base specification References: <46F8F77D.6090102@andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.212 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Arnt Gulbrandsen wrote: > Ken Murchison writes: >> True, the test against the Cc field fails, but when given a list of >> headers/strings, a logical OR is applied, so matching against To is >> sufficient for the test to succeed. > > Ah, now I see what you're saying. But 3028 consistently talks about > "address" as a single test with multiple arguments, not as a collection > of single-argument tests, so "the test evaluates to false" is less than > ideal phrasing. > > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change > anything substantive. I suppose a minor rephrasing could be done during > auth48. Perhaps ", then the :detail doesn't match anything" or something > like that. Not terribly important. Change it if you think that's both > appropriate and permissible. Anyone want to second this suggestion? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 09:27:04 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191342279.50293@Dxdb64avkeDG3RqngCzIug X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 09:27:04 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PGOXNI007333 for ; Tue, 25 Sep 2007 12:24:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PG8e7D086833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 09:08:40 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PG8ecZ086832; Tue, 25 Sep 2007 09:08:40 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PG8cB3086826 for ; Tue, 25 Sep 2007 09:08:39 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLRQZU5OGG00BTGA@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 25 Sep 2007 09:08:07 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLJVA3LB9C005BGY@mauve.mrochek.com>; Tue, 25 Sep 2007 09:07:57 -0700 (PDT) Cc: Ned Freed , ietf-mta-filters@imc.org Message-id: <01MLRQZRG4CU005BGY@mauve.mrochek.com> Date: Tue, 25 Sep 2007 08:53:37 -0700 (PDT) From: Ned Freed Subject: Re: sieve vacation draft, :mime In-reply-to: "Your message dated Tue, 25 Sep 2007 13:29:59 +0200" <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> To: Arnt Gulbrandsen DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190736482; h=Date: From:Subject:MIME-version:Content-type; b=uah5i52Mu51COQazmK+RzWYtF bCEYXHPELs5qsCNhEloX6DkzZ1U9IBEZEEaOk2CKIEonAKEFeqaA6BZGBVrWA== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > The sieve vacation draft doesn't say as much about :mime as it should. > IMO, it should specify precisely which header fields must, may and must > not be included in the :mime response. First of all, as far as the current draft goes this discussion is happening almost two years too late. Sieve vacation is in the RFC Editor queue - it is currently blocked on the base specification. The only changes that have been made to vacation since it was approved have been ones to align stuff like IANA registrations with current publication requirements. > I suggest that > a) content-type MUST be included (since if it's not included, what's > the point of :mime?) Strongly disagree. The point of :mime could have been to specify a text/plain part in the US-ASCII charset that also includes content-description or content-id fields. In such a case the content-type would be optional according to MIME and I see no reason why Sieve vacation should impose additional requiremens on the MIME entities it allows people to construct. > b) content-transfer-encoding MAY be included, and if it's not > included, the c-t-e is 7bit This is already implicit in the definition of a MIME entity and IMO does not need to be restated. > c) header fields defined in 2822 MUST NOT be included (e.g. received, > to, subject) This is also implicit in the definition of a MIME entity and while I can see some merit in restating this particular restriction I don't think it rises to the level of revising a draft in the RFC Editor queue. > d) other header fields MAY be included (e.g. x-loop, x-message-flag, > content-disposition) MIME entities are only supposed to contain MIME headers, so this is actually changing and extending what the document currently allows. Absent a really compelling case for adding this functionality I don't think now is the time to revisit this decision. Ned From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 10:27:01 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191342451.50854@tERoXkPGXMANQNLdzhQ3aQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 10:27:01 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PGRMJU007757 for ; Tue, 25 Sep 2007 12:27:27 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PGCTW2087678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 09:12:29 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PGCTxT087677; Tue, 25 Sep 2007 09:12:29 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PGCSXA087671 for ; Tue, 25 Sep 2007 09:12:28 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLRR4LOHZK00B9WE@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 25 Sep 2007 09:11:53 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLJVA3LB9C005BGY@mauve.mrochek.com>; Tue, 25 Sep 2007 09:11:49 -0700 (PDT) Cc: Ned Freed , ietf-mta-filters@imc.org Message-id: <01MLRR4K0QU2005BGY@mauve.mrochek.com> Date: Tue, 25 Sep 2007 09:08:49 -0700 (PDT) From: Ned Freed Subject: Re: sieve vacation draft and 3834 In-reply-to: "Your message dated Tue, 25 Sep 2007 13:49:03 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: To: Arnt Gulbrandsen DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190736712; h=Date: From:Subject:MIME-version:Content-type; b=IVcjQfpBxXR9l/VrX6kpSmiqy seKFfe+s3nBs5HI+ZKim8Etk1kBbw/PfkD7UandPgm1smG2PkXBp2kOLloZdA== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > I think section 4.6 is good, but it would be even better if it referred > to RFC 3834 section 2, perhaps at the end of the first paragraph. Some > of the later paragraphs could be deleted since 3834 says the same > things. Again, it is far too late to be considering such changes for this version of the document. And even if that weren't the case I would object since RFC 3834 only provides, in its own words, "broad guidelines". IMO the point of RFC 3834 is to provide guidance as to what restrictions need to be in other documents that define various types of autoforwarders. It isn't really intended to provide the definition of the one true sort of autoforwwarder. Ned From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 10:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191342886.41683@yZK2eCmSpHlD32YCpg/93Q X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 10:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PGYcsp009047 for ; Tue, 25 Sep 2007 12:34:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PGJURY088898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 09:19:30 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PGJUAt088897; Tue, 25 Sep 2007 09:19:30 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PGJTla088885 for ; Tue, 25 Sep 2007 09:19:29 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLRRDYPATC000ZO1@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 25 Sep 2007 09:19:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLJVA3LB9C005BGY@mauve.mrochek.com>; Tue, 25 Sep 2007 09:19:19 -0700 (PDT) Cc: ietf-mta-filters@imc.org, Alexey Melnikov Message-id: <01MLRRDUVK16005BGY@mauve.mrochek.com> Date: Tue, 25 Sep 2007 09:16:24 -0700 (PDT) From: Ned Freed Subject: Re: a conflict between 3598(bis) and the base specification In-reply-to: "Your message dated Tue, 25 Sep 2007 10:36:49 -0400" <46F91D01.3010501@andrew.cmu.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <46F8F77D.6090102@andrew.cmu.edu> <46F91D01.3010501@andrew.cmu.edu> To: Ken Murchison DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190737165; h=Date: From:Subject:MIME-version:Content-type; b=on1CuIKDhMAYIhhbuSsEbzIXg g9uyqYdJC7czQeGRglatNpQLydtksUOoGlLIfIWM4Wlle9O3ngKJ2nN6tV6Vw== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > Arnt Gulbrandsen wrote: > > Ken Murchison writes: > >> True, the test against the Cc field fails, but when given a list of > >> headers/strings, a logical OR is applied, so matching against To is > >> sufficient for the test to succeed. > > > > Ah, now I see what you're saying. But 3028 consistently talks about > > "address" as a single test with multiple arguments, not as a collection > > of single-argument tests, so "the test evaluates to false" is less than > > ideal phrasing. > > > > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change > > anything substantive. I suppose a minor rephrasing could be done during > > auth48. Perhaps ", then the :detail doesn't match anything" or something > > like that. Not terribly important. Change it if you think that's both > > appropriate and permissible. > Anyone want to second this suggestion? Changing it to say "fails to match" or something similar seems fine to me. Ned From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 11:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191346930.87179@1sVGUebsEwKSrKyIpWmJgg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 11:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PHg36R018614 for ; Tue, 25 Sep 2007 13:42:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PHM6ij099730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 10:22:06 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PHM6ip099729; Tue, 25 Sep 2007 10:22:06 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PHM40C099721 for ; Tue, 25 Sep 2007 10:22:05 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLRTKKRG1C00AKZ4@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 25 Sep 2007 10:22:01 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLJVA3LB9C005BGY@mauve.mrochek.com>; Tue, 25 Sep 2007 10:21:58 -0700 (PDT) Cc: Ned Freed , ietf-mta-filters@imc.org Message-id: <01MLRTKJAVVU005BGY@mauve.mrochek.com> Date: Tue, 25 Sep 2007 10:21:25 -0700 (PDT) From: Ned Freed Subject: Re: sieve vacation draft, :mime In-reply-to: "Your message dated Tue, 25 Sep 2007 13:51:41 +0200" MIME-version: 1.0 References: <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> To: Arnt Gulbrandsen DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190740921; h=Date: From:Subject:MIME-version; b=XIlzl84NU/+TAkW+3E6D8f1TYt2+LRkRWVuu/p vHPT0MtuKrvGkQ3kqfm9z1h0XUrPWUT2YT2Xyn/JHiwcHwcA== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > Oops. > Arnt Gulbrandsen writes: > > I suggest that > > ... > e) MIME-Version MUST NOT be included MIME-Version isn't an entity header, so this is already covered as well. Ned From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 12:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191352735.27803@AQWadXoZ63P2vhiOsoOrXg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 12:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PJIn95031371 for ; Tue, 25 Sep 2007 15:18:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PJ4pNK013254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 12:04:51 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PJ4pER013252; Tue, 25 Sep 2007 12:04:51 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PJ4lqF013242 for ; Tue, 25 Sep 2007 12:04:48 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLRX5SNMBK00BU1K@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 25 Sep 2007 12:04:39 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MLJVA3LB9C005BGY@mauve.mrochek.com>; Tue, 25 Sep 2007 12:04:36 -0700 (PDT) Cc: Alexey Melnikov , ietf-mta-filters@imc.org, Ned Freed , Cullen Jennings , Lisa Dusseault , iesg@ietf.org Message-id: <01MLRX5RNVIC005BGY@mauve.mrochek.com> Date: Tue, 25 Sep 2007 11:55:19 -0700 (PDT) From: Ned Freed Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt In-reply-to: "Your message dated Mon, 24 Sep 2007 09:23:58 -0700" <1190651039.11509.39.camel@localhost> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> <46F58579.70701@isode.com> <1190651039.11509.39.camel@localhost> To: Aaron Stone DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190747078; h=Date: From:Subject:MIME-version:Content-type; b=JOtUDeUrWv8wVxz0KePtSDMP5 UW1JtQDgkuGg8eMmqAk7mxz/rMFgh7hlLC0q+FNZwnDpF6y9B7QYG/08Pus8g== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > On Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote: > > Ned Freed wrote: > > > > >> When I mentioned months ago > > >> I could imagine many ways to solve this, coupling this type of thing > > >> to the ability to do more than one redirect was one of the things > > >> that seemed like a possible solution (and corresponds to my > > >> understanding of at least some current deployments). > > > > > > In conclusion, Alexey has proposed new text in a separate messagage which > > > I find completely acceptable. Please take a look at that and let's see > > > where we are. > > > > Here is the proposal Ned was referring to: > > > > In section 4.2, add a sentence to the end of 3rd paragraph: > > OLD: > > The envelope sender address on the outgoing message is chosen by the > > sieve implementation. It MAY be copied from the message being > > processed. > > NEW: > > The envelope sender address on the outgoing message is chosen by the > > sieve implementation. It MAY be copied from the message being > > processed. However, if the message being processed has an empty > > envelope sender address the outgoing message MUST also have an > > empty envelope sender address. > If this is correct behavior (thinking back again to the original > reference to .forward files), then my implementation is incorrect (it > tries to construct an envelope sender when one is not already present). I understand that some implementations will have to change, but I'm prety confident we need this requirement. I cannot cite problematic behavior with Sieve redirect to back it up, but I have seen several cases of bounce loops occur with other sorts of autoforwarding that does this. This is less an issue with intentional attacks than it is with unintentional loop creation. The common problematic case is where someone redirects their mail unconditionally to some remote place while filling in their own address in the envelope. Now suppose that remote address becomes invalid. The DSN goes back and is redirected, but now it has a nonempty envelope from so a loop forms. > > In section 4.2, last paragraph: > > > > OLD: > > Implementations SHOULD take measures to implement loop control, > > ^^^^^^ > > possibly including adding headers to the message or counting Received > > headers. If an implementation detects a loop, it causes an error. > > NEW: > > Implementations MUST take measures to implement loop control, > > ^^^^ > > possibly including adding headers to the message or counting Received > > headers as specified in section 6.2 of [SMTP]. If an implementation > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > detects a loop, it causes an error. > +1 > > Add to the end of section 4.2 two new paragraphs: > > > > Implementations MUST provide means of limiting the number of redirects a > > Sieve script can perform. See Section 10 for more details. > > > > Implementations MAY ignore a redirect action silently due to policy > > reasons. > > For example, an implementation MAY choose not to redirect to an address > > that > > is known to be undeliverable. An ignored redirect MUST NOT cancel the > > implicit keep. > > > > > > In section 10, replace 2nd paragraph: > > > > OLD: > > It is equally important that implementations sanity-check the user's > > scripts, and not allow users to create on-demand mailbombs. For > > instance, an implementation that allows a user to redirect a message > > multiple times might also allow a user to create a mailbomb triggered > > by mail from a specific user. Site- or implementation-defined limits > > on actions are useful for this. > > > > NEW: > > Allowing a single script to redirect to multiple destinations can be > > used as a means of amplifying the number of messages in an attack. > > Moreover, if loop detection is not properly implemented it may be > > possible to set up exponentially growing message loops. According, > > Sieve implementations: > Accordingly, > ^^ > > (1) MUST implement facilities to detect and break message loops. See > > RFC 2821 section 6.2 for additional information on basic loop > > detection strategies. > > > > (2) MUST provide the means for administrators to limit the ability of > > users to abuse redirect. In particular, it MUST be possible to > > limit the number of redirects a script can perform. Additionally, > > if no use cases exist for using redirect to multiple destinations, > > this limit SHOULD be set to 1. Additional limits, such > > as the ability to restrict redirect to local users MAY also be > > implemented. > > > > (3) MUST provide facilities to log use of redirect in order to facilitate > > tracking down abuse. > +1. (2) is a rather stern new requirement. It provides clarity on what > was meant by "Site- or implementation-defined limits on actions are > useful for this" in the original text. I don't see any problems with > this text myself, unless it precludes some other mechanisms that I > haven't thought about. I see it as setting a minimum that has to be there. I don't see how it could prevent some mechanism we haven't thought of from being used. Ned From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 14:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191357789.54555@mKnV8jPQEtGMpYoSrpl67g X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 14:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PKgxHU009412 for ; Tue, 25 Sep 2007 16:43:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PKI428020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 13:18:05 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PKI4ix020367; Tue, 25 Sep 2007 13:18:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PKI1Ma020361 for ; Tue, 25 Sep 2007 13:18:04 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id 4F50C3D06; Tue, 25 Sep 2007 13:19:47 -0700 (PDT) Date: Tue, 25 Sep 2007 20:19:46 -0000 To: "Ned Freed" Subject: Re: Suggested changes to address Cullen's DISCUSS on From: "Aaron Stone" X-Mailer: TWIG 2.8.2 Message-ID: In-Reply-To: <01MLRX5RNVIC005BGY@mauve.mrochek.com> References: <46C61458.7090903@isode.com> <46D05AC1.6090905@isode.com> <01MKLYZA8T6G00005F@mauve.mrochek.com> <01MKSZDVMDIG00005F@mauve.mrochek.com> <46F58579.70701@isode.com> <1190651039.11509.39.camel@localhost>, Cc: "Alexey Melnikov" , , "Ned Freed" , "Cullen Jennings" , "Lisa Dusseault" , Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Tue, Sep 25, 2007, Ned Freed said: > >> On Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote: >> > Ned Freed wrote: >> > >> > >> When I mentioned months ago >> > >> I could imagine many ways to solve this, coupling this type of thing >> > >> to the ability to do more than one redirect was one of the things >> > >> that seemed like a possible solution (and corresponds to my >> > >> understanding of at least some current deployments). >> > > >> > > In conclusion, Alexey has proposed new text in a separate messagage which >> > > I find completely acceptable. Please take a look at that and let's see >> > > where we are. >> > >> > Here is the proposal Ned was referring to: >> > >> > In section 4.2, add a sentence to the end of 3rd paragraph: >> > OLD: >> > The envelope sender address on the outgoing message is chosen by the >> > sieve implementation. It MAY be copied from the message being >> > processed. >> > NEW: >> > The envelope sender address on the outgoing message is chosen by the >> > sieve implementation. It MAY be copied from the message being >> > processed. However, if the message being processed has an empty >> > envelope sender address the outgoing message MUST also have an >> > empty envelope sender address. > >> If this is correct behavior (thinking back again to the original >> reference to .forward files), then my implementation is incorrect (it >> tries to construct an envelope sender when one is not already present). > > I understand that some implementations will have to change, but I'm prety > confident we need this requirement. I cannot cite problematic behavior > with Sieve redirect to back it up, but I have seen several cases of > bounce loops occur with other sorts of autoforwarding that does this. > > This is less an issue with intentional attacks than it is with unintentional > loop creation. The common problematic case is where someone redirects their > mail unconditionally to some remote place while filling in their own address > in the envelope. Now suppose that remote address becomes invalid. The > DSN goes back and is redirected, but now it has a nonempty envelope from > so a loop forms. I think by the time we're done with this section, we'll have written the best practices document for forwarding mail :-) It's one of those things where very specific guidance on edge cases is really important. [snip] >> > (1) MUST implement facilities to detect and break message loops. See >> > RFC 2821 section 6.2 for additional information on basic loop >> > detection strategies. >> > >> > (2) MUST provide the means for administrators to limit the ability of >> > users to abuse redirect. In particular, it MUST be possible to >> > limit the number of redirects a script can perform. Additionally, >> > if no use cases exist for using redirect to multiple destinations, >> > this limit SHOULD be set to 1. Additional limits, such >> > as the ability to restrict redirect to local users MAY also be >> > implemented. >> > >> > (3) MUST provide facilities to log use of redirect in order to facilitate >> > tracking down abuse. > >> +1. (2) is a rather stern new requirement. It provides clarity on what >> was meant by "Site- or implementation-defined limits on actions are >> useful for this" in the original text. I don't see any problems with >> this text myself, unless it precludes some other mechanisms that I >> haven't thought about. > > I see it as setting a minimum that has to be there. I don't see how it could > prevent some mechanism we haven't thought of from being used. To clarify what I wrote above ('this text' had the wrong antecedent), I see no problems myself with the new text and I definitely appreciate the guidance and direct statement of what was alluded to by the original text. Aaron From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 14:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191358805.69064@A3vugPsBG+FehtykUTYxYA X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 14:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PKxxd5010942 for ; Tue, 25 Sep 2007 17:00:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PKkr9X023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 13:46:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PKkrie023252; Tue, 25 Sep 2007 13:46:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PKkqE3023246 for ; Tue, 25 Sep 2007 13:46:53 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ABBFF4AC44; Tue, 25 Sep 2007 22:46:51 +0200 (CEST) Message-Id: <+QSDVo1jkXcHpJW5lHeRoA.md5@libertango.oryx.com> Date: Tue, 25 Sep 2007 22:48:51 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: sieve vacation draft, :mime Cc: Ned Freed References: <9MF9o72iS2oR3wwutUnMCg.md5@libertango.oryx.com> <01MLRQZRG4CU005BGY@mauve.mrochek.com> In-Reply-To: <01MLRQZRG4CU005BGY@mauve.mrochek.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ned Freed writes: > MIME entities are only supposed to contain MIME headers, The definition in 2045 contains this sentence: Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. > so this is actually changing and extending what the document currently > allows. Absent a really compelling case for adding this functionality > I don't think now is the time to revisit this decision. I agree that once a document is in the queue, the threshold for attempting a change should be high. Higher than e.g. the threshold for issuing an erratum. The reason I'm unhappy today is that I just discovered lots of test cases. (I wasn't an implementer two years ago, I'm afraid.) I don't want to have to write code and tests for e.g. Subject being present in both :mime and :subject. In fact, if your intention as document editor was that only MIME header fields should be present, I think I'll be quiet now and write some code to discard all other header fields. That's simple to implement and it's always possible to write more complicated code if someone complains. Arnt From owner-ietf-mta-filters@mail.imc.org Tue Sep 25 14:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191360122.69353@SjeHO+GFZlXkDHZru2QDTw X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 25 Sep 2007 14:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8PLLsLT013618 for ; Tue, 25 Sep 2007 17:22:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PL94pB025077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 14:09:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PL94CE025076; Tue, 25 Sep 2007 14:09:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PL93mv025069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Sep 2007 14:09:04 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id l8PL91G4013802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 17:09:02 -0400 Message-ID: <46F978E7.7000405@andrew.cmu.edu> Date: Tue, 25 Sep 2007 17:08:55 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf-mta-filters@imc.org CC: Ned Freed , Alexey Melnikov , Arnt Gulbrandsen Subject: Re: a conflict between 3598(bis) and the base specification References: <46F8F77D.6090102@andrew.cmu.edu> <46F91D01.3010501@andrew.cmu.edu> <01MLRRDUVK16005BGY@mauve.mrochek.com> In-Reply-To: <01MLRRDUVK16005BGY@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ned Freed wrote: > >> Arnt Gulbrandsen wrote: >> > Ken Murchison writes: >> >> True, the test against the Cc field fails, but when given a list of >> >> headers/strings, a logical OR is applied, so matching against To is >> >> sufficient for the test to succeed. >> > >> > Ah, now I see what you're saying. But 3028 consistently talks about >> > "address" as a single test with multiple arguments, not as a collection >> > of single-argument tests, so "the test evaluates to false" is less than >> > ideal phrasing. >> > >> > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change >> > anything substantive. I suppose a minor rephrasing could be done during >> > auth48. Perhaps ", then the :detail doesn't match anything" or >> something >> > like that. Not terribly important. Change it if you think that's both >> > appropriate and permissible. > >> Anyone want to second this suggestion? > > Changing it to say "fails to match" or something similar seems fine to me. How about this? Original text: If the address is not encoded to contain a detail sub-part, then the test evaluates to false. Proposed text 1: If the address is not encoded to contain a detail sub-part, then the address fails to match any of the key-list arguments. Proposed text 2: If the address is not encoded to contain a detail sub-part, then the address fails to match any of the specified keys. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From owner-ietf-mta-filters@mail.imc.org Wed Sep 26 04:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191408256.39397@z4J+nUQCw+flyF63PvewNQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 26 Sep 2007 04:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8QAi6c2003426 for ; Wed, 26 Sep 2007 06:44:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QATtsH009841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 03:29:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8QATtrP009840; Wed, 26 Sep 2007 03:29:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QATsrf009833 for ; Wed, 26 Sep 2007 03:29:55 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 26 Sep 2007 11:29:51 +0100 Message-ID: <46FA236E.2060509@isode.com> Date: Wed, 26 Sep 2007 10:16:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed CC: Ken Murchison , ietf-mta-filters@imc.org Subject: Re: a conflict between 3598(bis) and the base specification References: <46F8F77D.6090102@andrew.cmu.edu> <46F91D01.3010501@andrew.cmu.edu> <01MLRRDUVK16005BGY@mauve.mrochek.com> In-Reply-To: <01MLRRDUVK16005BGY@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ned Freed wrote: >> Arnt Gulbrandsen wrote: >> > Ken Murchison writes: >> >> True, the test against the Cc field fails, but when given a list of >> >> headers/strings, a logical OR is applied, so matching against To is >> >> sufficient for the test to succeed. >> > >> > Ah, now I see what you're saying. But 3028 consistently talks about >> > "address" as a single test with multiple arguments, not as a >> collection >> > of single-argument tests, so "the test evaluates to false" is less >> than >> > ideal phrasing. >> > >> > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change >> > anything substantive. I suppose a minor rephrasing could be done >> during >> > auth48. Perhaps ", then the :detail doesn't match anything" or >> something >> > like that. Not terribly important. Change it if you think that's both >> > appropriate and permissible. > >> Anyone want to second this suggestion? > > Changing it to say "fails to match" or something similar seems fine to > me. +1. I don't think this change is very controversial, so it can be done in AUTH48. From owner-ietf-mta-filters@mail.imc.org Wed Sep 26 04:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-mallorn-MailScanner-Watermark: 1191408989.42141@w0Do3DTnD+UODKVgUduDPQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 26 Sep 2007 04:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id l8QAuMOo005948 for ; Wed, 26 Sep 2007 06:56:28 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QAkcak012205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 03:46:38 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8QAkcuv012204; Wed, 26 Sep 2007 03:46:38 -0700 (MST) (enve