Spam
Now that the federal government has taken some steps in regulating spam, does that mean that a technical need as the IETF would look for, isn't needed? Maybe the Spam should be forgot about. Bill
Re: Adding [ietf] considered harmful
Is invoking Microsoft close enough to invoking Hitler to end this thread? (Hint: "please!"). Keith is right. If you don't like the way the IETF discussion list comes into your mailbox, start a reflector that fixes it the way you like it. IETF+censored does more violence to its contents than we're talking about now, and I wouldn't dream of subscribing without it... Spencer
Re: Tag, You're It!
On Wed, 17 Dec 2003 17:59:40 EST, Eric Burger <[EMAIL PROTECTED]> said: > I would offer that worrying about signed signatures when we don't have signed mail Oh? pgp0.pgp Description: PGP signature
Re: Adding [ietf] considered harmful
On Thu, 18 Dec 2003 10:39:21 +1200, Franck Martin said: > Why such a war for just 6 characters, while all mailing lists do it? If "all mailing lists do it" (which in itself is a dubious assertion) is sufficient justification, why are we bothering with an IETF? Maybe we should just disband and let Redmond write the standards, since "all computers do it". pgp0.pgp Description: PGP signature
Re: Adding [ietf] considered harmful
On Wed, 17 Dec 2003, Keith Moore wrote: > > Because we, people on the road, use various mail systems and even web > > based mail > > so do the rest of us. ever tried to read mail from a palm pilot? > those [foo] turds get *really* annoying... > > > Why such a war for just 6 characters, while all mailing lists do it? > > because I've tried it, and found it to be a royal pain in the wazoo. > > > Have you been out there? > > yup. > > > Let's give it a try and see... > > feel free to set up your own list mirror that prepends [ietf]. Or for all of those so free with advice that the rest of us endeavor to program our clients, servers, etc. to add the tag, you could just program yours to remove it. Clearly y'all have more expertise in this space and interest in gaining expertise with mail software. Should be a snap. Or just change the IETF list manager to which which makes addition of the tag optional by subscriber. I've encountered that feature in the past so I know it is available. Dave Morris
Re: Adding SpamAssassin Headers to IETF mail
Tuesday 16 December 2003, Sandy Wills wrote: > Would it be possible to somehow flag messages as "valid" or "bogus" > (or maybe "Holy Writ" or "Message from Satan"), and then allow > subscribers to set their systems to automatically filter on these > labels, if they care? Spamassassin has the capability of (optionally) adding a header "X-Spam-Level: " followed by a count of star which matches the spam score calculated by spamassassin. This makes it easy to filter, at an integer level, - if you want to filter at all. Set your mail program to match and throw away whatever is at your tolerance level: maybe X-Spam-Level: *** or X-Spam-Level: ** or X-Spam-Level: * (if your tolerance is really high). Anything above that level will also match and be thrown away. Henrik
Re: Adding [ietf] considered harmful
> doesn't make anyones life harder it hinders readability, esp. on small screens it hinders sorting of mail by subject it gets messed up with conversations involving multiple lists it's a pain to write filters to take the stuff out... bandwidth is not the issue. > Please consider this as someone who thinks it is a good idea because > some people want it not everything that some people want is a good idea. > regardless if they can jump through 10 more > hoops and get the same functionality with filters (on what ? return-path. it's required to be there, you know... > - I hate > it when people bcc: mailing lists and you loose the from/cc field > containing the mailing list you are filtering on) that's because you're using the wrong fields. nothing in the mail standards has ever required every recipient to appear in a to or cc field.
RE: Tag, You're It!
I would offer that worrying about signed signatures when we don't have signed mail is much more of a waste than 7 characters prepended to an unsigned Subject line. > -Original Message- > From: John Stracke [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 17, 2003 9:56 AM > To: [EMAIL PROTECTED] > Subject: Re: Tag, You're It! > > > Dave Aronson wrote: > > >Long story short, here's my proposal: > > > >- Tag the stuff [ietf]. > > > > > Modifying the Subject: line is a Bad Thing; it invalidates digital > signatures. We're never going to get widespread use of > signed email as > long as we have pieces of mail infrastructure munging > messages to make > signatures useless. > > -- > /\ > |John Stracke |[EMAIL PROTECTED] | > |Principal Engineer|http://www.centive.com | > |Centive |My opinions are my own. | > || > |Never underestimate the power of human stupidity. --I forget who| > \/ > > > > >
Re: Adding [ietf] considered harmful
> Because we, people on the road, use various mail systems and even web > based mail so do the rest of us. ever tried to read mail from a palm pilot? those [foo] turds get *really* annoying... > Why such a war for just 6 characters, while all mailing lists do it? because I've tried it, and found it to be a royal pain in the wazoo. > Have you been out there? yup. > Let's give it a try and see... feel free to set up your own list mirror that prepends [ietf].
Re: Adding [ietf] considered harmful
Hmmm, I am wondering if running this e-mail thread is adding a couple years worth of 6byte additions to the subject. Seems silly to me - I prefer lists to do this - makes many peoples life easier - doesn't make anyones life harder (and frankly if 6 bytes is going to blow your bandwidth budget - you have worse troubles than this proposal) Please consider this as someone who thinks it is a good idea because some people want it - regardless if they can jump through 10 more hoops and get the same functionality with filters (on what ? - I hate it when people bcc: mailing lists and you loose the from/cc field containing the mailing list you are filtering on) - procmail (oppps what about the people that don't use that, etc. Bill On Thu, Dec 18, 2003 at 10:39:21AM +1200, Franck Martin wrote: > Because we, people on the road, use various mail systems and even web > based mail, where the filters are not applied yet... > > Why such a war for just 6 characters, while all mailing lists do it? > > Have you been out there? > > Let's give it a try and see... > > Cheers > > On Thu, 2003-12-18 at 04:26, Keith Moore wrote: > > > > > > > would it be asking too much to add [ietf] to the subject line of each message? > > > > yes. it's completely redundant information, and it interferes with readability, > > particularly on small displays. > > > > why don't you get a better mail reader that lets you classify mail as it arrives? > > that is a much better way to distinguish one list's traffic from another. > > > Franck Martin > [EMAIL PROTECTED] > SOPAC, Fiji > GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 > "Toute connaissance est une reponse a une question" G.Bachelard
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
On Wed, 17 Dec 2003, Theodore Ts'o wrote: > On Wed, Dec 17, 2003 at 10:14:43PM -0500, shogunx wrote: > > On Thu, 18 Dec 2003, Mark Smith wrote: > > > > > I find this more frustrating. I have a dynamic IP address, because > > > fixed IP address ADSL isn't very common here in Australia. So I use > > > DYNDNS to map my domain MX records. I can't get matching PTR > > > records. > > > > > > I'm assuming my mail bounced because I don't have matching PTR and > > > MX records. > > > > > > Why should email assume fixed IP addresses for email delivery, or > > > rather, matching PTR and MX records ? They shouldn't assume this. PTR records are optional. Some places in the world don't have them at all. Some ISPs don't have them because they choose not to bother. Some that choose to bother, don't have them "right" per the demands of the reverse DNS checkers. The claim that "if forward and reverse DNS match, then you can trust the IP" is false. No such trust relationship can be deduced from the relevant RFCs, and the use of reverse DNS is optional. The few people that promote such configurations are well aware that they are violating RFCs, and they are aware that they are creating security vulnerabilities by causing people to place inappropriate faith and trust in DNS responses. The "Reverse DNS check" also fails if there is not a one-host/one-IP mapping. There is no support for this condition in the DNS RFCs so it too is a false assumption. This condition is often violated by multihomed hosts. The usual reason given for this check is to block spam. But they should also know that spammers neither choose their IP addresses, nor whether those IP addresses have reverse DNS. Reverse checking as a spam indicator is just checking the value of random variable that has no relationship to spam. It is an irony that the residential ISPs most plagued by spammers generally have reverse DNS configured such that this test passes. If you were to use DNS as a spam indicator, it would be more sensible to choose the presence of Reverse as an indicator of spam, than an indicator of non-spam. But it would still be testing the particular value of a random variable. --Dean
Re: Adding [ietf] considered harmful
Because we, people on the road, use various mail systems and even web based mail, where the filters are not applied yet... Why such a war for just 6 characters, while all mailing lists do it? Have you been out there? Let's give it a try and see... Cheers On Thu, 2003-12-18 at 04:26, Keith Moore wrote: > > would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another. Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard signature.asc Description: This is a digitally signed message part
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
On Wed, 17 Dec 2003, Theodore Ts'o wrote: > On Wed, Dec 17, 2003 at 10:14:43PM -0500, shogunx wrote: > > On Thu, 18 Dec 2003, Mark Smith wrote: > > > > > I find this more frustrating. I have a dynamic IP address, because fixed IP > > > address ADSL isn't very common here in Australia. So I use DYNDNS to map my > > > domain MX records. I can't get matching PTR records. > > > > > > I'm assuming my mail bounced because I don't have matching PTR and MX records. > > > > > > Why should email assume fixed IP addresses for email delivery, or rather, > > > matching PTR and MX records ? > > > > You could have the first authoritative nameserver listed with your > > registrar as the dyndns address, then do your dns locally for your domain. > > Two scripts on http://sleekfreak.ath.cx:81/technology.html allow this, > > regenerating the zone file every time the address changes. The two > > scripts run under client/server model presently. They would have to be > > merged or called sucessively to make it work on one host. > > The problem is how do you update the PTR record? It's owned by the > ISP, not by you. You the problems with forward or reverse dns? > My solution to the problem is to rent a 1U space at > a colo facility (via a co-op arrangement with a dozen or so > like-minded folks in Boston) which runs my DNS and my mail server, and > since it is at a fixed IP address, it avoids this kind of brain > damage. It costs me $50/month for the 1U rackspace plus fixed IP > address at colo facility, but if you have dynamic IP address via DSL, > you really are a second class citizen on the Internet, and there isn't > much that can be done about it. > Actually my family has a large Tier 1 NOC one hop from the backbone in two directions in Atlanta. Its free for me. I chose to solve the problem locally because your latter statement has some truth to it. Mail to many ISP's is filtered from "home" IP addresses, forcing the use of offshore mailservers to reach these these ISP's users. Rediculous. Hence, I voice my disapproval in the form of code. Scott > - Ted > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: Adding [ietf] considered harmful
i tend to agree with keith. this thread should have started life with the subject line "I can't figure out how to use filters on my client-side or web-side email system" and died right there. (Both hotmail and yahoo can at least filter on "To: or Cc:" which'll catch emails sent to [EMAIL PROTECTED] - the same rule's worked for my old netscape 4.x client for years.) gja Keith Moore wrote: > > > > > would it be asking too much to add [ietf] to the subject line of each message? > > yes. it's completely redundant information, and it interferes with readability, > particularly on small displays. > > why don't you get a better mail reader that lets you classify mail as it arrives? > that is a much better way to distinguish one list's traffic from another.
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
On Wed, Dec 17, 2003 at 10:14:43PM -0500, shogunx wrote: > On Thu, 18 Dec 2003, Mark Smith wrote: > > > I find this more frustrating. I have a dynamic IP address, because fixed IP > > address ADSL isn't very common here in Australia. So I use DYNDNS to map my domain > > MX records. I can't get matching PTR records. > > > > I'm assuming my mail bounced because I don't have matching PTR and MX records. > > > > Why should email assume fixed IP addresses for email delivery, or rather, matching > > PTR and MX records ? > > You could have the first authoritative nameserver listed with your > registrar as the dyndns address, then do your dns locally for your domain. > Two scripts on http://sleekfreak.ath.cx:81/technology.html allow this, > regenerating the zone file every time the address changes. The two > scripts run under client/server model presently. They would have to be > merged or called sucessively to make it work on one host. The problem is how do you update the PTR record? It's owned by the ISP, not by you. My solution to the problem is to rent a 1U space at a colo facility (via a co-op arrangement with a dozen or so like-minded folks in Boston) which runs my DNS and my mail server, and since it is at a fixed IP address, it avoids this kind of brain damage. It costs me $50/month for the 1U rackspace plus fixed IP address at colo facility, but if you have dynamic IP address via DSL, you really are a second class citizen on the Internet, and there isn't much that can be done about it. - Ted
Re: Adding SpamAssassin Headers to IETF mail
On Tue, 16 Dec 2003, Sandy Wills wrote: > [EMAIL PROTECTED] wrote: > > ...this implementation is to allow the IETF community to get used > > to having these headers in the messages, and allow us to make any > > changes to the filtering rules. The above seems like a thinly veiled attempt to make SpamAssassin headers a defacto standard supported by the IETF, without going through the standards process. There is no reason the IETF should condone bypassing the standards process to favor one competing implementation. Obviously, if the goal is to standardize these headers, then a standard can be produced and put through the standards process. Certainly, experimenters can test SpamAssassin headers without putting them in all the IETF production mail systems. This is yet another reason why adding SpamAssassin to IETF email headers is inappropriate. Dean Anderson CEO Av8 Internet, Inc
Re: Adding SpamAssassin Headers to IETF mail
This is ridiculous. The IETF is not getting a lot of spam, so adding SpamAssassin headers is a solution in need of a problem. I think this kind of filtering violates the IETF charter on public participation. SpamAssassin in particular uses many dubious and revenge-oriented blacklists to make it determination, and labels much non-spam mail as spam. Using SpamAssassin this way just enables these revenge blacklists to suppress IETF mail, which is inappropriate and a violation of IETF rules on public participation. Furthermore, such revenge blacklisting is a group boycott in violation of anti-trust law (see Exactis V. MAPS for a good example). Many businesses participate in the IETF, and would be harmed by a group boycott. It would be unlawful for the IETF to participate in an illegal group boycott which harms legitimate business. If individuals want to scan their IETF mail with SpamAssassin, then they are free to choose to do that themselves. Dean Anderson CEO Av8 Internet, Inc
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
On Thu, 18 Dec 2003, Mark Smith wrote: > I find this more frustrating. I have a dynamic IP address, because fixed IP address > ADSL isn't very common here in Australia. So I use DYNDNS to map my domain MX > records. I can't get matching PTR records. > > I'm assuming my mail bounced because I don't have matching PTR and MX records. > > Why should email assume fixed IP addresses for email delivery, or rather, matching > PTR and MX records ? You could have the first authoritative nameserver listed with your registrar as the dyndns address, then do your dns locally for your domain. Two scripts on http://sleekfreak.ath.cx:81/technology.html allow this, regenerating the zone file every time the address changes. The two scripts run under client/server model presently. They would have to be merged or called sucessively to make it work on one host. Scott > > Begin forwarded message: > > Date: Thu, 18 Dec 2003 01:11:28 +1030 (CST) > From: [EMAIL PROTECTED] (Mail Delivery System) > To: [EMAIL PROTECTED] > Subject: Undelivered Mail Returned to Sender > > > This is the Postfix program at host nosense.org. > > I'm sorry to have to inform you that the message returned > below could not be delivered to one or more destinations. > > For further assistance, please send mail to > > If you do so, please include this problem report. You can > delete your own text from the message returned below. > > The Postfix program > > <[EMAIL PROTECTED]>: host mail.netaxs.com[207.8.186.26] said: 550 5.7.1 > <[EMAIL PROTECTED]>... 203.102.233.19 is unwelcome here > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: Tag, You're It!
David Morris wrote: Even so, any point of sending signed mail to a public list should be to allow the list to process the signed mail. That is not the only point by a long shot. A much more important goal would be to help the recipients trust that the message was sent by the person it claims to be from. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |"Call me a Nervous Nellie, but I am concerned about the sale of| |nuclear arms in my general neighborhood." -- Dave Barry| \===/
Re: Tag, You're It!
On Wed, 17 Dec 2003 11:47:20 PST, David Morris said: > Even so, any point of sending signed mail to a public list should be to > allow the list to process the signed mail. If signed mail ever becomes part of the ietf list process, let the server process the signature and > mark the mail appropriately with the result of that processing and then > sign the mail itself before distribution. Now think carefully about the presentation - if I signed the Subject: line, and then the list processor munged and re-signed it, how do you display that to the end user in a sane manner? pgp0.pgp Description: PGP signature
Re: Adding SpamAssassin Headers to IETF mail
On Wed, 17 Dec 2003 11:04:21 PST, David Morris said:
>
> The point of [ietf] has little to do with programatic filters and much to
> do with human visual filtering. Seeing the list tag in the list of
> subjects provided in the index list provided by my mail client makes
> human prioritization much easier. Headers are for programs, subject
> content is for humans. There is a need though you may not feel the need.
Procmail is your friend
:0
*^Return-path:[EMAIL PROTECTED]
{
:0
* ^Subject:\/.+
OLDSUB="$MATCH"
:0 hwf
| formail -I "Subject: [ietf] $OLDSUB"
}
It can probably be done more simply - I'm just winging it here.
(Yes, I know procmail isn't available on a certain popular system. I don't
have much sympathy for the position that the IETF list should do substandard
things in order to support people who insist on using substandard tools.)
Proper chasing of Message-Id: and References: will even allow visualisation of
threading for off-list replies with changed Subject: lines, which is obviously
not anything the IETF mail server can help with.
pgp0.pgp
Description: PGP signature
Re: Tag, You're It!
On Wed, 17 Dec 2003, James M Galvin wrote: > > On Wed, 17 Dec 2003, Paul Hoffman / IMC wrote: > > At 12:47 PM -0500 12/17/03, John Stracke wrote: > > >Paul Hoffman / IMC wrote: > > > >>At 9:55 AM -0500 12/17/03, John Stracke wrote: > >> > >>>Modifying the Subject: line is a Bad Thing; it invalidates digital > >>>signatures. > >> > >>Which digital signatures are you talking about? Neither S/MIME nor > >>OpenPGP sign the headers in messages, only the bodies. > > > >S/MIME can sign the Subject: header (see RFC-1848, section 6.3) > > RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant > implementation. > > Two things. First, MOSS had *a* significant implementation that was > complete and freely available. I know because it was my group that > wrote it in a previous life. It just never had any significant usage or > deployement, but that's a different issue. > > Second, John is correct in theory although not in practice. Section 6.3 > of RFC1848 describes how security multiparts (RFC1847) can be used by > MOSS in particular but in practice by any secure email protocol to > protect selected headers of a message. This is done by signing a > message/rfc822 body part, not just the text/plain (or whatever) content > body part. > > S/MIME and OpenPGP can both use security multiparts. Even so, any point of sending signed mail to a public list should be to allow the list to process the signed mail. If signed mail ever becomes part of the ietf list process, let the server process the signature and mark the mail appropriately with the result of that processing and then sign the mail itself before distribution.
Re: Adding SpamAssassin Headers to IETF mail
The point of [ietf] has little to do with programatic filters and much to do with human visual filtering. Seeing the list tag in the list of subjects provided in the index list provided by my mail client makes human prioritization much easier. Headers are for programs, subject content is for humans. There is a need though you may not feel the need. Dave On Wed, 17 Dec 2003, Tim Chown wrote: > On Wed, Dec 17, 2003 at 08:00:38AM +0200, Pekka Savola wrote: > > > > I don't- IMHO it's stupid to waste the precious bits in the subject > > line to say "[ietf] " because there is no need for such. The messages > > can be filtered better using other thods as well, and humans can look > > at the headers.. > > I agree, for filtering everything's in the header already. >
Re: Tag, You're It!
On Wed, 17 Dec 2003, Paul Hoffman / IMC wrote: At 12:47 PM -0500 12/17/03, John Stracke wrote: >Paul Hoffman / IMC wrote: > >>At 9:55 AM -0500 12/17/03, John Stracke wrote: >> >>>Modifying the Subject: line is a Bad Thing; it invalidates digital >>>signatures. >> >>Which digital signatures are you talking about? Neither S/MIME nor >>OpenPGP sign the headers in messages, only the bodies. > >S/MIME can sign the Subject: header (see RFC-1848, section 6.3) RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant implementation. Two things. First, MOSS had *a* significant implementation that was complete and freely available. I know because it was my group that wrote it in a previous life. It just never had any significant usage or deployement, but that's a different issue. Second, John is correct in theory although not in practice. Section 6.3 of RFC1848 describes how security multiparts (RFC1847) can be used by MOSS in particular but in practice by any secure email protocol to protect selected headers of a message. This is done by signing a message/rfc822 body part, not just the text/plain (or whatever) content body part. S/MIME and OpenPGP can both use security multiparts. Jim
Re: Tag, You're It!
Paul Hoffman / IMC wrote: At 12:47 PM -0500 12/17/03, John Stracke wrote: S/MIME can sign the Subject: header (see RFC-1848, section 6.3) RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant implementation. Oh. Sorry. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Fate just isn't what it used to be." --Hobbes| \==/
Re: Tag, You're It!
At 12:47 PM -0500 12/17/03, John Stracke wrote: Paul Hoffman / IMC wrote: At 9:55 AM -0500 12/17/03, John Stracke wrote: Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. Which digital signatures are you talking about? Neither S/MIME nor OpenPGP sign the headers in messages, only the bodies. S/MIME can sign the Subject: header (see RFC-1848, section 6.3) RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant implementation. --Paul Hoffman, Director --Internet Mail Consortium
Re: Tag, You're It!
Paul Hoffman / IMC wrote: At 9:55 AM -0500 12/17/03, John Stracke wrote: Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. Which digital signatures are you talking about? Neither S/MIME nor OpenPGP sign the headers in messages, only the bodies. S/MIME can sign the Subject: header (see RFC-1848, section 6.3), and probably should, since some people write messages where the subject is part of the meaning--change the subject and you change the meaning of the message. (As an extreme case: at this company, people sometimes send messages with no body at all. It's so common that they have a convention for it: they put "(eom)" in the subject line, for "end of message".) -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |"Collect call from reality, will you accept the--" *click*| \==/
Re: Tag, You're It!
At 9:55 AM -0500 12/17/03, John Stracke wrote: Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. Which digital signatures are you talking about? Neither S/MIME nor OpenPGP sign the headers in messages, only the bodies. --Paul Hoffman, Director --Internet Mail Consortium
Re: More frustrating that not having [ietf] (Fw: Undelivered MailReturned to Sender)
Not an option; I can't even get POP3 access to the email server Clint (JOATMON) Chaplin >>> Ari Ollikainen <[EMAIL PROTECTED]> 12/17/03 08:36:15 >>> At 10:16 AM -0500 12/17/03, Gordon Cook wrote: >I share your frustration. Yes this is another casualty of the spam wars. This is my isp...not me. Bankrupt in june these folk added every ip block that they could find on every spam black hole list to their null routing tables and in short order place in japan, nepal, new zealand and mexico could no longer reach me. I have an alternate email that dot forwards on my home pages and by january 1 i hope to have moved completely...web and email service, to a different ISP. While you're at it, get a mail client that can filter incoming email and learn how to set up the filters...so that this silly thread can die. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ You can't depend on your judgement when your imagination is out of focus. -- Mark Twain. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ This email has been scanned for computer viruses.
Re: Adding [ietf] considered harmful
Not an option. I don't even have POP3 access to the email server. Clint (JOATMON) Chaplin >>> Keith Moore <[EMAIL PROTECTED]> 12/17/03 08:26:40 >>> > > would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another. This email has been scanned for computer viruses.
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
At 10:16 AM -0500 12/17/03, Gordon Cook wrote: >I share your frustration. Yes this is another casualty of the spam wars. This is >my isp...not me. Bankrupt in june these folk added every ip block that they could >find on every spam black hole list to their null routing tables and in short order >place in japan, nepal, new zealand and mexico could no longer reach me. I have an >alternate email that dot forwards on my home pages and by january 1 i hope to have >moved completely...web and email service, to a different ISP. While you're at it, get a mail client that can filter incoming email and learn how to set up the filters...so that this silly thread can die. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ You can't depend on your judgement when your imagination is out of focus. -- Mark Twain. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Re: Adding SpamAssassin Headers to IETF mail
> [EMAIL PROTECTED] wrote: > > ...we are planning to turn on SpamAssassin on all IETF mail... I have serious concerns about the use of spamassassin to filter IETF mail, but it depends hugely on the details. If the secretariat is just tagging mail, I don't have a big problem with that. If the secretariat is proposing to use spamassassin as a way to implement a few very carefully chosen filters, that's fine, provided those filters are actually reliable indicators that a message is not appropriate for the IETF list. For instance if IESG were to set a policy that all messages are plain English text (I'm speaking hypothetically here), then a filter that excluded other content-types and other languages would be defensible. If IESG were to set a policy that says messages should have valid return addresses, then a filter that checked return addresses for validity would be defensible. In all cases the filters should be well-documented and subject to public review prior to implementation, not something imposed at the whim of the secretariat and/or IESG. If the secretariat is proposing to use SpamAssassin's default filters, or even very many of the filters included in SpamAssassin, I would have serious objections to that. Many of SpamAssassin's criteria are completely without technical justification, and it is not unusual for SpamAssassin to block legitimate mail (as it did in that example I cited a day or two ago). Even if SpamAssassin only blocks one out of one hundred legitimate messages, it is still unreasonable to impose a significant barrier on that one poster. SpamAssassin is not a good judge of what is correct or reasonable, and we have had too much arbitrary censorship already. It's hard enough to contribute usefully to IETF without imposing the additional burden that contributors second-guess SpamAssassin's filters.
Adding [ietf] considered harmful
> > would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another.
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
> I share your frustration. Yes this is another casualty of the spam > wars. This is my isp...not me. Bankrupt in june these folk added > every ip block that they could find on every spam black hole list to > their null routing tables and in short order place in japan, nepal, > new zealand and mexico could no longer reach me. I have an alternate > email that dot forwards on my home pages and by january 1 i hope to > have moved completely...web and email service, to a different ISP. Maybe there needs to be a "stupid ISP tricks" RFC. I'm perfectly serious.
Re: Adding SpamAssassin Headers to IETF mail
On Tue, 16 Dec 2003 19:34:35 EST, Sandy Wills <[EMAIL PROTECTED]> said: > [1] Could we come up with a 512-bit flag system[2]? Would that be > enough? I don't want dick ads, I do want breast ads, I won't read > anything from California, I really, really want stuff from Dell. http://www.ietf.org/internet-drafts/draft-eastlake-xxx-06.txt pgp0.pgp Description: PGP signature
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
Mark Smith wrote: Why should email assume fixed IP addresses for email delivery, or rather, matching PTR and MX records ? Because spammers target home users with broadband connections, and try to crack their systems to use them as open relays. As a result, some ISPs have taken this step; they figure you can always send mail via your ISP's SMTP server. Yes, it's dain-bramaged. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Never underestimate the power of human stupidity. --I forget who| \/
Re: More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
I share your frustration. Yes this is another casualty of the spam wars. This is my isp...not me. Bankrupt in june these folk added every ip block that they could find on every spam black hole list to their null routing tables and in short order place in japan, nepal, new zealand and mexico could no longer reach me. I have an alternate email that dot forwards on my home pages and by january 1 i hope to have moved completely...web and email service, to a different ISP. I find this more frustrating. I have a dynamic IP address, because fixed IP address ADSL isn't very common here in Australia. So I use DYNDNS to map my domain MX records. I can't get matching PTR records. I'm assuming my mail bounced because I don't have matching PTR and MX records. Why should email assume fixed IP addresses for email delivery, or rather, matching PTR and MX records ? Begin forwarded message: Date: Thu, 18 Dec 2003 01:11:28 +1030 (CST) From: [EMAIL PROTECTED] (Mail Delivery System) To: [EMAIL PROTECTED] Subject: Undelivered Mail Returned to Sender This is the Postfix program at host nosense.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <[EMAIL PROTECTED]>: host mail.netaxs.com[207.8.186.26] said: 550 5.7.1 <[EMAIL PROTECTED]>... 203.102.233.19 is unwelcome here Reporting-MTA: dns; nosense.org Arrival-Date: Thu, 18 Dec 2003 01:10:54 +1030 (CST) Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mail.netaxs.com[207.8.186.26] said: 550 5.7.1 <[EMAIL PROTECTED]>... 203.102.233.19 is unwelcome here Received: from Dupy2.nosense.org (19.cust6.nsw.dsl.ozemail.com.au [203.102.233.19]) by nosense.org (Postfix) with SMTP id 262643F02A; Thu, 18 Dec 2003 01:10:54 +1030 (CST) Date: Thu, 18 Dec 2003 01:10:53 +1030 From: Mark Smith <[EMAIL PROTECTED]> To: Gordon Cook <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Adding SpamAssassin Headers to IETF mail Message-Id: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; x-Spamnix=checked Content-Transfer-Encoding: 7bit I just match on either the "Sender: [EMAIL PROTECTED]" header, or the ML specific email address I've created. I'm using Sylpheed though, it seems to be more flexible on matching header fields than most other email clients I've used in the past. On Wed, 17 Dec 2003 09:13:13 -0500 Gordon Cook <[EMAIL PROTECTED]> wrote: >On Wed, Dec 17, 2003 at 08:00:38AM +0200, Pekka Savola wrote: >> >> I don't- IMHO it's stupid to waste the precious bits in the subject >> line to say "[ietf] " because there is no need for such. The messages >> can be filtered better using other thods as well, and humans can look >> at the headers.. > >I agree, for filtering everything's in the header already. > >Tim I do not use eudora to forward list mail to separate mail boxes. therefore if i don't start list filtering into seperate mail boxes, i am forced to guess where a piece of mail might be ietf since adding 6 characters to ever subject headers is judged unhelpful and > unacceptable? There is no sure way at all to tell from a subject line whether its IETF and to complain about adding 6 ascii characters to a subject line wasting bits if it gives several thousand humans a hint as to whether to open and read, or delete unopened, or delete mail to spam mail box seems to be strange. But this point of view i guess is why the list keepers have not yet and probably never will do what most of the other lists that I receive do. -- = The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info & prices at http://cookreport.com/subscriptions.shtml Googin on real time global corp. http://cookreport.com/12.11.shtml Purchase 10 years of back issues at http://www.cafeshops.com/cookreportinter.6936314 E-mail [EMAIL PROTECTED] or use [EMAIL PROTECTED] Free World Dial up 17318 = -- = The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info & prices at http://cookreport.com/subscriptions.shtml Googin on real time global corp. http://cookreport.com/12.11.shtml Purchase 10 years of back issues at http://www.cafeshops.com/cookreportinter.6936314 E-mail [EMAIL PROTECTED] or use [EMAIL PROTECTED] Free World Dial up 17
More frustrating that not having [ietf] (Fw: Undelivered Mail Returned to Sender)
I find this more frustrating. I have a dynamic IP address, because fixed IP address ADSL isn't very common here in Australia. So I use DYNDNS to map my domain MX records. I can't get matching PTR records. I'm assuming my mail bounced because I don't have matching PTR and MX records. Why should email assume fixed IP addresses for email delivery, or rather, matching PTR and MX records ? Begin forwarded message: Date: Thu, 18 Dec 2003 01:11:28 +1030 (CST) From: [EMAIL PROTECTED] (Mail Delivery System) To: [EMAIL PROTECTED] Subject: Undelivered Mail Returned to Sender This is the Postfix program at host nosense.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <[EMAIL PROTECTED]>: host mail.netaxs.com[207.8.186.26] said: 550 5.7.1 <[EMAIL PROTECTED]>... 203.102.233.19 is unwelcome here Reporting-MTA: dns; nosense.org Arrival-Date: Thu, 18 Dec 2003 01:10:54 +1030 (CST) Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mail.netaxs.com[207.8.186.26] said: 550 5.7.1 <[EMAIL PROTECTED]>... 203.102.233.19 is unwelcome here --- Begin Message --- I just match on either the "Sender: [EMAIL PROTECTED]" header, or the ML specific email address I've created. I'm using Sylpheed though, it seems to be more flexible on matching header fields than most other email clients I've used in the past. On Wed, 17 Dec 2003 09:13:13 -0500 Gordon Cook <[EMAIL PROTECTED]> wrote: > >On Wed, Dec 17, 2003 at 08:00:38AM +0200, Pekka Savola wrote: > >> > >> I don't- IMHO it's stupid to waste the precious bits in the subject > >> line to say "[ietf] " because there is no need for such. The messages > >> can be filtered better using other thods as well, and humans can look > >> at the headers.. > > > >I agree, for filtering everything's in the header already. > > > >Tim > > I do not use eudora to forward list mail to separate mail boxes. > therefore if i don't start list filtering into seperate mail boxes, i > am forced to guess where a piece of mail might be ietf since adding 6 > characters to ever subject headers is judged unhelpful and > unacceptable? > > There is no sure way at all to tell from a subject line whether its > IETF and to complain about adding 6 ascii characters to a subject > line wasting bits if it gives several thousand humans a hint as to > whether to open and read, or delete unopened, or delete mail to spam > mail box seems to be strange. But this point of view i guess is why > the list keepers have not yet and probably never will do what most of > the other lists that I receive do. > > -- > = > The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 703 738-6031 > (Vonage) Subscription info & prices at > http://cookreport.com/subscriptions.shtml > Googin on real time global corp. http://cookreport.com/12.11.shtml Purchase 10 > years of back issues at http://www.cafeshops.com/cookreportinter.6936314 > E-mail [EMAIL PROTECTED] or use [EMAIL PROTECTED] Free World Dial up 17318 > = > --- End Message ---
Re: Tag, You're It!
Dave Aronson wrote: Long story short, here's my proposal: - Tag the stuff [ietf]. Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. We're never going to get widespread use of signed email as long as we have pieces of mail infrastructure munging messages to make signatures useless. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Never underestimate the power of human stupidity. --I forget who| \/
Tag, You're It! (was: Adding SpamAssassin Headers to IETF mail)
On Tue December 16 2003 22:35, Sujit Menon wrote: > Subject line should have only: (IETF Mailing List) Do you mean only as in, that should be the entire subject line, or as in, that should be all that should be in the tag prepended to the subject line? As a tag, it's still much longer than need be, so I'll ass-u-me you mean that that should be the entire subject line. > and by adding an > example of GNU SIP mailing list Sent by: [EMAIL PROTECTED] > in the mail from header. Do you mean the data sent in the "MAIL FROM" part of the first SMTP exchange, which IIRC shows up as the Return-Path: header, or the user-set From: header? Since you didn't use caps, and wrote header, I will ass-u-me you meant the From: header. > This will make it easier to set rules in our mail boxes Uh, no, in fact quite the opposite, if I understand you correctly. Your proposed Subject line would destroy the usefulness of the subject line, aside from telling that it's from this list. You wouldn't be able to scan through the list and pick out the ones that are on specific topics you want to read about (and read them), or that aren't (and delete them), let alone do any automatic filtering on the subject, whether based on interest or spamminess. Your proposed From line would make it much harder for us to filter out people we don't want to hear from (whether done manually or automatically, and whether to authors who are legit, kooks, or spammers), and to send replies directly to the author. Long story short, here's my proposal: - Tag the stuff [ietf]. Six chars, seven with a space. Big fat hairy deal! - Keep the author in the From. - Keep NOT putting the list in a Reply-To, so people have to purposely intend to send to the list in order to add to its traffic. - Don't filter spam. We can do it ourselves, and spam seems to be a negligible proportion of this list's email. The extra headers added by SpamAssasin and so forth would waste far more bandwidth than the spam! - Make the archives munge addresses. I *have* been getting spam at addresses I've used only here, and the public archives are the most likely explanation. (They're much too useful for me to ask to make them private, but if "privatize the archives" is the concensus, then I'd go along with it.) -- Dave Aronson, Senior Software Engineer, Secure Software Inc. (Opinions above NOT those of securesw.com unless so stated!) Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org Web: http://destined.to/program http://listen.to/davearonson
Re: Adding SpamAssassin Headers to IETF mail
I just match on either the "Sender: [EMAIL PROTECTED]" header, or the ML specific email address I've created. I'm using Sylpheed though, it seems to be more flexible on matching header fields than most other email clients I've used in the past. On Wed, 17 Dec 2003 09:13:13 -0500 Gordon Cook <[EMAIL PROTECTED]> wrote: > >On Wed, Dec 17, 2003 at 08:00:38AM +0200, Pekka Savola wrote: > >> > >> I don't- IMHO it's stupid to waste the precious bits in the subject > >> line to say "[ietf] " because there is no need for such. The messages > >> can be filtered better using other thods as well, and humans can look > >> at the headers.. > > > >I agree, for filtering everything's in the header already. > > > >Tim > > I do not use eudora to forward list mail to separate mail boxes. > therefore if i don't start list filtering into seperate mail boxes, i > am forced to guess where a piece of mail might be ietf since adding 6 > characters to ever subject headers is judged unhelpful and > unacceptable? > > There is no sure way at all to tell from a subject line whether its > IETF and to complain about adding 6 ascii characters to a subject > line wasting bits if it gives several thousand humans a hint as to > whether to open and read, or delete unopened, or delete mail to spam > mail box seems to be strange. But this point of view i guess is why > the list keepers have not yet and probably never will do what most of > the other lists that I receive do. > > -- > = > The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 703 738-6031 > (Vonage) Subscription info & prices at > http://cookreport.com/subscriptions.shtml > Googin on real time global corp. http://cookreport.com/12.11.shtml Purchase 10 > years of back issues at http://www.cafeshops.com/cookreportinter.6936314 > E-mail [EMAIL PROTECTED] or use [EMAIL PROTECTED] Free World Dial up 17318 > = >
Tag, You're It! (was: Adding SpamAssassin Headers to IETF mail)
On Tue December 16 2003 21:45, Franck Martin wrote: > It was replied to me a lot of technical reasons on how I could > filter otherwise. But I'm a human and I like to see it is an [ietf] > mail. I see that it is an IETF mail by seeing that it got routed into my IETF folder. (It gets there by my filters checking whether Sender is [EMAIL PROTECTED]) On the other claw, sometimes I have to get my mail over the web, in which case the folder routing rules haven't been applied. For this reason, I'd support a *short* tag, such as "[ietf]". To those who bitch about the waste of bits: clamp down on topic drift, large signatures, unnecessary headers (including spam-detection hints!), etc. etc. etc. first! -- Dave Aronson, Senior Software Engineer, Secure Software Inc. (Opinions above NOT those of securesw.com unless so stated!) Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org Web: http://destined.to/program http://listen.to/davearonson
Re: Adding SpamAssassin Headers to IETF mail
On Wed, Dec 17, 2003 at 08:00:38AM +0200, Pekka Savola wrote: I don't- IMHO it's stupid to waste the precious bits in the subject line to say "[ietf] " because there is no need for such. The messages can be filtered better using other thods as well, and humans can look at the headers.. I agree, for filtering everything's in the header already. Tim I do not use eudora to forward list mail to separate mail boxes. therefore if i don't start list filtering into seperate mail boxes, i am forced to guess where a piece of mail might be ietf since adding 6 characters to ever subject headers is judged unhelpful and unacceptable? There is no sure way at all to tell from a subject line whether its IETF and to complain about adding 6 ascii characters to a subject line wasting bits if it gives several thousand humans a hint as to whether to open and read, or delete unopened, or delete mail to spam mail box seems to be strange. But this point of view i guess is why the list keepers have not yet and probably never will do what most of the other lists that I receive do. -- = The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info & prices at http://cookreport.com/subscriptions.shtml Googin on real time global corp. http://cookreport.com/12.11.shtml Purchase 10 years of back issues at http://www.cafeshops.com/cookreportinter.6936314 E-mail [EMAIL PROTECTED] or use [EMAIL PROTECTED] Free World Dial up 17318 =
Re: Adding SpamAssassin Headers to IETF mail
On Wed, Dec 17, 2003 at 08:00:38AM +0200, Pekka Savola wrote: > > I don't- IMHO it's stupid to waste the precious bits in the subject > line to say "[ietf] " because there is no need for such. The messages > can be filtered better using other thods as well, and humans can look > at the headers.. I agree, for filtering everything's in the header already. Tim
al/nlMatrixTopNControlTable <-> hlMatrixControlTable dependence?
Hi, I wanted to know whether one can delete a control row from hlMatrixControlTable when a control row in al/nlMatrixTopNControlTable is pointing to the hlMatrixControlTable control row being deleted through the al/nlMatrixTopNControlMatrixIndex variable. eg. A control row exists in hlMatrixControlTable with Index value 112. A control row exists in alMatrixTopNControlTable with alMatrixTopNControlMatrixIndex value equal to 112. Can the control row in hlMatrixControlTable with index value 112 be deleted. I did not find any such dependency in RMON-II RFC i.e. 2021. However, conceptually al/nlMatrixTopNTable (i.e. data table) won't be populated once the corresponding control row from hlMatrixControlTable is deleted, eventhough a control row exists in al/nlMatrixTopNControlTable. Please clarify. Thanks, Chintan __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: Adding SpamAssassin Headers to IETF mail
On 17-dec-03, at 1:34, Sandy Wills wrote: I would like to propose a solution to the looming religious war: Some people are serious about wanting to see every message that crosses the ietf domain, and will offer violence to anyone who wants to keep their daily dose of spam away from them. Others (well, me. I follow ietf and ietf-announce for my own entertainment and education. I don't mind if you filter on "bigger dick".) will be willing to accept the server-based filter, in order to spare their inbox. Would it be possible to somehow flag messages as "valid" or "bogus" (or maybe "Holy Writ" or "Message from Satan"), and then allow subscribers to set their systems to automatically filter on these labels, if they care? Of course, if I wanted the mail server to work harder, I would suggest that the system keep track of each subscriber's preference and either send or pass, thus saving the bandwidth. I would very much like it if this could be implemented. I get enough spam as it is; I don't care to receive even more through the IETF lists. The problem with just tagging the spam is that it still wastes bandwidth, and to add insult to injury, the extra anti-spam headers waste even more bandwdith. Fortunately, it isn't as bad as I expected, for instance your message contains: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=PENIS_ENLARGE autolearn=no version=2.60 And before anyone asks: yes, I care because I regularly connect over GPRS and my (spam) filtering happens client-side. I don't believe keeping track of the recipient's spam reception preference is a lot of work for the mailing list server: simply set up two lists, one that checks for spam, adds the headers and forwards, and one that checks for spam, doesn't add headers and forwards on non-spaminess. Altenatively, wouldn't it be possible to create a system where list members sign their message, and when the signature is recognized, the message is automatically flagged as "not spam"?
