Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 16:45, SM wrote: At 20:11 25-02-10, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. While we are on this topic, which of the following methods would you recommend for a point of contact: 1. mailto [1] [2] [7] [8] [10] [12] [13] 2. email address without mailto [9] 3. AT [3] 4. at [4] [11] 5. [5] 6. email address as an image [6] The only one I object to strongly is 6, and that's because I can't see it and nor can anybody using a textmode browser. Other than that, it makes sense to avoid spam by not doing 1 or 2, although I would sooner not hide from spammers by breaking functionality, which 2-5 implies. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
On 2010-02-27 04:46 William Allen Simpson said the following: ... You are incorrect. Get off your high horse. You should have notified the secretariat of the version change weeks ago. Below is the response from Glen at the secretariat staff to my notification of the version change, which *was* sent weeks ago, on February 4th. The new version *has* been installed for the automated submission tool (I verified that yesterday before answering your first mail) but clearly there's an older copy somewhere else in their system. Your assumption of what I haven't done but should have done is incorrect. Your initial 'bugreport' contained no specifics whatsoever. You inappropriately sent the 'tool is broken' message to the whole IETF general discussion list, in addition to addressing me directly (so it's not as if you didn't know where to direct a bug report). All of the above earns you no respect with me, and that colours my responses. Next time, send a bug report to the secretariat or to me directly, containing specifics that lets us *fix* the problem, rather than blazoning an unspecific and unhelpful 'Things don't work' message across the sky, and you might get a different tone back. Henrik On 2010-02-04 20:09 Glen said the following: Installed! :-) Glen On 2/4/2010 3:31 AM, Henrik Levkowetz wrote: Hi, This is an automatic notification about a new idnits version, v2.12.01, generated when doing 'make upload' for idnits. Release notes: idnits (2.12.01) * The order of final double-quote and sentence stop in the ID-guidelines paragraph 5 text differed between the idnits expectations and the web page. Changed to accept both. * The ID-guidelines document combines the trust-specified statement of conformance with BCP 78 and 79 with the following statement of drafts being working documents into one paragraph, while idnits only would recognize them as separate paragraphs. Fixed to accept both. * Idnits expected the final URL in the ID-guidelines section 5 para 7 to end in a slash, while the guidelines specifies it without slash. Changed to accept both. The new version is available for download here: http://shiraz.tools.ietf.org/tools/idnits/idnits-v2.12.01 Regards, Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
On 2010-02-27 13:17 William Allen Simpson said the following: Henrik Levkowetz wrote: Your initial 'bugreport' contained no specifics whatsoever. You inappropriately sent the 'tool is broken' message to the whole IETF general discussion list, in addition to addressing me directly (so it's not as if you didn't know where to direct a bug report). All IETF draft submitters need to know promptly, as Monday is the deadline for -00 version internet-drafts. So you're still maintaining that it's good and right to send out a notice of a problem widely and provide no information which makes it possible to resolve it? Bah! It took some time (2 hours) to figure out that you had written the tool that generated the bad output, as the secretariat does not put your name (nor the tool name nor the version number) in their response message. I'm regretting wasting my time (finding you). So am I. And you probably shouldn't increment the .trivial for such a huge change. That was really a major change (as was 1id_guidelines itself). Maybe that's the reason the secretariat didn't think it was important enough to install. You're not duplicating what I've been saying. The tool *was* installed on February 4th. Somewhere there's been a slip-up, but translating that into evaluation of importance is nonsense. All of the above earns you no respect with me, and that colours my responses. Next time, send a bug report to the secretariat or to me directly, containing specifics that lets us *fix* the problem, rather than blazoning an unspecific and unhelpful 'Things don't work' message across the sky, and you might get a different tone back. It was reported to the secretariat directly ~13:53 EST by 'phone, but could not be fixed promptly. AFAICT, it's still not updated! http://tools.ietf.org/tools/idnits/ At this very moment: Version: 2.12.00 Ooh, that's not good. The .01 version is only available on some of the tools servers, not all. Fixed. Author: Note the author is missing here, too. Funny. I see my name quite clearly on the web page there. Also, the verbose output doesn't count line lengths correctly. Apparently, it is including the non-printing FF in the count. Not good. sarcasm Also, this was somewhat amusing: ** Obsolete normative reference: RFC 1700 (ref. 'RFC 3232') (Obsoleted by RFC 3232) Outstanding! Fails on the reference to RFC 1700 in the *title* of the RFC 3232 reference that obsoleted RFC 1700: I'm afraid I can't comment on this, as the error message is based on the content of the reference entry in your document, which you've not seen fit to provide, although I requested it in my first note. 1432 [RFC 3232] Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by 1433 an On-line Database, January 2002. /sarcasm At least the secretariat was smart enough to know that ** pseudo-error was bogus, and didn't include it in their message to me. I'm very gratified that you actually expect a mere computer program written by me to be able to make human grade intelligent evaluations of content. As I wrote previously, get off your high horse. We really don't need the attitude My attitude to you, sir, is that you should make it possible for me to fix things, by providing information instead of generalities of the it doesn't work type. I do what I do as a volunteer, and I certainly don't need the aggravation of broadcast generalities of this kind. Next time, test to see that your own code was installed and actually works. It's obvious that you never tested much of anything. It would be obvious to you if you'd looked at the idnits report of your own submission that idnits *had* been installed: https://datatracker.ietf.org/idst/display_idnit.cgi?submission_id=21622 So I'm afraid that your idea of what's obvious doesn't count for much with me. Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Based on my experience and that of other people, neither is true. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
+1 --On Saturday, February 27, 2010 08:49 -0500 John R. Levine jo...@iecc.com wrote: there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Based on my experience and that of other people, neither is true. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
I am very grateful for the efforts of Henrik and the rest of the tools team. They provide their services to the entire community with little recognition and no pay. They try very hard to keep the tools current and relevant. When I have found bugs, I have done my best to report them with very clear description of the problem that I encountered. And then, the problems have been corrected quickly. In my experience, a respectful interaction leads to speedy corrections. I think it is time to end this thread. It seems the most recent update was not installed on all of the tools servers, and that has been corrected. Russ Housley IETF Chair On 2/27/2010 7:47 AM, Henrik Levkowetz wrote: On 2010-02-27 13:17 William Allen Simpson said the following: Henrik Levkowetz wrote: Your initial 'bugreport' contained no specifics whatsoever. You inappropriately sent the 'tool is broken' message to the whole IETF general discussion list, in addition to addressing me directly (so it's not as if you didn't know where to direct a bug report). All IETF draft submitters need to know promptly, as Monday is the deadline for -00 version internet-drafts. So you're still maintaining that it's good and right to send out a notice of a problem widely and provide no information which makes it possible to resolve it? Bah! It took some time (2 hours) to figure out that you had written the tool that generated the bad output, as the secretariat does not put your name (nor the tool name nor the version number) in their response message. I'm regretting wasting my time (finding you). So am I. And you probably shouldn't increment the .trivial for such a huge change. That was really a major change (as was 1id_guidelines itself). Maybe that's the reason the secretariat didn't think it was important enough to install. You're not duplicating what I've been saying. The tool *was* installed on February 4th. Somewhere there's been a slip-up, but translating that into evaluation of importance is nonsense. All of the above earns you no respect with me, and that colours my responses. Next time, send a bug report to the secretariat or to me directly, containing specifics that lets us *fix* the problem, rather than blazoning an unspecific and unhelpful 'Things don't work' message across the sky, and you might get a different tone back. It was reported to the secretariat directly ~13:53 EST by 'phone, but could not be fixed promptly. AFAICT, it's still not updated! http://tools.ietf.org/tools/idnits/ At this very moment: Version: 2.12.00 Ooh, that's not good. The .01 version is only available on some of the tools servers, not all. Fixed. Author: Note the author is missing here, too. Funny. I see my name quite clearly on the web page there. Also, the verbose output doesn't count line lengths correctly. Apparently, it is including the non-printing FF in the count. Not good. sarcasm Also, this was somewhat amusing: ** Obsolete normative reference: RFC 1700 (ref. 'RFC 3232') (Obsoleted by RFC 3232) Outstanding! Fails on the reference to RFC 1700 in the *title* of the RFC 3232 reference that obsoleted RFC 1700: I'm afraid I can't comment on this, as the error message is based on the content of the reference entry in your document, which you've not seen fit to provide, although I requested it in my first note. 1432[RFC 3232] Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by 1433an On-line Database, January 2002. /sarcasm At least the secretariat was smart enough to know that ** pseudo-error was bogus, and didn't include it in their message to me. I'm very gratified that you actually expect a mere computer program written by me to be able to make human grade intelligent evaluations of content. As I wrote previously, get off your high horse. We really don't need the attitude My attitude to you, sir, is that you should make it possible for me to fix things, by providing information instead of generalities of the it doesn't work type. I do what I do as a volunteer, and I certainly don't need the aggravation of broadcast generalities of this kind. Next time, test to see that your own code was installed and actually works. It's obvious that you never tested much of anything. It would be obvious to you if you'd looked at the idnits report of your own submission that idnits *had* been installed: https://datatracker.ietf.org/idst/display_idnit.cgi?submission_id=21622 So I'm afraid that your idea of what's obvious doesn't count for much with me. Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 27 Feb 2010, at 13:49, John R. Levine wrote: there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Because, on inspection, both now and in the past, that is what it seems to do, for my personal domains. The difference in spam, and the apparent lack of lost mail, leads me to the conclusion that this small hack is worth the keeping, for now. Of course, I am more concerned about the lost mail, and I suspect that the IETF is more exposed to that possibility. In that case, it would be unwise. But it works for me, and given that it's in no way improper or non-standard, I don't see why it shouldn't for the IETF. Based on my experience and that of other people, neither is true. O.K. I must be very lucky indeed. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
