Re: non-solution
seems like the problem is poor signal to noise ratio. i'm not sure that will be solved by quick and easy web interface to noise creation. do we have an easy route to communicate with the spammers? like posting on this list? if they are spamming, then they are also watching and giggling. if so, perhaps we could ask them a few things; "what do you want?", "do you have a question?", and "does your mother know what you are doing?" come to mind. scott On Sat, 26 Jun 2004, Ed Gerck wrote: > to save trees, please read my past messages here, the answers are there. > Thanks. > > shogunx wrote: > > > On Sat, 26 Jun 2004, Ed Gerck wrote: > > > > > >> > >>shogunx wrote: > >> > >> > >>>On Wed, 23 Jun 2004, Iljitsch van Beijnum wrote: > >>> > >>> > >>> > On 23-jun-04, at 3:54, Ed Gerck wrote: > > > > >Of course, I still believe that insisting in only using the email > >for communications and screaming "bloody murder" when it does not > >work for some reason, at some time, is very un-Internet. If you want > >only a single path, you have to live with the resulting single point of > >failure. Allowing web-based messages in addition to email is a simple > >and cost-effective way to provide redundancy and reduce the importance > >of problems such as reported by Anderson. > > The IETF has used email as its primary method of conducting its > business for almost 20 years. The IETF is also in charge of all the > relevant standards. So if email doesn't work, I think the IETF should > fix it rather than come up with ad-hoc additional communication > mechanisms that have more than enough problems of their own. > >>> > >>> > >>>I am in agreement that the mailing list mechanism should not be > >>>tampered with... it works, so don't break it. > >> > >>What I suggested could easily and seamlessly merge with the mailing > >>list, as an email that was received by a web interface. > >> > > > > > > What are you suggesting, a web-based archive of list traffic and a form on > > a website to post to ietf lists? > > > > > > > >>BTW, I'm glad you are in the first phase of problem solving -- denial. > >>I'm suggesting we move to the second phase -- investigate options to > >>solve the problem. > >> > > > > > > Please define the problem that you are attempting to solve. > > > > > > > >> > > > > sleekfreak pirate broadcast > > http://sleekfreak.ath.cx:81/ > > > > > > > > > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf > sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
to save trees, please read my past messages here, the answers are there. Thanks. shogunx wrote: On Sat, 26 Jun 2004, Ed Gerck wrote: shogunx wrote: On Wed, 23 Jun 2004, Iljitsch van Beijnum wrote: On 23-jun-04, at 3:54, Ed Gerck wrote: Of course, I still believe that insisting in only using the email for communications and screaming "bloody murder" when it does not work for some reason, at some time, is very un-Internet. If you want only a single path, you have to live with the resulting single point of failure. Allowing web-based messages in addition to email is a simple and cost-effective way to provide redundancy and reduce the importance of problems such as reported by Anderson. The IETF has used email as its primary method of conducting its business for almost 20 years. The IETF is also in charge of all the relevant standards. So if email doesn't work, I think the IETF should fix it rather than come up with ad-hoc additional communication mechanisms that have more than enough problems of their own. I am in agreement that the mailing list mechanism should not be tampered with... it works, so don't break it. What I suggested could easily and seamlessly merge with the mailing list, as an email that was received by a web interface. What are you suggesting, a web-based archive of list traffic and a form on a website to post to ietf lists? BTW, I'm glad you are in the first phase of problem solving -- denial. I'm suggesting we move to the second phase -- investigate options to solve the problem. Please define the problem that you are attempting to solve. sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
On Sat, 26 Jun 2004, Ed Gerck wrote: > > > shogunx wrote: > > > On Wed, 23 Jun 2004, Iljitsch van Beijnum wrote: > > > > > >>On 23-jun-04, at 3:54, Ed Gerck wrote: > >> > >> > >>>Of course, I still believe that insisting in only using the email > >>>for communications and screaming "bloody murder" when it does not > >>>work for some reason, at some time, is very un-Internet. If you want > >>>only a single path, you have to live with the resulting single point of > >>>failure. Allowing web-based messages in addition to email is a simple > >>>and cost-effective way to provide redundancy and reduce the importance > >>>of problems such as reported by Anderson. > >> > >>The IETF has used email as its primary method of conducting its > >>business for almost 20 years. The IETF is also in charge of all the > >>relevant standards. So if email doesn't work, I think the IETF should > >>fix it rather than come up with ad-hoc additional communication > >>mechanisms that have more than enough problems of their own. > > > > > > I am in agreement that the mailing list mechanism should not be > > tampered with... it works, so don't break it. > > What I suggested could easily and seamlessly merge with the mailing > list, as an email that was received by a web interface. > What are you suggesting, a web-based archive of list traffic and a form on a website to post to ietf lists? > BTW, I'm glad you are in the first phase of problem solving -- denial. > I'm suggesting we move to the second phase -- investigate options to > solve the problem. > Please define the problem that you are attempting to solve. > > sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
shogunx wrote: On Wed, 23 Jun 2004, Iljitsch van Beijnum wrote: On 23-jun-04, at 3:54, Ed Gerck wrote: Of course, I still believe that insisting in only using the email for communications and screaming "bloody murder" when it does not work for some reason, at some time, is very un-Internet. If you want only a single path, you have to live with the resulting single point of failure. Allowing web-based messages in addition to email is a simple and cost-effective way to provide redundancy and reduce the importance of problems such as reported by Anderson. The IETF has used email as its primary method of conducting its business for almost 20 years. The IETF is also in charge of all the relevant standards. So if email doesn't work, I think the IETF should fix it rather than come up with ad-hoc additional communication mechanisms that have more than enough problems of their own. I am in agreement that the mailing list mechanism should not be tampered with... it works, so don't break it. What I suggested could easily and seamlessly merge with the mailing list, as an email that was received by a web interface. BTW, I'm glad you are in the first phase of problem solving -- denial. I'm suggesting we move to the second phase -- investigate options to solve the problem. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
On Wed, 23 Jun 2004, Iljitsch van Beijnum wrote: > On 23-jun-04, at 3:54, Ed Gerck wrote: > > > Of course, I still believe that insisting in only using the email > > for communications and screaming "bloody murder" when it does not > > work for some reason, at some time, is very un-Internet. If you want > > only a single path, you have to live with the resulting single point of > > failure. Allowing web-based messages in addition to email is a simple > > and cost-effective way to provide redundancy and reduce the importance > > of problems such as reported by Anderson. > > The IETF has used email as its primary method of conducting its > business for almost 20 years. The IETF is also in charge of all the > relevant standards. So if email doesn't work, I think the IETF should > fix it rather than come up with ad-hoc additional communication > mechanisms that have more than enough problems of their own. I am in agreement that the mailing list mechanism should not be tampered with... it works, so don't break it. The addition of realtime facilities like irc could potentially augment the process, as long as the dialogs were archived for public consumption. > > Creating such a new channel only gives people with unreasonable email > habits (such as rejecting replies to list messages without saying why) > positive feedback so email becomes even less reliable. > > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf > sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
On 23-jun-04, at 3:54, Ed Gerck wrote: Of course, I still believe that insisting in only using the email for communications and screaming "bloody murder" when it does not work for some reason, at some time, is very un-Internet. If you want only a single path, you have to live with the resulting single point of failure. Allowing web-based messages in addition to email is a simple and cost-effective way to provide redundancy and reduce the importance of problems such as reported by Anderson. The IETF has used email as its primary method of conducting its business for almost 20 years. The IETF is also in charge of all the relevant standards. So if email doesn't work, I think the IETF should fix it rather than come up with ad-hoc additional communication mechanisms that have more than enough problems of their own. Creating such a new channel only gives people with unreasonable email habits (such as rejecting replies to list messages without saying why) positive feedback so email becomes even less reliable. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
> From: Bill Sommerfeld > Substantially similar capabilities are present in all of the SMTP > MTA's I'm familiar with. If a message delivery attempt is rejected > early, only envelope information is logged, but if the message was > rejected in error, that's generally sufficient to identify what needs > to be whitelisted. Yes, but after you've had them, you find that facilities that log the fewest few dozen KBytes of SMTP bodies are very valuable. SMTP envelope logs are unitelligible to most users, not only because they are terse but because the SMTP envelope is a mystery to the fewer users that know about it. Delaying filter rejections until the SMTP DATA command and so capturing the message body resolves a lot of complaints of the form "Why did your idiotic spam filter reject that perfectly good mail message?" That can significantly reduce whitelisting requirements. Logging bodies involve some obvious privacy hassles. You must keep the logs private. The logs can have only censored copies of the envelope so that recipients can't know who else was sent the same message. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
the best point, Re: non-solution
Bill Sommerfeld wrote: > Ed Gerck wrote: What I suggested is a web interface to the IETF mailboxes, such that any routing problems TO those mailboxes would cease to be an issue, allowing the IETF to be in FULL CONTROL of what is forwared to a mailbox, or not. How is this compatible with the IETF being run largely by donated labor? That's the best point of my suggestion! The IETF (and this list!) would no longer waste time with complaints about lack of access to mailboxes, while IETF-wide challenge-response (as it is done today already) and filters would be in place to prevent further wasting of donated labor. Because routing problems TO those mailboxes would cease to be an issue, the servers would either accept and forward the message or send back a message with further instructions to the sender. Of course, people could still send email as today. But there would be an alternative using the Internet, preventing the current single point of failure. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
Bill Sommerfeld wrote: If the filter is after the server providing the form page and the SUBMIT button, yes, the server received the message. IETF can have a log file before the filter (SOP), allowing review of what is filtered. Substantially similar capabilities are present in all of the SMTP MTA's I'm familiar with. The problem, as has been (too) extensively discussed here, is that blacklists and other routing restrictions prevent the email from ever reaching the desired user's MTA (not to mention the user's MUA). What I suggested is a web interface to the IETF mailboxes, such that any routing problems TO those mailboxes would cease to be an issue, allowing the IETF to be in FULL CONTROL of what is forwared to a mailbox, or not. Of course, I still believe that insisting in only using the email for communications and screaming "bloody murder" when it does not work for some reason, at some time, is very un-Internet. If you want only a single path, you have to live with the resulting single point of failure. Allowing web-based messages in addition to email is a simple and cost-effective way to provide redundancy and reduce the importance of problems such as reported by Anderson. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
> If the filter is after the > server providing the form page and the SUBMIT button, yes, the > server received the message. IETF can have a log file before the > filter (SOP), allowing review of what is filtered. Substantially similar capabilities are present in all of the SMTP MTA's I'm familiar with. If a message delivery attempt is rejected early, only envelope information is logged, but if the message was rejected in error, that's generally sufficient to identify what needs to be whitelisted. - Bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
Bill Sommerfeld wrote: The server can filter as the IETF wishes (or dare) but there would be no problems with black-lists and mail routing affecting the message being RECEIVED by the IETF -- which is the point in question. If a message is blocked by a filter without making a sound, is it actually received? Cute ...this is not a quantum problem. If the filter is after the server providing the form page and the SUBMIT button, yes, the server received the message. IETF can have a log file before the filter (SOP), allowing review of what is filtered. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
> The server can filter as the IETF wishes (or dare) but there would be no > problems with black-lists and mail routing affecting the message being > RECEIVED by the IETF -- which is the point in question. If a message is blocked by a filter without making a sound, is it actually received? - Bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
Bill Sommerfeld wrote: The solution to this self-limitation problem [1], if the Internet MUST be the only communication path used by someone, is to use IETF web forms that go directly to the server. It's not a solution. For one, spammers, not content to ruin email, have been abusing web forms for quite some time; spam filters will be required there, as well. The server can filter as the IETF wishes (or dare) but there would be no problems with black-lists and mail routing affecting the message being RECEIVED by the IETF -- which is the point in question. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
> The solution to this self-limitation problem [1], if the Internet MUST be > the only communication path used by someone, is to use IETF web forms > that go directly to the server. It's not a solution. For one, spammers, not content to ruin email, have been abusing web forms for quite some time; spam filters will be required there, as well. - Bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
