Re: Fighting spam via greylisting
Jeremy Huntwork wrote: Be advised that your first post to a mailing list might be delayed by a few minutes. If it takes a considerably long time, or if you receive an undeliverable message from your MTA, please let us know at server-admin AT linuxfromscratch DOT org so that we can adjust our whitelisting files. Er. If you're having trouble mailing because of greylisting, then obviously a message to another mailing list on the same server isn't going to get through either. In that case, please send a message to my gmail account. My username is quadrata. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Jeremy Huntwork wrote: The basic idea is that whenever a new MTA (one that is not in the greylisting database) attempts to deliver mail, the mail is automatically rejected. If the MTA is a valid MTA, it will retry to deliver the mail after a few minutes. Assuming the user doesn't get a your message has been delayed message from their MTA in the meantime. It's been a while since I looked at the SMTP RFC(s), so I don't know if there's any minimum time (or minimum number of attempts) that have to pass before the user gets notified, but I'm guessing there isn't. If that's true, it would be valid for an MTA to notify the user if the first attempt failed. (Of course I don't know if there *are* any MTAs that work like this, either.) If there are any users on a setup like this, I can see some confusion happening. Also, the after a few minutes may be how most MTAs today work, but I doubt it's required behavior. I would bet that either the retry intervals are completely up to the MTA, or that the RFCs specify a minimum but not a maximum. I would bet that a half-hour retry interval would be legal. Finally, I would hope that when the greylisting engine rejects a mail, it does so with a temporary-failure code (4xx), not a permanent-failure code (5xx). Otherwise MTAs don't have to retry the messages, and some likely won't. I would assume that something like this has been thought through by the people that implemented the greylisting already, but it might be worthwhile to make sure. If I remember, I'll try sending a mail directly from my IP to my @lfs.org address through telnet, which should get rejected by the greylist, and see what response I get. (Of course I'm on a dynamic IP, too. Hope that doesn't complicate things.) It sounds like this will reduce spam, yes, but I'm just slightly concerned it will also introduce some user confusion (either due to your message hasn't been delivered yet messages or I send this an hour ago, and it hasn't been delivered yet! because their MTA is slow doing retries). But maybe I'm just used to the way people think at work (if it doesn't work RIGHT NOW, it's not working: call support!). signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Jeremy Huntwork wrote these words on 04/07/07 20:40 CST: I tried a Postfix implementation called Postgrey on my own personal server and the results were very good. (See http://postgrey.schweikert.ch/). Based on those results it was decided to implement this service on Quantum. Who decided? Were things so bad this had to happen? I am against it. I have not been receiving significant spam mail to my LFS account. And we only had two recent episodes of spam reaching Trac stuff. The reason I'm against it is because of the complications that may happen (Jeremy already described, and the solution is to send an email to some private address which isn't even listed, you have to kind of figure it out and hope you guess the domain name correctly; a month from know, is anyone going to have a clue what the hell that email addy was?), and Richards statement of I also may have lost some important emails, but I'll never know. Oh well, just my two cents. However, as this was decided outside the community, by who knows, I don't expect a reply, just wanted to chime in. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 09:10:00 up 3 days, 14:07, 1 user, load average: 0.14, 0.20, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Randy McMurchy wrote: Jeremy Huntwork wrote these words on 04/07/07 20:40 CST: I tried a Postfix implementation called Postgrey on my own personal server and the results were very good. (See http://postgrey.schweikert.ch/). Based on those results it was decided to implement this service on Quantum. Who decided? Jeremy and I discussed it and thought it would be good to try. Were things so bad this had to happen? I am against it. I have not been receiving significant spam mail to my LFS account. And we only had two recent episodes of spam reaching Trac stuff. You haven't been seeing it because we've been managing it. This action was to try to reduce the management workload. The reason I'm against it is because of the complications that may happen (Jeremy already described, and the solution is to send an email to some private address which isn't even listed, you have to kind of figure it out and hope you guess the domain name correctly; a month from know, is anyone going to have a clue what the hell that email addy was?), and Richards statement of I also may have lost some important emails, but I'll never know. Oh well, just my two cents. However, as this was decided outside the community, by who knows, I don't expect a reply, just wanted to chime in. The systems is supposed to just give a temporary failure. Standard MTAs are resigned to retry temporary failures. Many times spammers use cut down mailers and don't retry. That's the theory any way. The retry should be transparent to the user. The standard notification interval that I've seen is to notify temporary failures after 4 hours and stop trying after 5 days. We are only giving a temp failure message for 5 minutes. If this causes problems, we'll remove the function. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 04:28, Bruce Dubbs escribió:
Please, try to keep the CC to lfs-dev.
I do think that each section in Chapters 5 and 6 that install a new
package should start on a new page, but places like Chapters 8 and 9 and
possibly 1, 2, 3, 4, and 7 should 'flow'.
Yes, I was thinking also about that. The code was committed some hours ago.
Now the PDF have only 254 pages:
http://www.lfs-es.info/new-lfs-book/fop1-try2-lfs-book.pdf
It would also be nice to solve the problem of long urls that cause ugly
spacing when the text is fully justified. Examples are: page 13
(section 1.5), page 14, page 206 (section 7.5), page 217 (7.12.1).
The last paragraph on page 224 (8.2) also suffers from the
long-name-spacing-problem.
These word spacing issues vary a bit in 'badness', but it would be nice
if there were optional (zero width space) breaks at slash ('/') and
underscore ('_') characters.
The URLs hyphenation support on the old stylesheets and FOP-0.20 was very
ugly. I will test if the current one is more usable and, if true, trying to
extend the support also to filenames.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Bruce Dubbs wrote: The systems is supposed to just give a temporary failure. And it does -- after the RCPT TO, it gives a 450 4.7.1 rcpt-addr: Recipient address rejected: greylisted, see url type response. So at least the postgrey people were smart enough to do that. ;-) Many times spammers use cut down mailers and don't retry. Yeah, but how hard would it be to add retrying to a spammer's botnet software? I'm going to predict that within the next year, if greylisting is implemented widely (and I've been hearing about it a lot, but I don't know how many servers actually do it), the spammers will just start retrying once if they get a temporary-error response. But hey, for the moment, it might work. Probably worth a try at least. We are only giving a temp failure message for 5 minutes. Yes, but my ISP's mailer doesn't retry for at least 10 minutes. The message I sent whose date was 9:06 AM EST didn't actually get delivered to me until 9:18 AM EST; the intervening time was the server delay. Not that that's bad, mind you, but I don't think it's specified either (the delay could have been a couple hours). signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Bryan Kadzban wrote: Yes, but my ISP's mailer doesn't retry for at least 10 minutes. The message I sent whose date was 9:06 AM EST didn't actually get delivered to me until 9:18 AM EST; the intervening time was the server delay. Not that that's bad, mind you, but I don't think it's specified either (the delay could have been a couple hours). Yes, and that is only once. After that, you are whitelisted and won't get any delay from quantum. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: El Domingo, 8 de Abril de 2007 04:28, Bruce Dubbs escribió: Please, try to keep the CC to lfs-dev. Yes, I was a little too quick in replying. I think the lfs-dev is the proper place for this discussion. I do think that each section in Chapters 5 and 6 that install a new package should start on a new page, but places like Chapters 8 and 9 and possibly 1, 2, 3, 4, and 7 should 'flow'. Yes, I was thinking also about that. The code was committed some hours ago. Now the PDF have only 254 pages: http://www.lfs-es.info/new-lfs-book/fop1-try2-lfs-book.pdf I like this a lot better. Now I'm going to get a bit picky about the pdf, but its offered in a constructive manner. Don't feel obligated to fix any of these issues. I'd like to see other opinions too. 1. The font on the headers doesn't seem right. Most of the text is standard serif fonts (computer modern?). That looks fine. The headers are sans-serif and bold. The bold seems a little too wide. Looking at a typical O'Reilly book, they use ITC Garamond Light (Italic) for headings and Garamond Book for the normal text. It seems to flow there pretty nicely. How much control do we have over fonts? 2. The highlighted text has borders that seem a little heavy. The notes have borders that are light gray. 'Important' and 'Caution' areas have the heavy border too. Perhaps removing the border completely from the gray backgrounds and using the light gray border for all the light yellow backgrounds would give a better visual appearance. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
On Sun, Apr 08, 2007 at 10:28:06AM -0500, Bruce Dubbs wrote: You haven't been seeing it because we've been managing it. This action was to try to reduce the management workload. Thanks for what you guys have been doing. Hope this works. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
On Sun, 08 Apr 2007 09:17:03 -0500 Randy McMurchy [EMAIL PROTECTED] wrote: Jeremy Huntwork wrote these words on 04/07/07 20:40 CST: I tried a Postfix implementation called Postgrey on my own personal server and the results were very good. (See http://postgrey.schweikert.ch/). Based on those results it was decided to implement this service on Quantum. Who decided? Were things so bad this had to happen? I am against it. I have not been receiving significant spam mail to my LFS account. And we only had two recent episodes of spam reaching Trac stuff. The reason I'm against it is because of the complications that may happen (Jeremy already described, and the solution is to send an email to some private address which isn't even listed, you have to kind of figure it out and hope you guess the domain name correctly; a month from know, is anyone going to have a clue what the hell that email addy was?), and Richards statement of I also may have lost some important emails, but I'll never know. Oh well, just my two cents. However, as this was decided outside the community, by who knows, I don't expect a reply, just wanted to chime in. Randy, Justifiable scepticism! But just to ally some fears, I have been checking my greylisting logs across the whole time I've been running it, and there are *almost* no Ham messages that have been rejected. I have had two instances where a big server farm insisted on sending the retrys from many different IPs. This can confuse some greylisters - glst/xmail has a method of handling this, but it needs careful setup. The culprit is gmail/googlemail!! I expect the postgrey system that LFS is using also has these controls, if not, that is a worry. The logs will tell, but that's a chore. As with all mailserver management, the secret is in proper log analysis. And I only recommended a test. Happy Easter. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cups-1.2.10
Randy McMurchy wrote: Hi all, Currently, the book has CUPS-1.2.7. 1.2.10 is the current version. However, the current version fails the test suite miserably. It is a known bug, and fixed in SVN. I made a very small patch that updates the 1.2.10 'test' directory to SVN, and all but 1 test passes (there are 9 that fail before the patch). Note that you must run the dbus-uuidgen program first, or you will get additional failures. I cannot figure out which other file(s) needs changing to get all the tests to fail, so I created a patch that bumps the current version (1.2.10) to current SVN. It builds, and tests just fine. Here are the files changed using the bigger patch: Our choices are this: 1. Simply leave 1.2.7 in the book until 1.2.11 comes out. 2. Use the small patch (4006 bytes) and note in the book that one test will fail. 3. Use the larger patch (706998 bytes) and call it 'upstream_fixes' or something. 4. Do something else (Fedora CVS doesn't really help, and I didn't check any other distro, including Paldo). Which way should we go? I understand that the tests fail due to test suite problems, but does the program itself fail in normal use? It sounds like #2 would be a temporary workaround until 1.2.11 comes out (#1). Perhaps that is the best way to go. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 17:33, M.Canales.es escribió: The URLs hyphenation support on the old stylesheets and FOP-0.20 was very ugly. I will test if the current one is more usable and, if true, trying to extend the support also to filenames. And done: http://www.lfs-es.info/new-lfs-book/fop1-try3-lfs-book.pdf -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
On Sat, 7 Apr 2007 19:40:12 -0600 Jeremy Huntwork [EMAIL PROTECTED] wrote: Greetings All, Inspired by an email from Richard Downing, I decided to look into using greylisting to help fight spam. If you haven't heard of it before see: http://www.greylisting.org Did you see this system for 'autowhitelisting' that works with postgrey? http://oc-co.org/p2pwl/ I'm not using it. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 19:30, Bruce Dubbs escribió: I like this a lot better. Thanks. Now I'm going to get a bit picky about the pdf, but its offered in a constructive manner. Don't feel obligated to fix any of these issues. I'd like to see other opinions too. Starting with my owns ones ;-) 1. The font on the headers doesn't seem right. Most of the text is standard serif fonts (computer modern?). That looks fine. The headers are sans-serif and bold. The bold seems a little too wide. My acroreader say that the used ones are this Arial-BoldMT TimesNewRomanPSMT TimesNewRomanPS-ItalicMT TimesNewRomanPS-BoldMT Courier-Bold Courier Courier-Oblique Courier-BoldOblique Looking at a typical O'Reilly book, they use ITC Garamond Light (Italic) for headings and Garamond Book for the normal text. It seems to flow there pretty nicely. How much control do we have over fonts? http://xmlgraphics.apache.org/fop/0.93/fonts.html I have not full read it yet, but look that for files outside the ones listed above extra FOP configurations are needed and may implies that the user/reader must have intalled that fonts on their system. 2. The highlighted text has borders that seem a little heavy. The notes have borders that are light gray. 'Important' and 'Caution' areas have the heavy border too. Perhaps removing the border completely from the gray backgrounds and using the light gray border for all the light yellow backgrounds would give a better visual appearance. The colors and border are the same than the ones used on the XHTML output. The border could be changed from 1pc to 0.5pc to make ir less heavy, but in resume I would to have the same look in both versions. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: El Domingo, 8 de Abril de 2007 17:33, M.Canales.es escribió: The URLs hyphenation support on the old stylesheets and FOP-0.20 was very ugly. I will test if the current one is more usable and, if true, trying to extend the support also to filenames. And done: http://www.lfs-es.info/new-lfs-book/fop1-try3-lfs-book.pdf Looks nice. One place that is still a problem is the last paragraph of 8.2 (page 212). The long config variables, CONFIG_NLS_DEFAULT, CONFIG_SMB_NLS_DEFAULT, CONFIG_FAT_DEFAULT_CODEPAGE, and CONFIG_FAT_DEFAULT_IOCHARSET throw off the word spacing. If a break was made at the underscores, it would improve that paragraph. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: 1. The font on the headers doesn't seem right. Most of the text is standard serif fonts (computer modern?). That looks fine. The headers are sans-serif and bold. The bold seems a little too wide. My acroreader say that the used ones are this Arial-BoldMT TimesNewRomanPSMT TimesNewRomanPS-ItalicMT TimesNewRomanPS-BoldMT Courier-Bold Courier Courier-Oblique Courier-BoldOblique Is this a function of the reader's system or the system that renders the pdf. I thought the actual fonts used were enclosed in the file. I'm not 100% sure though. 2. The highlighted text has borders that seem a little heavy. The notes have borders that are light gray. 'Important' and 'Caution' areas have the heavy border too. Perhaps removing the border completely from the gray backgrounds and using the light gray border for all the light yellow backgrounds would give a better visual appearance. The colors and border are the same than the ones used on the XHTML output. The border could be changed from 1pc to 0.5pc to make ir less heavy, but in resume I would to have the same look in both versions. 0.5pc? I think that's a pica which is 1 PostScript pica = 4.2333 millimeters I don't think the borders are that thick--at least not on my system. My estimate is about 1 mm. Are you sure that's not the margin? Where is the border specified? Perhaps we could do some preprocessing for the pdf. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cups-1.2.10
Bruce Dubbs wrote these words on 04/08/07 13:06 CST: Randy McMurchy wrote: 3. Use the larger patch (706998 bytes) and call it 'upstream_fixes' or something. Which way should we go? I understand that the tests fail due to test suite problems, but does the program itself fail in normal use? Dunno. Never tried it. I typically won't install a package that has a myriad of test failures, when all the tests in prior versions *never* failed. It sounds like #2 would be a temporary workaround until 1.2.11 comes out (#1). Perhaps that is the best way to go. Well, after thinking about it some more, I feel a new version will be released soon. So, I used the large patch which takes the package to a version which may end up being the next production version. And that's the one I want to install on my test system, and test all the other packages against. So, since I cannot vouch for the 1.2.10 (unpatched) as working, I'll leave the update for someone else, or we'll just move to 1.2.11 when it is released. Attached is the small patch if anyone's interested in updating CUPS to 1.2.10. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 14:07:00 up 3 days, 19:04, 1 user, load average: 0.17, 0.04, 0.02 diff -Naur cups-1.2.10/test/4.2-cups-printer-ops.test cups-1.2.11/test/4.2-cups-printer-ops.test --- cups-1.2.10/test/4.2-cups-printer-ops.test 2006-08-16 15:05:58.0 -0500 +++ cups-1.2.11/test/4.2-cups-printer-ops.test 2007-04-08 11:35:22.0 -0500 @@ -1,5 +1,5 @@ # -# $Id: 4.2-cups-printer-ops.test 5833 2006-08-16 20:05:58Z mike $ +# $Id: 4.2-cups-printer-ops.test 6381 2007-03-21 15:19:02Z mike $ # # Verify that the CUPS printer operations work. # @@ -105,7 +105,7 @@ ATTR name requesting-user-name $user GROUP subscription - ATTR uri notify-recipient testnotify:// + ATTR uri notify-recipient-uri testnotify:// ATTR keyword notify-events printer-added,printer-modified,printer-deleted # What statuses are OK? @@ -258,5 +258,5 @@ } # -# End of $Id: 4.2-cups-printer-ops.test 5833 2006-08-16 20:05:58Z mike $ +# End of $Id: 4.2-cups-printer-ops.test 6381 2007-03-21 15:19:02Z mike $ # diff -Naur cups-1.2.10/test/4.3-job-ops.test cups-1.2.11/test/4.3-job-ops.test --- cups-1.2.10/test/4.3-job-ops.test 2006-05-05 11:33:57.0 -0500 +++ cups-1.2.11/test/4.3-job-ops.test 2007-04-08 11:35:22.0 -0500 @@ -1,5 +1,5 @@ # -# $Id: 4.3-job-ops.test 5493 2006-05-05 16:33:57Z mike $ +# $Id: 4.3-job-ops.test 6381 2007-03-21 15:19:02Z mike $ # # Verify that the IPP job operations work. # @@ -69,7 +69,7 @@ ATTR name requesting-user-name $user GROUP subscription - ATTR uri notify-recipient testnotify + ATTR uri notify-recipient-uri testnotify FILE testfile.jpg @@ -297,5 +297,5 @@ } # -# End of $Id: 4.3-job-ops.test 5493 2006-05-05 16:33:57Z mike $ +# End of $Id: 4.3-job-ops.test 6381 2007-03-21 15:19:02Z mike $ # diff -Naur cups-1.2.10/test/4.4-subscription-ops.test cups-1.2.11/test/4.4-subscription-ops.test --- cups-1.2.10/test/4.4-subscription-ops.test 2006-08-16 15:05:58.0 -0500 +++ cups-1.2.11/test/4.4-subscription-ops.test 2007-04-08 11:35:22.0 -0500 @@ -1,5 +1,5 @@ # -# $Id: 4.4-subscription-ops.test 5833 2006-08-16 20:05:58Z mike $ +# $Id: 4.4-subscription-ops.test 6381 2007-03-21 15:19:02Z mike $ # # Verify that the CUPS subscription operations work. # @@ -18,7 +18,7 @@ ATTR uri printer-uri $method://$hostname:$port/printers/Test1 GROUP subscription - ATTR uri notify-recipient testnotify:// + ATTR uri notify-recipient-uri testnotify:// ATTR keyword notify-events printer-state-changed ATTR integer notify-lease-duration 5 @@ -71,12 +71,12 @@ ATTR uri printer-uri $method://$hostname:$port/printers/Test1 GROUP subscription - ATTR uri notify-recipient testnotify:// + ATTR uri notify-recipient-uri testnotify:// ATTR keyword notify-events printer-state-changed ATTR integer notify-lease-duration 5 GROUP subscription - ATTR uri notify-recipient testnotify:// + ATTR uri notify-recipient-uri testnotify:// ATTR keyword notify-events printer-config-changed ATTR integer notify-lease-duration 5 @@ -118,5 +118,5 @@ } # -# End of $Id: 4.4-subscription-ops.test 5833 2006-08-16 20:05:58Z mike $ +# End of $Id: 4.4-subscription-ops.test 6381 2007-03-21 15:19:02Z mike $ # diff -Naur cups-1.2.10/test/run-stp-tests.sh cups-1.2.11/test/run-stp-tests.sh --- cups-1.2.10/test/run-stp-tests.sh 2006-11-15 14:37:45.0 -0600 +++ cups-1.2.11/test/run-stp-tests.sh 2007-04-08 11:35:22.0 -0500 @@ -1,6 +1,6 @@ #!/bin/sh # -# $Id: run-stp-tests.sh 6113 2006-11-15 20:37:45Z mike $ +# $Id: run-stp-tests.sh 6393 2007-03-24 14:37:13Z mike $ # # Perform the complete set of IPP compliance tests specified in the # CUPS Software Test Plan. @@ -405,6 +405,13 @@ export HOME # +# Force
Re: Fighting spam via greylisting
Jeremy Huntwork wrote these words on 04/08/07 12:47 CST: Anyway, the fact that we are having this conversation and that mailman is processing fewer junk emails shows that it is working as we hoped. But it appears that mails are taking 30 minutes or more to be delivered, even for whitelisted addresses, and it used to take about 30 seconds. Is this due to the changes, or something else going on with Quantum? -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 14:20:00 up 3 days, 19:17, 1 user, load average: 0.38, 0.24, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 20:52, Bruce Dubbs escribió: One place that is still a problem is the last paragraph of 8.2 (page 212). The long config variables, CONFIG_NLS_DEFAULT, CONFIG_SMB_NLS_DEFAULT, CONFIG_FAT_DEFAULT_CODEPAGE, and CONFIG_FAT_DEFAULT_IOCHARSET throw off the word spacing. If a break was made at the underscores, it would improve that paragraph. Actually that parameters are not tagged at this moment, thus can't be hyphenated. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 21:10, Bruce Dubbs escribió: Is this a function of the reader's system or the system that renders the pdf. I thought the actual fonts used were enclosed in the file. I'm not 100% sure though. For specifications, the Base-14 fonts must be available to all PDF readers and are not embedded, except if forced. Additional fonts must be embedded or be available to the readers. What I noticed, is that in Acrobat Reader 5.0 the fonts looks nice, but in KGoshtView looks a little ugly. Maybe due that Acrobat Reader uses their own fonts while other readers uses the ones from gs? 0.5pc? I think that's a pica which is 1 PostScript pica = 4.2333 millimeters I don't think the borders are that thick--at least not on my system. My estimate is about 1 mm. Are you sure that's not the margin? Where is the border specified? Perhaps we could do some preprocessing for the pdf. In new-xsl/stylesheets/pdf/lfs-admon.xsl for admonitions and new-xsl/stylesheets/pdf/lfs-mixed.xsl for verbatim environments. The line to search in both is: xsl:attribute name=border-width1pt/xsl:attribute Changing it to 0.5pt looks a good idea. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Randy McMurchy wrote: Jeremy Huntwork wrote these words on 04/08/07 12:47 CST: Anyway, the fact that we are having this conversation and that mailman is processing fewer junk emails shows that it is working as we hoped. But it appears that mails are taking 30 minutes or more to be delivered, even for whitelisted addresses, and it used to take about 30 seconds. Is this due to the changes, or something else going on with Quantum? I'm not sure. When I look at the log, I see: Apr 8 09:58:29 quantum postgrey[8131]: delayed 768 seconds: client=mail.bethelcolleg e.edu, [EMAIL PROTECTED], [EMAIL PROTECTED] but I don't think you really want to receive that one. :) I also see Apr 7 23:51:26 quantum postgrey[8131]: delayed 7717 seconds: client=qsrv02sl.mx.bigpond.com, [EMAIL PROTECTED], [EMAIL PROTECTED] Which doesn't look right either. I don't see anything *from* you that has been delayed, but it would be easy to miss something. I'll continue to investigate. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
TheOldFellow wrote: I have had two instances where a big server farm insisted on sending the retrys from many different IPs. This can confuse some greylisters - glst/xmail has a method of handling this, but it needs careful setup. The culprit is gmail/googlemail!! I expect the postgrey system that LFS is using also has these controls, if not, that is a worry. Postgrey does, indeed have a control. Postgrey comes with two whitelists. One is a list of users that you never want greylisted (the default file has [EMAIL PROTECTED] and [EMAIL PROTECTED] in it) and the other is a list of senders that need special handling. Google's mail farm is one such instance that appears in the default file. The logs will tell, but that's a chore. As with all mailserver management, the secret is in proper log analysis. Yes. And it's easy to disable at any time, should we need to. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
M.Canales.es wrote: What I noticed, is that in Acrobat Reader 5.0 the fonts looks nice, but in KGoshtView looks a little ugly. Maybe due that Acrobat Reader uses their own fonts while other readers uses the ones from gs? Sounds right. I was using xpdf. In new-xsl/stylesheets/pdf/lfs-admon.xsl for admonitions and new-xsl/stylesheets/pdf/lfs-mixed.xsl for verbatim environments. The line to search in both is: xsl:attribute name=border-width1pt/xsl:attribute Changing it to 0.5pt looks a good idea. A pt is 1/72nd of an inch. Do we have to use pt? How about 1px? Or better yet, for the pdf only in lfs-mixed.xsl, 0pt? I'll pull the xsl and look some more. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Bruce Dubbs wrote these words on 04/08/07 15:06 CST: I don't see anything *from* you that has been delayed, but it would be easy to miss something. I'll continue to investigate. All mails appear to lag about 30 minutes. From everyone. I'm going on the time the email is sent by the sender, and the time it hits my mailbox. My polling for mail is not the issue. In fact, your mail that I am replying to was sent at 15:06, but didn't hit my mailbox until about 15:35. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 15:40:00 up 3 days, 20:37, 1 user, load average: 0.13, 0.05, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
El Domingo, 8 de Abril de 2007 22:32, Bruce Dubbs escribió: I'll pull the xsl and look some more. Great, I need inputs about the explanatory comments. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [new XSL] Ready for inputs.
Manuel, I pulled the new style sheets from svn. How do you use them? Do you just have a temporary symbolic link from the trunk/BOOK/stylesheets to ../../branches/new-xsl/ ? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Default filesystem
Dan Nicholson escribió: On 2/3/07, TheOldFellow [EMAIL PROTECTED] wrote: What I need is something it can't handle, like Udev for several months a year ago, or a new booting scheme... This is actually something I want to bring up. Our booting is dog slow. Maybe it's time to look into making improvements. We could replace init with init-ng or upstart. Or, we could just work to parallelize the bootscripts like is done on RedHat and SuSE. I think this has been brought up before. -- Dan For desktop systems it doesn't matter how long it takes to boot, what matters is how long it takes to load a getty or a dm ;). In my current system, an Pentium III @ 450MHz, the runlevel takes 8 secs to be up, but gettys are available at 4 secs, or less, i'm not sure... My system is somewhat deviated, so a normal LFS may take a bit more, but the gettys/dm will be up as soon as possible, that's the beauty of initng, it does it without any effort :). -- Ismael Luceno [EMAIL PROTECTED] [EMAIL PROTECTED] InitNG maintainer and project lead - http://www.initng.org Registered Linux User #439653 - http://counter.li.org LFS User #17162- http://www.linuxfromscratch.org SourceMage GNU/Linux User - http://www.sourcemage.org IRC: ismaell @ irc.freenode.net #initng #uruguay #cross-lfs Jabber ID: [EMAIL PROTECTED] Blog: http://ismaell.wordpress.com GPG Key ID: EC8E5C9A GPG Key Fingerprint: 1356 7578 232E CCA6 D16D 46A8 FE6C 58D3 EC8E 5C9A signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Randy McMurchy wrote these words on 04/08/07 15:43 CST: All mails appear to lag about 30 minutes. From everyone. I'm going on the time the email is sent by the sender, and the time it hits my mailbox. My polling for mail is not the issue. There was no reply to my comments. And emails throughout the day have been one-half-hour late in delivery. So, we are now looking at a half-hour delay in delivering mail so that the management issues are lessened. This, I'm afraid, will be the death of the project. Is lessening the effort to eliminate spam, worth it? We cannot continue with a half-hour delay in delivery of mail. This would put us totally in an IRC support basis. Are we ready to do this? -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 20:44:00 up 4 days, 1:41, 1 user, load average: 0.28, 0.16, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Testing time response
Time now 2211 CDT -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Randy McMurchy wrote: Randy McMurchy wrote these words on 04/08/07 15:43 CST: All mails appear to lag about 30 minutes. From everyone. I'm going on the time the email is sent by the sender, and the time it hits my mailbox. My polling for mail is not the issue. There was no reply to my comments. And emails throughout the day have been one-half-hour late in delivery. So, we are now looking at a half-hour delay in delivering mail so that the management issues are lessened. This, I'm afraid, will be the death of the project. Is lessening the effort to eliminate spam, worth it? We cannot continue with a half-hour delay in delivery of mail. This would put us totally in an IRC support basis. Are we ready to do this? Yes, we know. We have backed out the graylisting, but the delay is still there. We are investigating right now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Randy McMurchy wrote: Randy McMurchy wrote these words on 04/08/07 15:43 CST: All mails appear to lag about 30 minutes. From everyone. I'm going on the time the email is sent by the sender, and the time it hits my mailbox. My polling for mail is not the issue. There was no reply to my comments. And emails throughout the day have been one-half-hour late in delivery. So, we are now looking at a half-hour delay in delivering mail so that the management issues are lessened. This, I'm afraid, will be the death of the project. Is lessening the effort to eliminate spam, worth it? We cannot continue with a half-hour delay in delivery of mail. This would put us totally in an IRC support basis. Are we ready to do this? Jeremy and I have been working on the mail problem we caused with the graylisting. There may have been multiple problems, but we think we've got them fixed. The graylisting is backed out and test messages to at least two lists were posted and echoed back in about 2 minutes. The theory about the graylisting was to send a 'try again later' message to the mail servers when first contacted. After the mail server is 'validated' by trying again, the server is put in a database and accepted immediately if the same server tries again. The problem as we can tell is that many large ISPs use multiple servers for outgoing MTAs. This causes a delay for every server. Additionally, the retry time is up to the sender and delays of hours is not uncommon if the first connection is rejected. This is not acceptable for world wide mailing lists like the ones at LFS. We're sorry about the delays today, but we can't improve things if we don't test them out. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Bruce Dubbs wrote: We're sorry about the delays today There still seems to be a delay to the lists. And FWIW, if you were monitoring the lists at all the past _week_ or so you would have noticed that there was a delay on the lists. I only implemented greylisting on quantum yesterday. Obviously, this shows that the problem lies elsewhere. I'll be investigating this further. Mailman receives messages nearly right away and posts them to pipermail, but it seems that _outgoing_ mail from mailman is delayed by quite a bit. Again, this would have had nothing to do with greylisting installed on our server. Digging deeper... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Jeremy Huntwork wrote: Digging deeper... Time test to lfs-dev, 0046 EDT - please ignore -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Jeremy Huntwork wrote: Jeremy Huntwork wrote: Digging deeper... Time test to lfs-dev, 0046 EDT - please ignore This one came through right away. There was a user subscribed to alfs-discuss and lfs-support that was using an unresolvable domain. Mailman was attempting to deliver to this user twice every thirty seconds, and the postfix mail queue was filled with mail headed for this user. Forcibly removing the user from the lists and restarting postfix and mailman _seems_ to have fixed the issue. Although why one unresolvable domain was causing so much trouble, I'm not sure. I'm looking into it further... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
Jeremy Huntwork wrote: Forcibly removing the user from the lists and restarting postfix and mailman _seems_ to have fixed the issue. Although why one unresolvable domain was causing so much trouble, I'm not sure. I'm looking into it further... Just to reiterate, greylisting was *not* the reason why posts were consistently delayed today. If it is felt that it is better left off the server, then that's fine, I will concede and will keep it disabled. The issue was always with *outgoing* mail from mailman and a flooded mail queue, not a delay of accepting *incoming* mail which would have only happened once for each MTA. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
