Re: localisation in system wide daemons
Hi All! On v, 2006-12-31 at 00:08 +0100, Marc Haber wrote: > > For the record: I maintain two widely installed packages which are > translated to a gazillion of languages (exim4 and adduser, to be > exact), and I have never received a non-english bug report. Then you lucky or your packages do it right. :) My problem is not with the bug report language but the cut&pasted log messages language. If I got a bug report I allways ask for log messages (not for my packages but in some mailing list) and it's vwey confusable if I cannot read or understand the log messages. And if I had have a package with a lot of messages it would have been a PIA. (IMHO) PS: My signature is correct or too short? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
Josip Rodin wrote: Yes. Just like any other large amount of traffic could be harmful on big domains. I will be more precise. Answering a rcpt-to is, in my case, around 20 to 30% of the job of the "storage cluster" to deliver a mail (I am not talking about CPU, just disks IOs). If the number of mails sent as from our domains is equivalent to the number of mails we receive and if everybody use sender verify, it would mean we have to increase our IOs capacity by 20 to 30% (I know, there is 2 "if" and it is a very rough figure). I guess the counter-argument could be - all those services are explicitly created in order to voluntarily serve requests, but nobody volunteered their server to answer sender verification requests. Yet, a sender verification request is nothing but a three-command SMTP conversation. If someone puts an SMTP server online, and connects it via DNS, it's not exactly strange that other people talk to it. No, a rcpt-to is not intended to verify an email but to deliver an mail. You may use VRFY if you want to 1) verify an email and 2) check if you are allowed to verify... :-) IMHO, using rcpt-to to verify sender is just like using resume download to do segmented/parallel downloads. It works but you are using the command in an perverted/antisocial way. François -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
On Sat, 30 Dec 2006 19:13:57 +0100, Michelle Konzack <[EMAIL PROTECTED]> wrote: >Maybe the package maintainer do not want to get bugreports >for his/her package in 100 differns languages? You are - again - taking about something you don't understand. For the record: I maintain two widely installed packages which are translated to a gazillion of languages (exim4 and adduser, to be exact), and I have never received a non-english bug report. The "worst" that happened was that somebody contacted my via private e-mail in German, but these somebodies probably knew that German is my native language. Oh, yeah, right. Kindly fix your signature. It is ridiculously overlong. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 03:14:45PM +0100, Josip Rodin wrote: > On Sat, Dec 30, 2006 at 05:34:28AM -0800, Ryan Murray wrote: > [...] > > The mail gateway, web scripts, and userdir-ldap command line interface > > have all been updated to deal with the new fields. > Thanks Ryan. As usual, you do the right thing. I'm still sad that we all > have to wait for you to get sufficient free time slots to do these kinds > of things, but hey. > I should note that the mail bot is a wee bit too simple when processing > the new mailRBL field; I did this: > % echo mailrbl sbl.spamhaus.org | gpg --clearsign | mail -s mailrbl [EMAIL > PROTECTED] > % echo mailrbl list.dsbl.org | gpg --clearsign | mail -s mailrbl [EMAIL > PROTECTED] > which resulted in only the latter being in the mailRBL field in the LDAP > database. It works when both settings are specified in a single batch. > I figure it's a consequence of the ldapmodify default changetype being > 'replace'. I suppose that's a sane default, but it could still be a bit > confusing to people who don't know/notice. Nothing new here, this is how the mail gateway has handled debian.net DNS entries for years. (If it didn't do it this way, how would you have the gateway *delete* old entries?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
* Paul Waring: > I've seen a lot of announcement/verification emails (such as Amazon > orders) which go out from an address that does not exist - In the SMTP envelope? I strongly doubt that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
Am 2006-12-22 09:37:35, schrieb Javier Fernández-Sanguino Peña: > IMHO, either that software should be modified to support i18n text or the > admin would have to choose wether he prefers to *understand* the logfile or > to be able to parse it with automatic programs (I believe you are talking > about tools such as logcheck or log-analysis [1][2]). > > In any case, it would not be too difficult to adjust programas that parse > logs to be able to parse translated messages. Take in account that all > translated text messages would be available in a message catalog (typically a > PO file). Sorry, but "gettext" does not support reverse lookups > msgstr "media error (bad sector): status=" > msgstr "error en el medio (sector defectuoso): estado=" But you can look-up only for the englisch string and get the translated back Now imagine you have 100 *.mo files and each with 100 strings The loganalyzer must read ALL 100 *.mo files and parse all 100 strings in it and then compare it with the message in the logfile... > a.- be able to use software that generates reports from logfiles with english > messages, and not being able to understand the logfiles themselves and > (probably) not the reports either (if the reporting software is not i18nised) If a non-native english speaker want to analyze logfiles, the loganalyzer should do the translation... The log analyzer should be configurable if it get a string like 8<-- Dec 27 12:25:01 michelle1 init: Re-reading inittab Dec 27 12:25:01 michelle1 last message repeated 2 times Dec 27 12:28:08 michelle1 uptimed: milestone: 9 days, 00:00:00 (Neun Tage) Dec 27 12:28:08 michelle1 sSMTP[11044]: Unable to set AuthUser="[EMAIL PROTECTED]" Dec 27 12:28:08 michelle1 sSMTP[11044]: Unable to set AuthPass="" Dec 27 12:28:08 michelle1 sSMTP[11044]: Server didn't accept AUTH LOGIN (535 Authentication rejected) Dec 27 12:30:01 michelle1 init: Re-reading inittab Dec 27 12:30:01 michelle1 last message repeated 2 times Dec 27 21:20:01 michelle1 init: Re-reading inittab Dec 27 21:20:01 michelle1 last message repeated 2 times Dec 27 21:21:23 michelle1 rpc.statd[724]: Received erroneous SM_UNMON request from michelle1.private for 192.168.0.69 Dec 27 21:25:03 michelle1 init: Re-reading inittab Dec 27 21:25:03 michelle1 last message repeated 2 times Dec 28 00:30:25 michelle1 /usr/sbin/gpm[664]: select(): Interrupted system call 8<-- So if the loganalyzer read " sSMTP[" it should use the "ssmtp.mo" file and if it read " rpc.statd" from "nfs-common.mo". I have seenm there is apossibility to get all english strings from an mo file so if you have a message like Dec 27 12:28:08 michelle1 sSMTP[11044]: Unable to set AuthUser="[EMAIL PROTECTED]" the loganalyzer can cut it to sSMTP[11044]: Unable to set AuthUser="[EMAIL PROTECTED]" detect the "sSMTP" program and do a Fuzzy-Search in the ssmtp.mo for "Unable to set " which will probably work since the original String seems to be msgid "Unable to set %s=\"%s\"\n" if it would be localized. > What would you chose? > > Regards > > Javier Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: localisation in system wide daemons
Hi, Am 2006-12-22 03:27:43, schrieb Javier Fernández-Sanguino Peña: > > I can't find anything about this in the policy but to me it > > doesnt make sense to use a locale if you dont want it for > > some programs. > > Why would you *not* want a locale? If the program has l10n support and it > provides messages (even in a non-interactive way) there's chances some users > will benefit from the translated messages. Maybe the package maintainer do not want to get bugreports for his/her package in 100 differns languages? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Downgrading the priority of nfs-utils
Hello Javier, Am 2006-12-22 03:37:54, schrieb Javier Fernández-Sanguino Peña: > On Thu, Dec 21, 2006 at 06:51:58PM +0100, Michelle Konzack wrote: > > No, it works, but since "portmap" is not more (since Sarge) > > installed by default it need arround 60-300 seconds to mount > > but after this time, it is there. > > Are you sure it's not installed? It's Priority: standard so if the user (in > tasksel) selects 'standard' he *will* get the portmapper. What is "tasksel"? :-) I do not need the shit it installs... Only the REAL baseinstall (which under Sarge has already to much packages) compared to Woody and Etch is the hell!) > Not sure right now what happens if he selects another task but, at least in > Sarge, since fam (installed because of dependencies in the GNOME task [1]) > depended on the portmapper it would get installed in that case too. > > From what I see in tasksel's sources, the same should be true for Etch too. > Right? Yes. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: db.debian.org (and related infrastructure) updates
Bastian Blank <[EMAIL PROTECTED]> wrote: > On Sat, Dec 30, 2006 at 05:34:28AM -0800, Ryan Murray wrote: >> * Mail greylisting > What happens with a mail which is delivered to an user with greylisting > enabled and one with it disabled? >> * Mail whitelist >> * Mail RBL list >> * Mail RHSBL list > What happens with this lists for mails which is delivered to more than > one user? Hello, Afaict from reading exim4.conf on master all tests are done after RCPT TO, so for greylisting you get MAIL FROM:<[EMAIL PROTECTED]> 250 OK RCPT TO:<[EMAIL PROTECTED]> 451 greylisted RCPT TO:<[EMAIL PROTECTED]> 250 Accepted DATA [...] and the non-greylist users will usually simply receive the mail immediately. The same thing would apply to DNS-lists tests, rcpt to for enabled acounts is rejected, the others receive the mail. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 05:14:30PM +0100, Francois Petillon wrote: > As we have started to collect stats, out of 1K connections, there are from > 30 to 50 connections that look like sender verify. This is quite low right > now but it could be harmful on big domains if more people use it. Yes. Just like any other large amount of traffic could be harmful on big domains. > you are using someone else ressources to fight spam. That's certainly true. But, come to think of it, using someone else's resources is not really a taboo on the Internet. We all participate in such things, almost constantly. Whenever I make a connection to a site, that site has to spend resources to answer me (even if the answer is a rejection). If I resolve a domain, this takes a toll on the entire DNS infrastructure leading up to the desired domain. I use a search engine, whose crawler bot most probably spent gobs of resources on countless sites in order to get me search results. I suppose we could just go about being unusually thrifty and use only our own resources in anti-spam, but these days even content filtering from SpamAssassin is fairly inadequate without a number of checks in remote databases. I guess the counter-argument could be - all those services are explicitly created in order to voluntarily serve requests, but nobody volunteered their server to answer sender verification requests. Yet, a sender verification request is nothing but a three-command SMTP conversation. If someone puts an SMTP server online, and connects it via DNS, it's not exactly strange that other people talk to it. > Second, spammers may adapt in an annoying way (either they will use > domains who always answer a 2xx to rcpt to, or they will use verified > emails). Some of them actually already do that, all the time, for years now. > >Also, sender verification when seen from the side of the victims is > >indistinguishable from a dictionary attack, and may cause deliverability > >issues to the hosts attempting it. > > I confirm it : we already have blacklisted IPs as they were issuing too > many rcpt-to on not existing emails. These were dued to sender > verifications... You choose to ban those, just like someone else chooses to ban deliveries from unverifiable senders. There's nothing particularly strange there. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Dec 30, Josip Rodin <[EMAIL PROTECTED]> wrote: > Um, that happens if your domain is used in spam to so many different mail > servers and with so many various local parts (so as to avoid caching), > and all that are three-verb SMTP conversations. TBH I've never actually This happens often indeed. > heard of anyone getting DDoS'ed by sender verification attempts, so > I can't really imagine that this is terribly likely to happen. I did. > Besides, in the core, it's silly to call the idea antisocial just because > it can be used in a DDoS. Heck, TCP SYN can be used in a DDoS, and any higher > protocol too, but that doesn't mean they're antisocial, only that they are > prone to abuse by antisocial people. SYNs are a fundamental protocol element which cannot be replaced easily, sender verification is not. -- ciao, Marco signature.asc Description: Digital signature
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 05:34:28AM -0800, Ryan Murray wrote: > * Mail greylisting What happens with a mail which is delivered to an user with greylisting enabled and one with it disabled? > * Mail whitelist > * Mail RBL list > * Mail RHSBL list What happens with this lists for mails which is delivered to more than one user? Bastian -- "... freedom ... is a worship word..." "It is our worship word too." -- Cloud William and Kirk, "The Omega Glory", stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 04:44:06PM +0100, Marco d'Itri wrote: > > > It's sad to see Debian promoting and supporting use of antisocial > > > software. > > There's nothing more anti-social in sender verification than in any other > > similar check - if someone sends mail from an address that cannot be > > delivered to, I don't want to accept it, because I can't deliver a reply to > > them. If they want to talk to me, but won't accept replies from me, who > > exactly is antisocial there? > For a start that sites performing sender verification will partecipate > in a DDoS on the mail infrastructure of domains forged by spammers. > It's just as simple as this. Sender verification is barely less harmful > than C/R schemes and antivirus advertisements^Wnotices. Um, that happens if your domain is used in spam to so many different mail servers and with so many various local parts (so as to avoid caching), and all that are three-verb SMTP conversations. TBH I've never actually heard of anyone getting DDoS'ed by sender verification attempts, so I can't really imagine that this is terribly likely to happen. Besides, in the core, it's silly to call the idea antisocial just because it can be used in a DDoS. Heck, TCP SYN can be used in a DDoS, and any higher protocol too, but that doesn't mean they're antisocial, only that they are prone to abuse by antisocial people. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
Marco d'Itri wrote: For a start that sites performing sender verification will partecipate in a DDoS on the mail infrastructure of domains forged by spammers. As we have started to collect stats, out of 1K connections, there are from 30 to 50 connections that look like sender verify. This is quite low right now but it could be harmful on big domains if more people use it. There are two things I really dislike in sender verification. First, you are using someone else ressources to fight spam. Second, spammers may adapt in an annoying way (either they will use domains who always answer a 2xx to rcpt to, or they will use verified emails). Also, sender verification when seen from the side of the victims is indistinguishable from a dictionary attack, and may cause deliverability issues to the hosts attempting it. I confirm it : we already have blacklisted IPs as they were issuing too many rcpt-to on not existing emails. These were dued to sender verifications... François -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 04:37:15PM +0100, Joerg Jaspert wrote: > I personally would love, if you go and whitelist, that you also > whitelist the following set of hosts: Wouldn't this be useful in the greylistd configuration on master, then? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Dec 30, Josip Rodin <[EMAIL PROTECTED]> wrote: > > It's sad to see Debian promoting and supporting use of antisocial > > software. > There's nothing more anti-social in sender verification than in any other > similar check - if someone sends mail from an address that cannot be > delivered to, I don't want to accept it, because I can't deliver a reply to > them. If they want to talk to me, but won't accept replies from me, who > exactly is antisocial there? For a start that sites performing sender verification will partecipate in a DDoS on the mail infrastructure of domains forged by spammers. It's just as simple as this. Sender verification is barely less harmful than C/R schemes and antivirus advertisements^Wnotices. Also, sender verification when seen from the side of the victims is indistinguishable from a dictionary attack, and may cause deliverability issues to the hosts attempting it. On Dec 30, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > And if you would simply read the mail you would understand that this is > a per-user setting. If you dont like it - dont use it. And if you would simply read the mail you would understand that this is not relevant. -- ciao, Marco signature.asc Description: Digital signature
Re: db.debian.org (and related infrastructure) updates
Hi, On Sat, Dec 30, 2006 at 04:31:12PM +0100, Joerg Jaspert wrote: > - the birthDate field isn't currently available via the mail daemon, >this will be fixed soon. What about gender? How is it specified? with a ldapsearch, I can find 1, 2 and 9... Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On 10884 March 1977, Joerg Jaspert wrote: Hehe, reply to myself, but it didnt really fit for d-d-a. > - If you whitelist hosts - dont bother to whitelist any .debian.org >host, they are automagically whitelisted. I personally would love, if you go and whitelist, that you also whitelist the following set of hosts: smithers.debconf.org cmburns.debconf.org chic.spi-inc.org frida.spi-inc.org That are the main MXs and list servers for DebConf and SPI. (Of course if you don't do stuff with one of that - dont bother). They arent spambots and greylisting wont help you, they will queue and definitely deliver it to you. :) -- bye Joerg I'm James Troup, long term source of all evil in Debian. you may know me from such debian-devel-announce gems as "Serious Problems With " pgpv12uM2sQeP.pgp Description: PGP signature
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 03:32:02PM +0100, Steinar H. Gunderson wrote: > >> I've seen a lot of announcement/verification emails (such as Amazon > >> orders) which go out from an address that does not exist - presumably > >> such emails would be blocked by sender verification? > > Yes. Sender callout verification is basically this: > > Note that the mail in the "From" field can be different from the envelope > given in the SMTP session (which is where a bounce would go). Yes, Exim on master.d.o is currently set up to verify envelope senders. It doesn't verify header senders (although such a thing is also possible). The two addresses may differ. So currently the situation is that if your Amazon order or whathaveyou comes in with a deliverable envelope sender address, but an undeliverable header sender address, it'll go through. (More often than not, however, mails come with both addresses being the same.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 03:27:46PM +0100, Josip Rodin wrote: >> I've seen a lot of announcement/verification emails (such as Amazon >> orders) which go out from an address that does not exist - presumably >> such emails would be blocked by sender verification? > Yes. Sender callout verification is basically this: Note that the mail in the "From" field can be different from the envelope given in the SMTP session (which is where a bounce would go). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 02:10:14PM +, Paul Waring wrote: > I've seen a lot of announcement/verification emails (such as Amazon > orders) which go out from an address that does not exist - presumably > such emails would be blocked by sender verification? Yes. Sender callout verification is basically this: % swaks -q RCPT -f '<>' -t [EMAIL PROTECTED] === Trying master.debian.org:25... === Connected to master.debian.org. <- 220 master.debian.org ESMTP Exim 4.50 Sat, 30 Dec 2006 14:22:32 + -> EHLO keid.carnet.hr <- 250-master.debian.org Hello keid.carnet.hr [161.53.160.10] <- 250-SIZE 62914560 <- 250-PIPELINING <- 250 HELP -> MAIL FROM:<> <- 250 OK -> RCPT TO:<[EMAIL PROTECTED]> <** 550 unknown user -> QUIT <- 221 master.debian.org closing connection % swaks -q RCPT -f '<>' -t [EMAIL PROTECTED] === Trying master.debian.org:25... === Connected to master.debian.org. <- 220 master.debian.org ESMTP Exim 4.50 Sat, 30 Dec 2006 14:22:49 + -> EHLO keid.carnet.hr <- 250-master.debian.org Hello keid.carnet.hr [161.53.160.10] <- 250-SIZE 62914560 <- 250-PIPELINING <- 250 HELP -> MAIL FROM:<> <- 250 OK -> RCPT TO:<[EMAIL PROTECTED]> <- 250 Accepted -> QUIT <- 221 master.debian.org closing connection Based on (an integrated implementation of) that behaviour, Exim makes it possible to reject mails (at SMTP time, not via a bounce), or put the result of the check in a variable an pass it on in a header (where you can e.g. make SpamAssassin score on it). > You could argue perhaps that the people sending out these emails shouldn't > be doing this, or that developers shouldn't be using @debian.org addresses > for that purpose, but it's not quite as clear cut as not being able to > reply means that you don't want to receive an email. Well, as with all automatic anti-spam measures, it's an issue of ratio - whether the number of unverifiable senders that are also spam sufficiently exceeds the number of unverifiable senders that are wanted. For years now, I have observed the latter in negligible ranges. Obviously, YMMV. People who got false positives were instantly notified, and they didn't complain too much. Again, YMMV. BTW, really popular systems that send out gobs of autogenerated legitimate e-mails generally tend to switch to using verifiable addresses because they notice that they can't deliver to people using sender verification. Anyway, the simple fact that this is a matter of choice makes this whole discussion moot - if someone wishes to do it, they can; if they don't, they are perfectly free to avoid it. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
hi [& thanks Ryan for the work] Ryan Murray ha scritto: > The mail gateway, web scripts, and userdir-ldap command line interface have > all been updated to deal with the new fields. I connected to the web interface at https://db.debian.org/update.cgi?id=mennucc1 I found fields for birthdate and Greylisting and Callout, but no fields for RBL and RHSBL and whitelisting a. signature.asc Description: OpenPGP digital signature
Re: db.debian.org (and related infrastructure) updates
On 10884 March 1977, Marco d'Itri wrote: >> * Mail sender verification callouts > It's sad to see Debian promoting and supporting use of antisocial > software. And if you would simply read the mail you would understand that this is a per-user setting. If you dont like it - dont use it. -- bye Joerg LOL die Telefonnummer vom Arbeitsamt Mönchengladbach ist echt 404-0? Soll das nen schlechter Scherz sein? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 05:34:28AM -0800, Ryan Murray wrote: [...] > The mail gateway, web scripts, and userdir-ldap command line interface > have all been updated to deal with the new fields. Thanks Ryan. As usual, you do the right thing. I'm still sad that we all have to wait for you to get sufficient free time slots to do these kinds of things, but hey. I should note that the mail bot is a wee bit too simple when processing the new mailRBL field; I did this: % echo mailrbl sbl.spamhaus.org | gpg --clearsign | mail -s mailrbl [EMAIL PROTECTED] % echo mailrbl list.dsbl.org | gpg --clearsign | mail -s mailrbl [EMAIL PROTECTED] which resulted in only the latter being in the mailRBL field in the LDAP database. It works when both settings are specified in a single batch. I figure it's a consequence of the ldapmodify default changetype being 'replace'. I suppose that's a sane default, but it could still be a bit confusing to people who don't know/notice. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
Josip Rodin wrote: There's nothing more anti-social in sender verification than in any other similar check - if someone sends mail from an address that cannot be delivered to, I don't want to accept it, because I can't deliver a reply to them. If they want to talk to me, but won't accept replies from me, who exactly is antisocial there? I've seen a lot of announcement/verification emails (such as Amazon orders) which go out from an address that does not exist - presumably such emails would be blocked by sender verification? You could argue perhaps that the people sending out these emails shouldn't be doing this, or that developers shouldn't be using @debian.org addresses for that purpose, but it's not quite as clear cut as not being able to reply means that you don't want to receive an email. Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 02:49:20PM +0100, Marco d'Itri wrote: > > * Mail sender verification callouts > It's sad to see Debian promoting and supporting use of antisocial > software. There's nothing more anti-social in sender verification than in any other similar check - if someone sends mail from an address that cannot be delivered to, I don't want to accept it, because I can't deliver a reply to them. If they want to talk to me, but won't accept replies from me, who exactly is antisocial there? There are valid technical arguments against sender callout verification, but what you said is just nonsensical. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Dec 30, Ryan Murray <[EMAIL PROTECTED]> wrote: > * Mail sender verification callouts It's sad to see Debian promoting and supporting use of antisocial software. -- ciao, Marco signature.asc Description: Digital signature
Re: [ITH] eagle-usb
On Tue, Dec 26, 2006 at 09:21:31PM +, Paul Cupis wrote: > I intend to hijack the eagle-usb source package. Please remove s390 from the architectures, it is useless. Bastian -- Our way is peace. -- Septimus, the Son Worshiper, "Bread and Circuses", stardate 4040.7. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405019: ITP: libauthen-simple-smb-perl -- Simple SMB authentication
Package: wnpp Severity: wishlist Owner: Xavier Oswald <[EMAIL PROTECTED]> * Package name: libauthen-simple-smb-perl Version : 0.1 Upstream Author : Christian Hansen <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/C/CH/CHANSEN/Authen-Simple-SMB-0.1.tar.gz * License : GPL Description : Simple SMB authentication This package allow to authenticate against a SMB server. It uses the libauthen-simple-perl framework. -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405011: ITP: ledger -- command-line accounting program
Package: wnpp Severity: wishlist Owner: Trent Buck <[EMAIL PROTECTED]> * Package name: ledger Version : 2.5 Upstream Author : John Wiegley <[EMAIL PROTECTED]> * URL : http://newartisans.com/ledger.html * License : BSD Programming Lang: C++ Description : command-line accounting program Ledger is an accounting tool with the moxie to exist. It provides no bells or whistles, and returns the user to the days before user interfaces were even a twinkling in their father's CRT. What it does offer is a double-entry accounting ledger with all the flexibility and muscle of its modern day cousins, without any of the fat. Think of it as the Bran Muffin of accounting tools. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Wouter Verhelst a écrit : > having one buildd maintainer per arch as opposed > to a team will allow one to faster see recurring obscure problems that > need fixing). That's the theory. The reality shows the exact contrary, at least for arm: - The chroot of "netwinder" is broken for weeks. - "tofee" is loosing packages for weeks. - Some build daemons do not have enough resources to build big packages. Nobody adds those packages to weak_no_auto_build or weak_no_auto_build on those build daemons. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405010: ITP: libauthen-simple-passwd-perl -- Simple Passwd authentication
Package: wnpp Severity: wishlist Owner: Xavier Oswald <[EMAIL PROTECTED]> * Package name: libauthen-simple-passwd-perl Version : 0.6 Upstream Author : Christian Hansen <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/C/CH/CHANSEN/Authen-Simple-Passwd-0.6.tar.gz * License : GPL Description : Simple Passwd authentication This package allow to authenticate against a passwd file. It uses the libauthen-simple-perl framework. -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
#include * Steve McIntyre [Wed, Dec 20 2006, 06:29:04PM]: > Gnome vs. KDE vs. XFCE > == > > The KDE and XFCE variants of CD#1 are now being produced to give more > choice to people for initial installation. By default, CD#1 has always > meant to be enough to install a fully-functioning system, including a I think there should be plenty of space on the XFCE variant. Would it be possible to put some other popular WMs on this CD? According to popcon fluxbox, icewm and wmaker play in the same league as xfwm4. Regards, Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
On Fri, Dec 29, 2006 at 02:24:27PM -0500, Clint Adams wrote: > > I think you're confusing the buildd admin with the porters. I expect > > Maybe that's because the buildd admins used to be the porters, and then, > for some reason I do not understand, this mysteriously stopped being > true. Usually, the porters who initially set up the port did buildd admin stuff too, but then got tired of it and gave it up to the "central" buildd admin team. Since maintaining a buildd host is pretty boring and numb work, I can see why that is; but when this happens, the people actually doing the most work for the port are no longer porters. The only exception to this rule is m68k, where porters are buildd admins and buildd admins are porters. This has its upsides (when there's an issue with the port, people who actually care about the port are told immediately, and are in the ability to do something about it; having a team to maintain a buildd host instead of just one person increases response time to package maintainers), but also its downsides (having a single buildd admin for more than one port will help him to more easily distinguish between an obscure package bug that occurs on more than one architecture and an obscure compiler bug that is architecture-specific and will need fixing; having one buildd maintainer per arch as opposed to a team will allow one to faster see recurring obscure problems that need fixing). Which of the two approaches is best is not an easy question to answer; all I can say is that both approaches seem to work in different situations. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
