From owner-ietf-mta-filters Fri Jun 4 05:29:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54CTJJw008439; Fri, 4 Jun 2004 05:29:19 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54CTJFx008438; Fri, 4 Jun 2004 05:29:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i54CTFH7008420 for ; Fri, 4 Jun 2004 05:29:18 -0700 (PDT) (envelope-from mem@mv.mv.com) Received: (qmail 24961 invoked from network); 4 Jun 2004 08:29:15 -0400 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 4 Jun 2004 08:29:15 -0400 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 15251 invoked by uid 101); 4 Jun 2004 08:29:13 -0400 From: "Mark E. Mallett" Date: Fri, 4 Jun 2004 08:29:13 -0400 To: ietf-mta-filters@imc.org Cc: "Mark E. Mallett" Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt Message-ID: <20040604122913.GA29859@iridium.mv.net> References: <4079E9CA.3010106@elvey.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4079E9CA.3010106@elvey.fastmail.fm> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a fine draft. I have a few musings that I sent to Matthew earlier that I'll twist around a little here- don't mistake these as objections though, there's really not a lot to object to. Not sure I made that clear earlier. But I do think there are some points to raise, if not ponder. In this draft there are some great justifications for script writers to use "refuse" rather than "reject. However there's this: > There is an exception when a single message has multiple SMTP > recipients, and at least one but not all of them are refusing delivery > (whether the refusal is caused by execution of a Sieve "refuse" or for > another reason). In this case, the server MUST accept the message and > generate DSNs for all recipients that are refusing it. This may not be the only fallback case. I could envision other cases where smtp-time "refuse" was generally implemented, but situationally unavailable. (You've identified one.) As you say, existing scripts should continue to run. I see a conundrum, in that script writers will feel assured that by using "refuse" they will not be generating bounces. Without "refuse" a conscientious script writer would probably have used "discard" or "fileinto" -- anything other than "reject." However, in the presence of a "refuse" option, the same conscientious script writer will likely use "refuse." So under some conditions the very presence of this option could increase the likelihood of generating rejects. No matter what percentage this represents, I'd feel better if that were taken into account. I'd take that into account by being able to specify a fallback option should "refuse" not be present. And if you give the ability to have a fallback option, you could make the default fallback action be "discard" rather than "reject" -- and force the script writer to specify a preference for reject if for some reason they wanted to use it. I don't even think that's the best alternative: better would be some more systemic-level enhancements to SIEVE that would allow certain conditions to be tested and operated on. For example, being able to test whether "refuse" succeeded would help: if not refuse "This looks like spam" { discard; } Less disruptive systemic changes could be devised; for example being able to test the status of the implicit keep flag: refuse "This looks like spam"; if not ikeep { discard; } Or something like a "stop" if successful: refuse :stop "This looks like spam"; discard; This branches into a train of thought about general script portability: I've mentioned in the past that it would be nice to be able to have conditions depending on what mode a script was running in, or what capabilities were supported, so that scripts could continue to run in the face of changing environments. ("changing environments" was in fact one of the cases I had in mind above, when I mentioned that there could be other situations in which "refuse" is unavailable. One has to think of the system administration too.) Other than that, I'm obviously getting farther away from "refuse" -- but I often think that some broader thinking about SIEVE extensions would help keep the language more whole in the face of these optional capabilities. (That's rather brusque but I don't want to go on here too long..) At any rate, those are some thoughts. -mm- From owner-ietf-mta-filters Fri Jun 4 12:20:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54JKf8G068090; Fri, 4 Jun 2004 12:20:41 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54JKfkE068089; Fri, 4 Jun 2004 12:20:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54JKfWf068073 for ; Fri, 4 Jun 2004 12:20:41 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: qpj8Wil7VVT3crQCAph/9g 1086376841 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 98799C04712; Fri, 4 Jun 2004 15:20:39 -0400 (EDT) Message-ID: <40C0CB82.60507@elvey.com> Date: Fri, 04 Jun 2004 12:20:34 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mark E. Mallett" Cc: ietf-mta-filters@imc.org Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt References: <4079E9CA.3010106@elvey.fastmail.fm> <20040604122913.GA29859@iridium.mv.net> In-Reply-To: <20040604122913.GA29859@iridium.mv.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . 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: On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey: >This is a fine draft. I have a few musings that I sent to Matthew >earlier that I'll twist around a little here- don't mistake these as >objections though, there's really not a lot to object to. Not sure I >made that clear earlier. But I do think there are some points to >raise, if not ponder. > >In this draft there are some great justifications for script writers >to use "refuse" rather than "reject. However there's this: > > > >>There is an exception when a single message has multiple SMTP >>recipients, and at least one but not all of them are refusing delivery >>(whether the refusal is caused by execution of a Sieve "refuse" or for >>another reason). In this case, the server MUST accept the message and >>generate DSNs for all recipients that are refusing it. >> >> > >This may not be the only fallback case. I could envision other cases >where smtp-time "refuse" was generally implemented, but situationally >unavailable. (You've identified one.) As you say, existing scripts >should continue to run. > > What do you envision? I haven't thought of any others and don't think there are any. We designed the spec consciously so that, e.g. MUAs can't implement "refuse". In other words, if you want to , tough, if your implementation can't handle it. If it claims to, it's violating our spec. We can't physically prevent this from happening though. We state it strongly: "A SIEVE implementation that cannot do so MUST NOT claim to support the refuse extension." >I see a conundrum, in that script writers will feel assured that by >using "refuse" they will not be generating bounces. Without "refuse" a >conscientious script writer would probably have used "discard" or >"fileinto" -- anything other than "reject." However, in the presence >of a "refuse" option, the same conscientious script writer will likely >use "refuse." So under some conditions the very presence of this >option could increase the likelihood of generating rejects. No matter >what percentage this represents, I'd feel better if that were taken >into account. > > This will happen if the implementation is defective (and in the listed exceptional case, which I'm not worried about). I think what we've done already will prevent this from being a real problem. >I'd take that into account by being able to specify a fallback option >should "refuse" not be present. And if you give the ability to have a >fallback option, you could make the default fallback action be >"discard" rather than "reject" -- and force the script writer to >specify a preference for reject if for some reason they wanted to use >it. > > That's being much more cavalier with people's email than I'm comfortable with, especially if one is optimistic that we will have a pretty effective antispam solution in the fairly near future - effective enough to drive a bunch of them out of the business. There's an RFC for unilaterally preventing joe jobs, and someone reinvented the same or came up with a similar solution at the recent ASRG MARID meeting. I could look it up if you're interested. For example, here's a problem: I admin a few mailing lists (verified opt-in, of course.) One is political and has severe deliverability problems that I'm working to fix. Not getting any indication that mail hasn't been delivered makes this task much harder. The ideas below are good ideas for improving Sieve, but are out of scope for my draft. It would be in scope for a new version of Sieve, and would require several extension specs be changed to work well with it. I think we've made the best of a bad situation; don't see how we can improve the "refuse" spec. >I don't even think that's the best alternative: better would be some >more systemic-level enhancements to SIEVE that would allow certain >conditions to be tested and operated on. For example, being able to >test whether "refuse" succeeded would help: > > if not refuse "This looks like spam" { > discard; > } > > Yeah, this would be nice, but it's not something I'm able to take on. I'd support it. IIRC, Sieve actions don't have return values. >Less disruptive systemic changes could be devised; for example being >able to test the status of the implicit keep flag: > > refuse "This looks like spam"; > if not ikeep { discard; } > >Or something like a "stop" if successful: > > refuse :stop "This looks like spam"; > discard; > > >This branches into a train of thought about general script portability: >I've mentioned in the past that it would be nice to be able to have >conditions depending on what mode a script was running in, or what >capabilities were supported, so that scripts could continue to run in >the face of changing environments. ("changing environments" was in >fact one of the cases I had in mind above, when I mentioned that there >could be other situations in which "refuse" is unavailable. One has >to think of the system administration too.) Other than that, I'm >obviously getting farther away from "refuse" -- but I often think that >some broader thinking about SIEVE extensions would help keep the >language more whole in the face of these optional capabilities. >(That's rather brusque but I don't want to go on here too long..) > >At any rate, those are some thoughts. > >-mm- > > > PPS I find your comments constructive and helpful, though my to-the-point comments and questions might make it seem otherwise. Thanks. From owner-ietf-mta-filters Sun Jun 6 22:14:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i575ENiZ089583; Sun, 6 Jun 2004 22:14:23 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i575EMCw089582; Sun, 6 Jun 2004 22:14:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i575ELQp089555 for ; Sun, 6 Jun 2004 22:14:22 -0700 (PDT) (envelope-from mem@mv.mv.com) Received: (qmail 7556 invoked from network); 7 Jun 2004 01:14:26 -0400 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 7 Jun 2004 01:14:26 -0400 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 6582 invoked by uid 101); 7 Jun 2004 01:14:25 -0400 From: "Mark E. Mallett" Date: Mon, 7 Jun 2004 01:14:25 -0400 To: Matthew Elvey Cc: "Mark E. Mallett" , ietf-mta-filters@imc.org Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt Message-ID: <20040607051425.GG12334@iridium.mv.net> References: <4079E9CA.3010106@elvey.fastmail.fm> <20040604122913.GA29859@iridium.mv.net> <40C0CB82.60507@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C0CB82.60507@elvey.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jun 04, 2004 at 12:20:34PM -0700, Matthew Elvey wrote: > On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey: > >This may not be the only fallback case. I could envision other cases > >where smtp-time "refuse" was generally implemented, but situationally > >unavailable. (You've identified one.) As you say, existing scripts > >should continue to run. > > > What do you envision? I haven't thought of any others and don't think > there are any. a) All it takes is one such case for the point to apply. The fact that there is one at all is enough. b) I alluded to some more broader cases and even gave a f'rinstance. The key is "situationally unavailable." In fact there are other arguments that apply here that don't apply to (a). I'll expand a little below. > We designed the spec consciously so that, e.g. MUAs can't implement > "refuse". > In other words, if you want to , tough, if your > implementation can't handle it. > If it claims to, it's violating our spec. We can't physically prevent > this from happening though. > We state it strongly: > > "A SIEVE implementation that cannot do so MUST NOT claim > to support the refuse extension." Well that's all very self-referential as an answer :-) I'm suggesting that the spec should be adjusted to allow a best-effort "refuse" with a fallback to another action, and your refutation is that the spec doesn't allow it. That's too circular of a way to respond to the suggestion. > >I'd take that into account by being able to specify a fallback option > >should "refuse" not be present. And if you give the ability to have a > >fallback option, you could make the default fallback action be > >"discard" rather than "reject" -- and force the script writer to > >specify a preference for reject if for some reason they wanted to use > >it. > > > That's being much more cavalier with people's email than I'm comfortable > with, Actually it's the opposite of being cavalier: it's giving more options to the script writer. I'm trying to see how you classify it as cavalier- perhaps you think I'm saying that the only action be discard, and not the default one? Figuring out what the best default is is a matter that's best done before people start writing scripts. Having a default doesn't preclude other deliberate actions. I simply suggest a default that encompasses the usual case; defaults constructed in that way help minimize code and enhance clarity. > especially if one is optimistic that we will have a pretty > effective antispam solution in the fairly near future - effective enough > to drive a bunch of them out of the business. That would be nice. Even if that comes to pass, "refuse" and other actions will still be useful. > There's an RFC for unilaterally preventing joe jobs, and someone > reinvented the same or came up with a similar solution at the recent > ASRG MARID meeting. > I could look it up if you're interested. most others later are repeated from my email of 5/25 to which I haven't > received a response(!?).> Sorry, maybe I wasn't clear. I did respond- I said that any extended back and forth discussion would be better on the list, and I promised to restate my thoughts here. Which I did (it took me a while, sorry). Anyway, on to specifics about "situational unavailability" of "refuse." Mainly I'm concerned not so much about individual scripts but about script portability and overall system administration. For language growth I'd like to help ensure that scripts can be written in a way that lets people move them from one environment to another without having to completely rewrite them. Unfortunately the "require" model, while having a noble goal, tends to work against this. With some extensions (such as "spamtest"), there's not much that can be done about it (other than having a way to conditionalize based on the presence of cababilities, as I've said elsewhere). But with something like "refuse" I think there is- simply by allowing its best-effort use with a fallback if it's unavailable. Some cases: a) Surely it would be good to encourage people to design their scripts to use "refuse" now, even if the environment won't support it until some time in the future. When the environment does support it, peoples' existing scripts would suddenly do better things. b) On a server-wide administrative level, things change. Imagine a change to an SMTP server that makes "refuse" not work- either for a short while, or for the long term. Neither is hard to imagine. This is what I had in mind when I said something about "refuse being situationally unavailable." Without a fallback capability, such system-wide changes would be a nightmare. c) Similarly, one should allow for scripts to be pushed off to other instances of mail servers which handle incoming mail for a large environment, not all of which are architected the same. d) Part of designing language elements such as this is not having to imagine every eventuality, but rather providing options that allow flexibility in the face of currently-unknown future situations. Planning for a best-attempt "refuse" with a fallback strikes me as much better than an all-or-nothing "refuse" without one. If SIEVE provided conditionals based on capabilities, there'd be no need for this, and perhaps I wouldn't be suggesting it ('tho maybe I would). But it doesn't, and so I am. Bottom line: I would prefer a "refuse if you can" kind of spec, for all the reasons stated. It would allow for more flexibility in script writing, better script portability, better anticipation of SMTP-time support for scripts now, and less headaches for system administrators. Yours, -mm- From owner-ietf-mta-filters Tue Jun 8 19:46:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i592kjAS090220; Tue, 8 Jun 2004 19:46:45 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i592kjnu090219; Tue, 8 Jun 2004 19:46:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i592kiq3090212 for ; Tue, 8 Jun 2004 19:46:44 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: NS3QNxXEARM/BGZyIyDk6w 1086749205 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id C3C87C0666D; Tue, 8 Jun 2004 22:46:45 -0400 (EDT) Message-ID: <40C67A10.1000002@elvey.com> Date: Tue, 08 Jun 2004 19:46:40 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: "refuse" ; Re: Registration of new Sieve extensions, and changes. (sieve-extensions) References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . 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: An FYI, and a new post. ----------- FYI, per an earlier post, I contacted IANA and heard back a month later: On 6/8/2004 12:47 PM, IANA sent forth electrons to convey: Matthew, We have corrected the reference in the sieve-extensions registry and registered the 2 sieve-extensions mentioned below. Capability name: refuse Capability keyword: refuse Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [draft-elvey-refuse-sieve-01.txt] Person and email address to contact for further information: Matthew Elvey The Elvey Partnership, LLC 3042 Sacramento-ietf St Ste 04 San Francisco, CA U.S.A. sieve3@matthew.elvey.com AND Capability name: regex Capability keyword: regex Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [draft-murchison-sieve-regex-07.txt] Person and email address to contact for further information: Kenneth Murchison ken@oceana.com Please see: Please note: Extensions designed for interoperable use SHOULD be defined as standards track or IESG approved experimental RFCs. Best regards, Michelle Cotton IANA -----Original Message----- From: Matthew Elvey [mailto:matthew@elvey.com] Sent: Saturday, May 08, 2004 2:49 PM To: iana@iana.org Subject: Registration of new Sieve extensions, and changes. Hello, and thanks for your public service. I think http://www.iana.org/assignments/sieve-extensions needs some updates. An RFC # (3685) has been associated with spamtest and virustest. -see http://www.faqs.org/rfcs/rfc3685.html Please add the RFC #, and add the following entries: Per http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt : Capability name: refuse Capability keyword: refuse Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [RFC-elvey-refuse-sieve-01.txt] Person and email address to contact for further information: Matthew Elvey The Elvey Partnership, LLC 3042 Sacramento-ietf St Ste 04 San Francisco, CA U.S.A. sieve3@matthew.elvey.com Per http://www.ietf.org/internet-drafts/draft-murchison-sieve-regex-07.txt : Capability name: regex Capability keyword: regex Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [RFC-murchison-sieve-regex-07.txt] Person and email address to contact for further information: Kenneth Murchison ken@oceana.com Thanks, Matthew --------------- Also, here's an email I sent to Mark M and ietf-mta-filters-request@imc.org instead of ietf-mta-filters@imc.org: On 6/7/2004 11:19 AM, Matthew Elvey sent forth electrons to convey: >> I'm suggesting that the spec should be adjusted to allow a best-effort >> "refuse" with a fallback to another action... > > > > Please suggest the specific other action you would like it to fallback > to; if you don't it's difficult to make progress. > Is the specific other action bitbucketing? That is what you were > suggesting earlier. > > >> Imagine a >> change to an SMTP server that makes "refuse" not work- either for >> a short while, or for the long term. Neither is hard to imagine. >> > Please assume I have no imagination, and provide a specific example, of > > "situationally unavailable" which would result in a problem > > so we can discuss a specific situation. > I can't think of such a situation where there would be a resulting > problem. > > I will respond further to your email, but want to deal with these > points first. > From owner-ietf-mta-filters Sun Jun 13 14:24:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DLOnIP052222; Sun, 13 Jun 2004 14:24:49 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DLOnVh052221; Sun, 13 Jun 2004 14:24:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mx.mail.rcn.net ([213.214.224.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5DLO2MH051785 for ; Sun, 13 Jun 2004 14:24:47 -0700 (PDT) (envelope-from jehorton@erols.com) Date: Sun, 13 Jun 2004 21:24:35 +0000 From: Jehorton Subject: IndispensableSoftWare on cd... needy? seeBody To: Ietf-mta-filters References: <0E09G930082AF7JD@imc.org> In-Reply-To: <0E09G930082AF7JD@imc.org> Message-ID: <9FJ73D1E46HE3ED1@erols.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ietf-mta-filters http://FJGCNA.info/OE017/?affiliate_id=233642&campaign_id=601 http://BENBCE.info/OE017/?affiliate_id=233642&campaign_id=601 Bye-bye From owner-ietf-mta-filters Mon Jun 21 06:35:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LDZahq082792; Mon, 21 Jun 2004 06:35:36 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LDZa5l082791; Mon, 21 Jun 2004 06:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from id081.wkap.nl (id081.wkap.nl [195.169.64.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LDZZmi082781 for ; Mon, 21 Jun 2004 06:35:35 -0700 (PDT) (envelope-from R.E.Sonneveld@sonnection.nl) Received: from CONVERSION-DAEMON.wkap.nl by wkap.nl (PMDF V6.2-X17 #30922) id <01LBKBFVJXIO9JDKVJ@wkap.nl> for ietf-mta-filters@imc.org; Mon, 21 Jun 2004 15:35:36 +0200 (MET) Received: from PC1101 ([195.169.64.97]) by wkap.nl (PMDF V6.2-X17 #30921) with ESMTP id <01LBKBFV970K8WZJ8T@wkap.nl>; Mon, 21 Jun 2004 15:35:28 +0200 (MET) Date: Mon, 21 Jun 2004 15:35:27 +0200 From: "Rolf E. Sonneveld" Subject: Question on separators in localpart To: ietf-mta-filters@imc.org Cc: r.e.sonneveld@sonnection.nl Reply-to: R.E.Sonneveld@sonnection.nl Message-id: <6DFAA8CF01F3E243BE4D137CBF7E4F4F0965B919@id194.kapnet.intra> Organization: Sonnection B.V. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_yek982cZ6kTg9wdkJWX7hA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, some time ago a discussion took place on this list about 'detail separators'. I can't recall the details of the discussion. But on the subject of 'detail separators' I have a question. For a new to-be-created e-mail address naming convention, user addresses will get the notation First.Last@domain.com. AFAIK this is in general use at many organizations worldwide. For functional mailboxes there are multiple choices. My question is: is it better to use (e.g.): HelpDesk.London@domain.com (dot in localpart) HelpDesk-London@domain.com (hyphen in localpart) HelpDesk_London@domain.com (underscore in localpart) I believe the 'underscore' will possibly cause other problems (e.g. when gatewayed into the X.400 world), so the question is mainly whether the use of either format 1 (dot) or format 2 (hyphen) will cause any possible problems for SIEVE scripts? Regards, /rolf --Boundary_(ID_yek982cZ6kTg9wdkJWX7hA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D= =0A=0D=0A

Hi,

= =0D=0A=0D=0A

 =

=0D=0A=0D=0A

some time ago a = discussion took place on this list about ‘detail=0D=0Aseparator= s’. I can’t recall the details of the discussion. But on= =0D=0Athe subject of ‘detail separators’ I have a questio= n.

=0D=0A=0D=0A

=  

=0D=0A=0D=0A

For a new to-be-created e-mail address naming convention,=0D= =0Auser addresses will get the notation First.Last@domain.com.=0D=0AAFAIK this is in general = use at many organizations worldwide.

=0D=0A=0D=0A

 

=0D=0A=0D= =0A

For functional mailboxes ther= e are multiple choices. My=0D=0Aquestion is: is  it better to us= e (e.g.):

=0D=0A=0D=0A

 

=0D=0A=0D=0A

HelpDesk.Lon= don@domain.com=0D=0A(dot in localpart)

=0D=0A= =0D=0A

HelpDesk-London@domain.com=0D=0A(hyphen in= localpart)

=0D=0A=0D=0A

HelpDesk_Londo= n@domain.com=0D=0A(underscore in localpart)

= =0D=0A=0D=0A

 =

=0D=0A=0D=0A

I believe the &#= 8216;underscore’ will possibly cause=0D=0Aother problems (e.g. = when gatewayed into the X.400 world), so the question is=0D=0Amainly = whether the use of either format 1 (dot) or format 2 (hyphen) will ca= use=0D=0Aany possible problems for SIEVE scripts?

= =0D=0A=0D=0A

 =

=0D=0A=0D=0A

Regards,<= /font>

=0D=0A=0D=0A

/rolf

=0D=0A=0D=0A

&nb= sp;

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A= --Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)-- From owner-ietf-mta-filters Mon Jun 21 13:14:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKEwGs059338; Mon, 21 Jun 2004 13:14:58 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LKEwVq059337; Mon, 21 Jun 2004 13:14:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKEv8b059327 for ; Mon, 21 Jun 2004 13:14:57 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i5LKEwtC029746; Mon, 21 Jun 2004 16:14:58 -0400 Date: Mon, 21 Jun 2004 16:14:57 -0400 (EDT) From: Rob Siemborski To: Rob Mueller cc: ietf-mta-filters@imc.org Subject: Re: State of notify draft... In-Reply-To: <00f501c457cb$01c26070$29afc742@ROBMHP> Message-ID: References: <00f501c457cb$01c26070$29afc742@ROBMHP> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 21 Jun 2004, Rob Mueller wrote: > So it seems we have an original draft, comments about problems, and even > agreement by the original author, but no followup as yet :( I'll note that MANAGESIEVE is in much the same state. I guess this is a disadvanteage of proceeding without an official Working Group... -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-mta-filters Mon Jun 21 13:04:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LK4jMU057737; Mon, 21 Jun 2004 13:04:45 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LK4id1057736; Mon, 21 Jun 2004 13:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LK4dhx057703 for ; Mon, 21 Jun 2004 13:04:39 -0700 (PDT) (envelope-from robm@fastmail.fm) X-Sasl-enc: 7vmLShKEJwTgTjIXz8UHqA 1087848279 Received: from ROBMHP (66.199.175.41.novustelecom.net [66.199.175.41]) by mail.messagingengine.com (Postfix) with ESMTP id AE1B8C0CEFD; Mon, 21 Jun 2004 16:04:34 -0400 (EDT) Message-ID: <00f501c457cb$01c26070$29afc742@ROBMHP> From: "Rob Mueller" To: Cc: "Wolfgang Segmuller" , "Simon Josefsson" , "\"Nigel Swinson\"" , , , "Jutta Degener" , "Jeremy Howard" Subject: State of notify draft... Date: Mon, 21 Jun 2004 13:04:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2149 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi I'm just trying to find out if anyone knows anything more about the current state of the notify extension. Looking from the list archive I can see this was first announced on 03 Jul 2001: http://www.imc.org/ietf-mta-filters/mail-archive/msg00972.html A couple of good points re $from$ vs $from-address$ vs $from-name$ and QP and charset decoding were raised here: http://www.imc.org/ietf-mta-filters/mail-archive/msg00973.html And there was tentative agreement on many of these issues from the original draft author stating that he'd create a new one. http://www.imc.org/ietf-mta-filters/mail-archive/msg00980.html Though there didn't appear to have been another draft forth coming, and searching the list, almost no discussion on the "notify" extension since then, apart from a similar "what's up" email here: http://www.imc.org/ietf-mta-filters/mail-archive/msg01007.html So it seems we have an original draft, comments about problems, and even agreement by the original author, but no followup as yet :( I'm wondering what the general process for going forward and creating another draft with some of these issues addressed? I think that having a non-decoded text/* part in an arbitrary character set will be somewhere between annoying and useless, and the separated $from-address$ and $from-name$ variables would be very useful. Is there anyone interested in/able to create a new draft? If not, I'd be willing to do it, but I'm not entirely sure of the process of taking over and going forward with this. Rob From owner-ietf-mta-filters Tue Jun 22 01:33:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M8XtNF037895; Tue, 22 Jun 2004 01:33:55 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M8Xt6s037893; Tue, 22 Jun 2004 01:33:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M8XmHx037802 for ; Tue, 22 Jun 2004 01:33:55 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id B17BF1A705; Tue, 22 Jun 2004 10:33:45 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id AE89D1A6B5; Tue, 22 Jun 2004 10:33:42 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: "Rolf E. Sonneveld" Subject: Re: Question on separators in localpart Cc: ietf-mta-filters@imc.org References: <6DFAA8CF01F3E243BE4D137CBF7E4F4F0965B919@id194.kapnet.intra> In-Reply-To: <6DFAA8CF01F3E243BE4D137CBF7E4F4F0965B919@id194.kapnet.intra> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Jun 2004 10:35:13 +0200 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rolf E. Sonneveld writes: > I believe the 'underscore' will possibly cause other problems (e.g. > when gatewayed into the X.400 world), so the question is mainly > whether the use of either format 1 (dot) or format 2 (hyphen) will > cause any possible problems for SIEVE scripts? No. Btw, the underscore may cause some problems when e-mail addresses are read over the phone. People are less used to underscores in email addresses than to hyphens or dots. Arnt From owner-ietf-mta-filters Wed Jun 23 11:46:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIk5V0050105; Wed, 23 Jun 2004 11:46:05 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NIk5Js050102; Wed, 23 Jun 2004 11:46:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIk4W2050075 for ; Wed, 23 Jun 2004 11:46:05 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i5NIoNtm005941 for ; Wed, 23 Jun 2004 14:50:23 -0400 (EDT) Message-ID: <40D9D018.7090803@oceana.com> Date: Wed, 23 Jun 2004 14:46:48 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF MTA Filters List Subject: :binary in draft-degener-sieve-body-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What is the intended use of :binary? If its for checking virus signatures, isn't this better suited to virustest? The reason I ask is that I've spent the last few days adding body support to Cyrus Sieve and implementing :binary as its currently documented is non-trivial and potentially expensive in both memory and CPU (especially if coupled with :regex). So, is :binary really necessary, and if so, can it be moved to a separate extension (e.g. 'binary' or 'body-binary') so that it isn't a requirement for implementing text-based body tests? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-mta-filters Wed Jun 23 13:20:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKKYf9070316; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKKYQx070315; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKKYoX070308 for ; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) (envelope-from jutta@sendmail.com) Received: from jutta.sendmail.com ([10.210.202.37]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i5NKKZgr019766; Wed, 23 Jun 2004 13:20:36 -0700 Received: by jutta.sendmail.com (Postfix, from userid 500) id 58E70179AA; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) Date: Wed, 23 Jun 2004 13:20:34 -0700 From: Jutta Degener To: Ken Murchison Cc: IETF MTA Filters List Subject: Re: :binary in draft-degener-sieve-body-02.txt Message-ID: <20040623202034.GE1725@jutta.sendmail.com> References: <40D9D018.7090803@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D9D018.7090803@oceana.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > What is the intended use of :binary? If its for checking virus > signatures, isn't this better suited to virustest? The "virustest" predicate operates on a much higher level of abstraction than :binary. Obviously, if all you want to do is test against viruses, and you have a working, well-maintained virustest support from your ISP, you won't need :binary. But apart from making up for insufficient or outdated virus- and spam-shielding, :binary also has value as a catch-all tool that works even in the presence of bad or unkown charsets or badly used or specified MIME types. For example, it can look into a WAV file and distinguish WAV-encoded GSM from WAV-encoded PCM, and feed to a telephony gateway only those formats the gateway is known to be able to decode. It can read version numbers of software formats, or become an ad-hoc way of looking into "wrapper" formats. > The reason I ask is > that I've spent the last few days adding body support to Cyrus Sieve > and implementing :binary as its currently documented is non-trivial and > potentially expensive in both memory and CPU (especially if coupled with > :regex). I've implemented :binary, too, and it didn't seem like a big overhead compared to, say, a charset conversion via iconv that the other options ask you to do to arrive at UTF-8. Do you remember what specifically got in your way? > So, is :binary really necessary, and if so, can it be moved to a > separate extension (e.g. 'binary' or 'body-binary') so that it isn't a > requirement for implementing text-based body tests? Sure, we can do that. This is just a draft. But I'd like to gather a little more experience with the implementations before aking a decision; maybe nobody ever uses it (I mean, it's not like the format really comes naturally to users...), and we can just drop it entirely. Or maybe it'll be so overwhelmingly useful that farming it out doesn't make sense after all. Jutta From owner-ietf-mta-filters Wed Jun 23 13:28:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKSf3P071947; Wed, 23 Jun 2004 13:28:41 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKSfos071946; Wed, 23 Jun 2004 13:28:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKSeoK071928 for ; Wed, 23 Jun 2004 13:28:41 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i5NKX3Rk011524; Wed, 23 Jun 2004 16:33:04 -0400 (EDT) Message-ID: <40D9E827.6000502@oceana.com> Date: Wed, 23 Jun 2004 16:29:27 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jutta Degener CC: IETF MTA Filters List Subject: Re: :binary in draft-degener-sieve-body-02.txt References: <40D9D018.7090803@oceana.com> <20040623202034.GE1725@jutta.sendmail.com> In-Reply-To: <20040623202034.GE1725@jutta.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jutta Degener wrote: > > I've implemented :binary, too, and it didn't seem like a big > overhead compared to, say, a charset conversion via iconv that > the other options ask you to do to arrive at UTF-8. Do you > remember what specifically got in your way? Nothing earth shattering, but the [decoded] body part needs to be expanded into space-separated hex (a 3x increase in size) in order to do the match. This *might* be avoidable by doing the "hex dump" on the fly for :contains and possibly :matches, but is necessary for :regex unless using a home-grown regex function/library. I thought about "decoding" the ascii-hex pattern and then comparing against the content, but that prohibits patterns such as "3c 4?" Or are patterns such as this prohibited (special pattern-matches chars can't be used as a placeholder for a nibble)? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKSf3P071947; Wed, 23 Jun 2004 13:28:41 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKSfos071946; Wed, 23 Jun 2004 13:28:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKSeoK071928 for ; Wed, 23 Jun 2004 13:28:41 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i5NKX3Rk011524; Wed, 23 Jun 2004 16:33:04 -0400 (EDT) Message-ID: <40D9E827.6000502@oceana.com> Date: Wed, 23 Jun 2004 16:29:27 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jutta Degener CC: IETF MTA Filters List Subject: Re: :binary in draft-degener-sieve-body-02.txt References: <40D9D018.7090803@oceana.com> <20040623202034.GE1725@jutta.sendmail.com> In-Reply-To: <20040623202034.GE1725@jutta.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jutta Degener wrote: > > I've implemented :binary, too, and it didn't seem like a big > overhead compared to, say, a charset conversion via iconv that > the other options ask you to do to arrive at UTF-8. Do you > remember what specifically got in your way? Nothing earth shattering, but the [decoded] body part needs to be expanded into space-separated hex (a 3x increase in size) in order to do the match. This *might* be avoidable by doing the "hex dump" on the fly for :contains and possibly :matches, but is necessary for :regex unless using a home-grown regex function/library. I thought about "decoding" the ascii-hex pattern and then comparing against the content, but that prohibits patterns such as "3c 4?" Or are patterns such as this prohibited (special pattern-matches chars can't be used as a placeholder for a nibble)? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKKYf9070316; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKKYQx070315; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKKYoX070308 for ; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) (envelope-from jutta@sendmail.com) Received: from jutta.sendmail.com ([10.210.202.37]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i5NKKZgr019766; Wed, 23 Jun 2004 13:20:36 -0700 Received: by jutta.sendmail.com (Postfix, from userid 500) id 58E70179AA; Wed, 23 Jun 2004 13:20:34 -0700 (PDT) Date: Wed, 23 Jun 2004 13:20:34 -0700 From: Jutta Degener To: Ken Murchison Cc: IETF MTA Filters List Subject: Re: :binary in draft-degener-sieve-body-02.txt Message-ID: <20040623202034.GE1725@jutta.sendmail.com> References: <40D9D018.7090803@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D9D018.7090803@oceana.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > What is the intended use of :binary? If its for checking virus > signatures, isn't this better suited to virustest? The "virustest" predicate operates on a much higher level of abstraction than :binary. Obviously, if all you want to do is test against viruses, and you have a working, well-maintained virustest support from your ISP, you won't need :binary. But apart from making up for insufficient or outdated virus- and spam-shielding, :binary also has value as a catch-all tool that works even in the presence of bad or unkown charsets or badly used or specified MIME types. For example, it can look into a WAV file and distinguish WAV-encoded GSM from WAV-encoded PCM, and feed to a telephony gateway only those formats the gateway is known to be able to decode. It can read version numbers of software formats, or become an ad-hoc way of looking into "wrapper" formats. > The reason I ask is > that I've spent the last few days adding body support to Cyrus Sieve > and implementing :binary as its currently documented is non-trivial and > potentially expensive in both memory and CPU (especially if coupled with > :regex). I've implemented :binary, too, and it didn't seem like a big overhead compared to, say, a charset conversion via iconv that the other options ask you to do to arrive at UTF-8. Do you remember what specifically got in your way? > So, is :binary really necessary, and if so, can it be moved to a > separate extension (e.g. 'binary' or 'body-binary') so that it isn't a > requirement for implementing text-based body tests? Sure, we can do that. This is just a draft. But I'd like to gather a little more experience with the implementations before aking a decision; maybe nobody ever uses it (I mean, it's not like the format really comes naturally to users...), and we can just drop it entirely. Or maybe it'll be so overwhelmingly useful that farming it out doesn't make sense after all. Jutta Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIk5V0050105; Wed, 23 Jun 2004 11:46:05 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NIk5Js050102; Wed, 23 Jun 2004 11:46:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIk4W2050075 for ; Wed, 23 Jun 2004 11:46:05 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i5NIoNtm005941 for ; Wed, 23 Jun 2004 14:50:23 -0400 (EDT) Message-ID: <40D9D018.7090803@oceana.com> Date: Wed, 23 Jun 2004 14:46:48 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF MTA Filters List Subject: :binary in draft-degener-sieve-body-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What is the intended use of :binary? If its for checking virus signatures, isn't this better suited to virustest? The reason I ask is that I've spent the last few days adding body support to Cyrus Sieve and implementing :binary as its currently documented is non-trivial and potentially expensive in both memory and CPU (especially if coupled with :regex). So, is :binary really necessary, and if so, can it be moved to a separate extension (e.g. 'binary' or 'body-binary') so that it isn't a requirement for implementing text-based body tests? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M8XtNF037895; Tue, 22 Jun 2004 01:33:55 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M8Xt6s037893; Tue, 22 Jun 2004 01:33:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M8XmHx037802 for ; Tue, 22 Jun 2004 01:33:55 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id B17BF1A705; Tue, 22 Jun 2004 10:33:45 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id AE89D1A6B5; Tue, 22 Jun 2004 10:33:42 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: "Rolf E. Sonneveld" Subject: Re: Question on separators in localpart Cc: ietf-mta-filters@imc.org References: <6DFAA8CF01F3E243BE4D137CBF7E4F4F0965B919@id194.kapnet.intra> In-Reply-To: <6DFAA8CF01F3E243BE4D137CBF7E4F4F0965B919@id194.kapnet.intra> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Jun 2004 10:35:13 +0200 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rolf E. Sonneveld writes: > I believe the 'underscore' will possibly cause other problems (e.g. > when gatewayed into the X.400 world), so the question is mainly > whether the use of either format 1 (dot) or format 2 (hyphen) will > cause any possible problems for SIEVE scripts? No. Btw, the underscore may cause some problems when e-mail addresses are read over the phone. People are less used to underscores in email addresses than to hyphens or dots. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKEwGs059338; Mon, 21 Jun 2004 13:14:58 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LKEwVq059337; Mon, 21 Jun 2004 13:14:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKEv8b059327 for ; Mon, 21 Jun 2004 13:14:57 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i5LKEwtC029746; Mon, 21 Jun 2004 16:14:58 -0400 Date: Mon, 21 Jun 2004 16:14:57 -0400 (EDT) From: Rob Siemborski To: Rob Mueller cc: ietf-mta-filters@imc.org Subject: Re: State of notify draft... In-Reply-To: <00f501c457cb$01c26070$29afc742@ROBMHP> Message-ID: References: <00f501c457cb$01c26070$29afc742@ROBMHP> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 21 Jun 2004, Rob Mueller wrote: > So it seems we have an original draft, comments about problems, and even > agreement by the original author, but no followup as yet :( I'll note that MANAGESIEVE is in much the same state. I guess this is a disadvanteage of proceeding without an official Working Group... -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LK4jMU057737; Mon, 21 Jun 2004 13:04:45 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LK4id1057736; Mon, 21 Jun 2004 13:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LK4dhx057703 for ; Mon, 21 Jun 2004 13:04:39 -0700 (PDT) (envelope-from robm@fastmail.fm) X-Sasl-enc: 7vmLShKEJwTgTjIXz8UHqA 1087848279 Received: from ROBMHP (66.199.175.41.novustelecom.net [66.199.175.41]) by mail.messagingengine.com (Postfix) with ESMTP id AE1B8C0CEFD; Mon, 21 Jun 2004 16:04:34 -0400 (EDT) Message-ID: <00f501c457cb$01c26070$29afc742@ROBMHP> From: "Rob Mueller" To: Cc: "Wolfgang Segmuller" , "Simon Josefsson" , "\"Nigel Swinson\"" , , , "Jutta Degener" , "Jeremy Howard" Subject: State of notify draft... Date: Mon, 21 Jun 2004 13:04:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2149 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi I'm just trying to find out if anyone knows anything more about the current state of the notify extension. Looking from the list archive I can see this was first announced on 03 Jul 2001: http://www.imc.org/ietf-mta-filters/mail-archive/msg00972.html A couple of good points re $from$ vs $from-address$ vs $from-name$ and QP and charset decoding were raised here: http://www.imc.org/ietf-mta-filters/mail-archive/msg00973.html And there was tentative agreement on many of these issues from the original draft author stating that he'd create a new one. http://www.imc.org/ietf-mta-filters/mail-archive/msg00980.html Though there didn't appear to have been another draft forth coming, and searching the list, almost no discussion on the "notify" extension since then, apart from a similar "what's up" email here: http://www.imc.org/ietf-mta-filters/mail-archive/msg01007.html So it seems we have an original draft, comments about problems, and even agreement by the original author, but no followup as yet :( I'm wondering what the general process for going forward and creating another draft with some of these issues addressed? I think that having a non-decoded text/* part in an arbitrary character set will be somewhere between annoying and useless, and the separated $from-address$ and $from-name$ variables would be very useful. Is there anyone interested in/able to create a new draft? If not, I'd be willing to do it, but I'm not entirely sure of the process of taking over and going forward with this. Rob Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LDZahq082792; Mon, 21 Jun 2004 06:35:36 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LDZa5l082791; Mon, 21 Jun 2004 06:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from id081.wkap.nl (id081.wkap.nl [195.169.64.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LDZZmi082781 for ; Mon, 21 Jun 2004 06:35:35 -0700 (PDT) (envelope-from R.E.Sonneveld@sonnection.nl) Received: from CONVERSION-DAEMON.wkap.nl by wkap.nl (PMDF V6.2-X17 #30922) id <01LBKBFVJXIO9JDKVJ@wkap.nl> for ietf-mta-filters@imc.org; Mon, 21 Jun 2004 15:35:36 +0200 (MET) Received: from PC1101 ([195.169.64.97]) by wkap.nl (PMDF V6.2-X17 #30921) with ESMTP id <01LBKBFV970K8WZJ8T@wkap.nl>; Mon, 21 Jun 2004 15:35:28 +0200 (MET) Date: Mon, 21 Jun 2004 15:35:27 +0200 From: "Rolf E. Sonneveld" Subject: Question on separators in localpart To: ietf-mta-filters@imc.org Cc: r.e.sonneveld@sonnection.nl Reply-to: R.E.Sonneveld@sonnection.nl Message-id: <6DFAA8CF01F3E243BE4D137CBF7E4F4F0965B919@id194.kapnet.intra> Organization: Sonnection B.V. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_yek982cZ6kTg9wdkJWX7hA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, some time ago a discussion took place on this list about 'detail separators'. I can't recall the details of the discussion. But on the subject of 'detail separators' I have a question. For a new to-be-created e-mail address naming convention, user addresses will get the notation First.Last@domain.com. AFAIK this is in general use at many organizations worldwide. For functional mailboxes there are multiple choices. My question is: is it better to use (e.g.): HelpDesk.London@domain.com (dot in localpart) HelpDesk-London@domain.com (hyphen in localpart) HelpDesk_London@domain.com (underscore in localpart) I believe the 'underscore' will possibly cause other problems (e.g. when gatewayed into the X.400 world), so the question is mainly whether the use of either format 1 (dot) or format 2 (hyphen) will cause any possible problems for SIEVE scripts? Regards, /rolf --Boundary_(ID_yek982cZ6kTg9wdkJWX7hA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D= =0A=0D=0A

Hi,

= =0D=0A=0D=0A

 =

=0D=0A=0D=0A

some time ago a = discussion took place on this list about ‘detail=0D=0Aseparator= s’. I can’t recall the details of the discussion. But on= =0D=0Athe subject of ‘detail separators’ I have a questio= n.

=0D=0A=0D=0A

=  

=0D=0A=0D=0A

For a new to-be-created e-mail address naming convention,=0D= =0Auser addresses will get the notation First.Last@domain.com.=0D=0AAFAIK this is in general = use at many organizations worldwide.

=0D=0A=0D=0A

 

=0D=0A=0D= =0A

For functional mailboxes ther= e are multiple choices. My=0D=0Aquestion is: is  it better to us= e (e.g.):

=0D=0A=0D=0A

 

=0D=0A=0D=0A

HelpDesk.Lon= don@domain.com=0D=0A(dot in localpart)

=0D=0A= =0D=0A

HelpDesk-London@domain.com=0D=0A(hyphen in= localpart)

=0D=0A=0D=0A

HelpDesk_Londo= n@domain.com=0D=0A(underscore in localpart)

= =0D=0A=0D=0A

 =

=0D=0A=0D=0A

I believe the &#= 8216;underscore’ will possibly cause=0D=0Aother problems (e.g. = when gatewayed into the X.400 world), so the question is=0D=0Amainly = whether the use of either format 1 (dot) or format 2 (hyphen) will ca= use=0D=0Aany possible problems for SIEVE scripts?

= =0D=0A=0D=0A

 =

=0D=0A=0D=0A

Regards,<= /font>

=0D=0A=0D=0A

/rolf

=0D=0A=0D=0A

&nb= sp;

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A= --Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DLOnIP052222; Sun, 13 Jun 2004 14:24:49 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DLOnVh052221; Sun, 13 Jun 2004 14:24:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mx.mail.rcn.net ([213.214.224.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5DLO2MH051785 for ; Sun, 13 Jun 2004 14:24:47 -0700 (PDT) (envelope-from jehorton@erols.com) Date: Sun, 13 Jun 2004 21:24:35 +0000 From: Jehorton Subject: IndispensableSoftWare on cd... needy? seeBody To: Ietf-mta-filters References: <0E09G930082AF7JD@imc.org> In-Reply-To: <0E09G930082AF7JD@imc.org> Message-ID: <9FJ73D1E46HE3ED1@erols.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ietf-mta-filters http://FJGCNA.info/OE017/?affiliate_id=233642&campaign_id=601 http://BENBCE.info/OE017/?affiliate_id=233642&campaign_id=601 Bye-bye Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i592kjAS090220; Tue, 8 Jun 2004 19:46:45 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i592kjnu090219; Tue, 8 Jun 2004 19:46:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i592kiq3090212 for ; Tue, 8 Jun 2004 19:46:44 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: NS3QNxXEARM/BGZyIyDk6w 1086749205 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id C3C87C0666D; Tue, 8 Jun 2004 22:46:45 -0400 (EDT) Message-ID: <40C67A10.1000002@elvey.com> Date: Tue, 08 Jun 2004 19:46:40 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: "refuse" ; Re: Registration of new Sieve extensions, and changes. (sieve-extensions) References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . 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: An FYI, and a new post. ----------- FYI, per an earlier post, I contacted IANA and heard back a month later: On 6/8/2004 12:47 PM, IANA sent forth electrons to convey: Matthew, We have corrected the reference in the sieve-extensions registry and registered the 2 sieve-extensions mentioned below. Capability name: refuse Capability keyword: refuse Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [draft-elvey-refuse-sieve-01.txt] Person and email address to contact for further information: Matthew Elvey The Elvey Partnership, LLC 3042 Sacramento-ietf St Ste 04 San Francisco, CA U.S.A. sieve3@matthew.elvey.com AND Capability name: regex Capability keyword: regex Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [draft-murchison-sieve-regex-07.txt] Person and email address to contact for further information: Kenneth Murchison ken@oceana.com Please see: Please note: Extensions designed for interoperable use SHOULD be defined as standards track or IESG approved experimental RFCs. Best regards, Michelle Cotton IANA -----Original Message----- From: Matthew Elvey [mailto:matthew@elvey.com] Sent: Saturday, May 08, 2004 2:49 PM To: iana@iana.org Subject: Registration of new Sieve extensions, and changes. Hello, and thanks for your public service. I think http://www.iana.org/assignments/sieve-extensions needs some updates. An RFC # (3685) has been associated with spamtest and virustest. -see http://www.faqs.org/rfcs/rfc3685.html Please add the RFC #, and add the following entries: Per http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt : Capability name: refuse Capability keyword: refuse Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [RFC-elvey-refuse-sieve-01.txt] Person and email address to contact for further information: Matthew Elvey The Elvey Partnership, LLC 3042 Sacramento-ietf St Ste 04 San Francisco, CA U.S.A. sieve3@matthew.elvey.com Per http://www.ietf.org/internet-drafts/draft-murchison-sieve-regex-07.txt : Capability name: regex Capability keyword: regex Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: [RFC-murchison-sieve-regex-07.txt] Person and email address to contact for further information: Kenneth Murchison ken@oceana.com Thanks, Matthew --------------- Also, here's an email I sent to Mark M and ietf-mta-filters-request@imc.org instead of ietf-mta-filters@imc.org: On 6/7/2004 11:19 AM, Matthew Elvey sent forth electrons to convey: >> I'm suggesting that the spec should be adjusted to allow a best-effort >> "refuse" with a fallback to another action... > > > > Please suggest the specific other action you would like it to fallback > to; if you don't it's difficult to make progress. > Is the specific other action bitbucketing? That is what you were > suggesting earlier. > > >> Imagine a >> change to an SMTP server that makes "refuse" not work- either for >> a short while, or for the long term. Neither is hard to imagine. >> > Please assume I have no imagination, and provide a specific example, of > > "situationally unavailable" which would result in a problem > > so we can discuss a specific situation. > I can't think of such a situation where there would be a resulting > problem. > > I will respond further to your email, but want to deal with these > points first. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i575ENiZ089583; Sun, 6 Jun 2004 22:14:23 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i575EMCw089582; Sun, 6 Jun 2004 22:14:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i575ELQp089555 for ; Sun, 6 Jun 2004 22:14:22 -0700 (PDT) (envelope-from mem@mv.mv.com) Received: (qmail 7556 invoked from network); 7 Jun 2004 01:14:26 -0400 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 7 Jun 2004 01:14:26 -0400 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 6582 invoked by uid 101); 7 Jun 2004 01:14:25 -0400 From: "Mark E. Mallett" Date: Mon, 7 Jun 2004 01:14:25 -0400 To: Matthew Elvey Cc: "Mark E. Mallett" , ietf-mta-filters@imc.org Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt Message-ID: <20040607051425.GG12334@iridium.mv.net> References: <4079E9CA.3010106@elvey.fastmail.fm> <20040604122913.GA29859@iridium.mv.net> <40C0CB82.60507@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C0CB82.60507@elvey.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jun 04, 2004 at 12:20:34PM -0700, Matthew Elvey wrote: > On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey: > >This may not be the only fallback case. I could envision other cases > >where smtp-time "refuse" was generally implemented, but situationally > >unavailable. (You've identified one.) As you say, existing scripts > >should continue to run. > > > What do you envision? I haven't thought of any others and don't think > there are any. a) All it takes is one such case for the point to apply. The fact that there is one at all is enough. b) I alluded to some more broader cases and even gave a f'rinstance. The key is "situationally unavailable." In fact there are other arguments that apply here that don't apply to (a). I'll expand a little below. > We designed the spec consciously so that, e.g. MUAs can't implement > "refuse". > In other words, if you want to , tough, if your > implementation can't handle it. > If it claims to, it's violating our spec. We can't physically prevent > this from happening though. > We state it strongly: > > "A SIEVE implementation that cannot do so MUST NOT claim > to support the refuse extension." Well that's all very self-referential as an answer :-) I'm suggesting that the spec should be adjusted to allow a best-effort "refuse" with a fallback to another action, and your refutation is that the spec doesn't allow it. That's too circular of a way to respond to the suggestion. > >I'd take that into account by being able to specify a fallback option > >should "refuse" not be present. And if you give the ability to have a > >fallback option, you could make the default fallback action be > >"discard" rather than "reject" -- and force the script writer to > >specify a preference for reject if for some reason they wanted to use > >it. > > > That's being much more cavalier with people's email than I'm comfortable > with, Actually it's the opposite of being cavalier: it's giving more options to the script writer. I'm trying to see how you classify it as cavalier- perhaps you think I'm saying that the only action be discard, and not the default one? Figuring out what the best default is is a matter that's best done before people start writing scripts. Having a default doesn't preclude other deliberate actions. I simply suggest a default that encompasses the usual case; defaults constructed in that way help minimize code and enhance clarity. > especially if one is optimistic that we will have a pretty > effective antispam solution in the fairly near future - effective enough > to drive a bunch of them out of the business. That would be nice. Even if that comes to pass, "refuse" and other actions will still be useful. > There's an RFC for unilaterally preventing joe jobs, and someone > reinvented the same or came up with a similar solution at the recent > ASRG MARID meeting. > I could look it up if you're interested. most others later are repeated from my email of 5/25 to which I haven't > received a response(!?).> Sorry, maybe I wasn't clear. I did respond- I said that any extended back and forth discussion would be better on the list, and I promised to restate my thoughts here. Which I did (it took me a while, sorry). Anyway, on to specifics about "situational unavailability" of "refuse." Mainly I'm concerned not so much about individual scripts but about script portability and overall system administration. For language growth I'd like to help ensure that scripts can be written in a way that lets people move them from one environment to another without having to completely rewrite them. Unfortunately the "require" model, while having a noble goal, tends to work against this. With some extensions (such as "spamtest"), there's not much that can be done about it (other than having a way to conditionalize based on the presence of cababilities, as I've said elsewhere). But with something like "refuse" I think there is- simply by allowing its best-effort use with a fallback if it's unavailable. Some cases: a) Surely it would be good to encourage people to design their scripts to use "refuse" now, even if the environment won't support it until some time in the future. When the environment does support it, peoples' existing scripts would suddenly do better things. b) On a server-wide administrative level, things change. Imagine a change to an SMTP server that makes "refuse" not work- either for a short while, or for the long term. Neither is hard to imagine. This is what I had in mind when I said something about "refuse being situationally unavailable." Without a fallback capability, such system-wide changes would be a nightmare. c) Similarly, one should allow for scripts to be pushed off to other instances of mail servers which handle incoming mail for a large environment, not all of which are architected the same. d) Part of designing language elements such as this is not having to imagine every eventuality, but rather providing options that allow flexibility in the face of currently-unknown future situations. Planning for a best-attempt "refuse" with a fallback strikes me as much better than an all-or-nothing "refuse" without one. If SIEVE provided conditionals based on capabilities, there'd be no need for this, and perhaps I wouldn't be suggesting it ('tho maybe I would). But it doesn't, and so I am. Bottom line: I would prefer a "refuse if you can" kind of spec, for all the reasons stated. It would allow for more flexibility in script writing, better script portability, better anticipation of SMTP-time support for scripts now, and less headaches for system administrators. Yours, -mm- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54JKf8G068090; Fri, 4 Jun 2004 12:20:41 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54JKfkE068089; Fri, 4 Jun 2004 12:20:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54JKfWf068073 for ; Fri, 4 Jun 2004 12:20:41 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: qpj8Wil7VVT3crQCAph/9g 1086376841 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 98799C04712; Fri, 4 Jun 2004 15:20:39 -0400 (EDT) Message-ID: <40C0CB82.60507@elvey.com> Date: Fri, 04 Jun 2004 12:20:34 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mark E. Mallett" Cc: ietf-mta-filters@imc.org Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt References: <4079E9CA.3010106@elvey.fastmail.fm> <20040604122913.GA29859@iridium.mv.net> In-Reply-To: <20040604122913.GA29859@iridium.mv.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . 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: On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey: >This is a fine draft. I have a few musings that I sent to Matthew >earlier that I'll twist around a little here- don't mistake these as >objections though, there's really not a lot to object to. Not sure I >made that clear earlier. But I do think there are some points to >raise, if not ponder. > >In this draft there are some great justifications for script writers >to use "refuse" rather than "reject. However there's this: > > > >>There is an exception when a single message has multiple SMTP >>recipients, and at least one but not all of them are refusing delivery >>(whether the refusal is caused by execution of a Sieve "refuse" or for >>another reason). In this case, the server MUST accept the message and >>generate DSNs for all recipients that are refusing it. >> >> > >This may not be the only fallback case. I could envision other cases >where smtp-time "refuse" was generally implemented, but situationally >unavailable. (You've identified one.) As you say, existing scripts >should continue to run. > > What do you envision? I haven't thought of any others and don't think there are any. We designed the spec consciously so that, e.g. MUAs can't implement "refuse". In other words, if you want to , tough, if your implementation can't handle it. If it claims to, it's violating our spec. We can't physically prevent this from happening though. We state it strongly: "A SIEVE implementation that cannot do so MUST NOT claim to support the refuse extension." >I see a conundrum, in that script writers will feel assured that by >using "refuse" they will not be generating bounces. Without "refuse" a >conscientious script writer would probably have used "discard" or >"fileinto" -- anything other than "reject." However, in the presence >of a "refuse" option, the same conscientious script writer will likely >use "refuse." So under some conditions the very presence of this >option could increase the likelihood of generating rejects. No matter >what percentage this represents, I'd feel better if that were taken >into account. > > This will happen if the implementation is defective (and in the listed exceptional case, which I'm not worried about). I think what we've done already will prevent this from being a real problem. >I'd take that into account by being able to specify a fallback option >should "refuse" not be present. And if you give the ability to have a >fallback option, you could make the default fallback action be >"discard" rather than "reject" -- and force the script writer to >specify a preference for reject if for some reason they wanted to use >it. > > That's being much more cavalier with people's email than I'm comfortable with, especially if one is optimistic that we will have a pretty effective antispam solution in the fairly near future - effective enough to drive a bunch of them out of the business. There's an RFC for unilaterally preventing joe jobs, and someone reinvented the same or came up with a similar solution at the recent ASRG MARID meeting. I could look it up if you're interested. For example, here's a problem: I admin a few mailing lists (verified opt-in, of course.) One is political and has severe deliverability problems that I'm working to fix. Not getting any indication that mail hasn't been delivered makes this task much harder. The ideas below are good ideas for improving Sieve, but are out of scope for my draft. It would be in scope for a new version of Sieve, and would require several extension specs be changed to work well with it. I think we've made the best of a bad situation; don't see how we can improve the "refuse" spec. >I don't even think that's the best alternative: better would be some >more systemic-level enhancements to SIEVE that would allow certain >conditions to be tested and operated on. For example, being able to >test whether "refuse" succeeded would help: > > if not refuse "This looks like spam" { > discard; > } > > Yeah, this would be nice, but it's not something I'm able to take on. I'd support it. IIRC, Sieve actions don't have return values. >Less disruptive systemic changes could be devised; for example being >able to test the status of the implicit keep flag: > > refuse "This looks like spam"; > if not ikeep { discard; } > >Or something like a "stop" if successful: > > refuse :stop "This looks like spam"; > discard; > > >This branches into a train of thought about general script portability: >I've mentioned in the past that it would be nice to be able to have >conditions depending on what mode a script was running in, or what >capabilities were supported, so that scripts could continue to run in >the face of changing environments. ("changing environments" was in >fact one of the cases I had in mind above, when I mentioned that there >could be other situations in which "refuse" is unavailable. One has >to think of the system administration too.) Other than that, I'm >obviously getting farther away from "refuse" -- but I often think that >some broader thinking about SIEVE extensions would help keep the >language more whole in the face of these optional capabilities. >(That's rather brusque but I don't want to go on here too long..) > >At any rate, those are some thoughts. > >-mm- > > > PPS I find your comments constructive and helpful, though my to-the-point comments and questions might make it seem otherwise. Thanks. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54CTJJw008439; Fri, 4 Jun 2004 05:29:19 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54CTJFx008438; Fri, 4 Jun 2004 05:29:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i54CTFH7008420 for ; Fri, 4 Jun 2004 05:29:18 -0700 (PDT) (envelope-from mem@mv.mv.com) Received: (qmail 24961 invoked from network); 4 Jun 2004 08:29:15 -0400 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 4 Jun 2004 08:29:15 -0400 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 15251 invoked by uid 101); 4 Jun 2004 08:29:13 -0400 From: "Mark E. Mallett" Date: Fri, 4 Jun 2004 08:29:13 -0400 To: ietf-mta-filters@imc.org Cc: "Mark E. Mallett" Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt Message-ID: <20040604122913.GA29859@iridium.mv.net> References: <4079E9CA.3010106@elvey.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4079E9CA.3010106@elvey.fastmail.fm> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a fine draft. I have a few musings that I sent to Matthew earlier that I'll twist around a little here- don't mistake these as objections though, there's really not a lot to object to. Not sure I made that clear earlier. But I do think there are some points to raise, if not ponder. In this draft there are some great justifications for script writers to use "refuse" rather than "reject. However there's this: > There is an exception when a single message has multiple SMTP > recipients, and at least one but not all of them are refusing delivery > (whether the refusal is caused by execution of a Sieve "refuse" or for > another reason). In this case, the server MUST accept the message and > generate DSNs for all recipients that are refusing it. This may not be the only fallback case. I could envision other cases where smtp-time "refuse" was generally implemented, but situationally unavailable. (You've identified one.) As you say, existing scripts should continue to run. I see a conundrum, in that script writers will feel assured that by using "refuse" they will not be generating bounces. Without "refuse" a conscientious script writer would probably have used "discard" or "fileinto" -- anything other than "reject." However, in the presence of a "refuse" option, the same conscientious script writer will likely use "refuse." So under some conditions the very presence of this option could increase the likelihood of generating rejects. No matter what percentage this represents, I'd feel better if that were taken into account. I'd take that into account by being able to specify a fallback option should "refuse" not be present. And if you give the ability to have a fallback option, you could make the default fallback action be "discard" rather than "reject" -- and force the script writer to specify a preference for reject if for some reason they wanted to use it. I don't even think that's the best alternative: better would be some more systemic-level enhancements to SIEVE that would allow certain conditions to be tested and operated on. For example, being able to test whether "refuse" succeeded would help: if not refuse "This looks like spam" { discard; } Less disruptive systemic changes could be devised; for example being able to test the status of the implicit keep flag: refuse "This looks like spam"; if not ikeep { discard; } Or something like a "stop" if successful: refuse :stop "This looks like spam"; discard; This branches into a train of thought about general script portability: I've mentioned in the past that it would be nice to be able to have conditions depending on what mode a script was running in, or what capabilities were supported, so that scripts could continue to run in the face of changing environments. ("changing environments" was in fact one of the cases I had in mind above, when I mentioned that there could be other situations in which "refuse" is unavailable. One has to think of the system administration too.) Other than that, I'm obviously getting farther away from "refuse" -- but I often think that some broader thinking about SIEVE extensions would help keep the language more whole in the face of these optional capabilities. (That's rather brusque but I don't want to go on here too long..) At any rate, those are some thoughts. -mm-