Re: Bug#215205: language-chooser: Language order shouldn't be alphabetical
On Sun, Oct 12, 2003 at 08:17:06PM -0500, Steve Langasek wrote: > On Sun, Oct 12, 2003 at 02:32:39PM +0100, Dale Amon wrote: > > On Sun, Oct 12, 2003 at 01:56:46PM +0200, Goswin von Brederlow wrote: > > > Dale Amon <[EMAIL PROTECTED]> writes: > > > And if I'm a german living in america? > > > Then you'd go to the normal alphabetical listing just > > as you would have to now, while 99% of the users in > > that TZ had the right language as one of the first > > couple choices. > > And what language will you use to ask the user to indicate their > timezone? ASCII-art world map? -- --- Paul "TBBle" Hampson, MCSE 6th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "If they leave no survivors, where do the stories come from?" -- Capt. Jack Sparrow, "Pirates of the Cariibiean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Anyone interested in libical?
Is anyone interested in adopting libical? It has been orphaned for 193 days (#187030). I wouldn't mind removing it, but mozilla build-depends on it (perhaps this can be changed, tho?). Description: Development environment for libical Libical is an Open Source implementation of the IETF's iCalendar Calendaring and Scheduling protocols. (RFC 2445, 2446, and 2447). It parses iCal components and provides a C API for manipulating the component properties, parameters, and subcomponents. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server
On Mon, 13 Oct 2003 00:02:47 -0400
Joe Drew <[EMAIL PROTECTED]> wrote:
> David B Harris wrote:
>
> > As much as you may dislike it, people care about toolkit. I don't
> > understand the witch-hunt to remove references to such things.
>
> Short description is a limited resource. By all means, put GTK or GNOME
> in the long description if it is deemed necessary; apt searches will
> still find what you're looking for.
Obviously if the short description is too long, something needs to go -
and in that case, certainly not mentioning the toolkit is reasonable.
However, in this particular case ("gtk/gnome client for masqdialer
server", but really "gnome client for masqdialer" since the "gtk" is
assumed when talking about GNOME) is 35 characters long.
If you think 35 characters is too long, feel free to start filing
thousands and thousands of bugs on all the other packages, suggesting
that they remove little bits and pieces.
pgpJg5QyDch8o.pgp
Description: PGP signature
Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server
On Mon, 13 Oct 2003 01:44:57 -0400
David B Harris <[EMAIL PROTECTED]> wrote:
> Obviously if the short description is too long, something needs to go -
> and in that case, certainly not mentioning the toolkit is reasonable.
> However, in this particular case ("gtk/gnome client for masqdialer
> server", but really "gnome client for masqdialer" since the "gtk" is
> assumed when talking about GNOME) is 35 characters long.
>
> If you think 35 characters is too long, feel free to start filing
> thousands and thousands of bugs on all the other packages, suggesting
> that they remove little bits and pieces.
(And if you don't, please don't bother people about it - instead file a
bug on Policy asking for the short description guidelines to
specifically say "do not mention the application's toolkit".)
pgpbH15Uf0TrV.pgp
Description: PGP signature
Re: Anyone interested in libical?
* Martin Michlmayr wrote: > Is anyone interested in adopting libical? It has been orphaned for > 193 days (#187030). I wouldn't mind removing it, but mozilla > build-depends on it (perhaps this can be changed, tho?). Mozilla builds fine without libical. -- - nobse
Re: 2.5 IPsec kernel patch: orphaning the grsecurity patch
Hi, martin f krafft wrote:
> Herbert gets to pollute the kernel-source all he wants because
> apparently noone gives a flying food.
Disagree. Some people, myself among them, have stated their unhappiness.
To me personally, though, it doesn't matter that much. I'd rather spend
the time on gettng 2.6 release-ready.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"I'm a creationist; I refuse to believe that I could have evolved from man."
Re: Packaging sysfsutils: static library?
Hi! On 2003-10-13 1:45 +0200, Marco d'Itri wrote: > BTW, I may have been missing something as I did not read the beginning > of this thread, but I don't see the point of packaging sysfsutils: It is a separate upstream package. > as it's part of the udev source package Well, they copied the library to udev because the upstream package does not provide a shared library yet. But the utilities (lsusb and sysfstool) and its documentation aren't part of udev. Maybe these two upstream packages will be merged in the future. > (which I ITP'ed some weeks ago) Am I missing something? bugs.d.o/wnpp does not contain the word 'udev' and only once 'sysfs' (#215257, the ITP I'm talking about). I also cannot find your name in wnpp. > it will be uploaded to the archive by me when it will be actually > useful for something. In the meantime I also prepared a package, including manpages and everything, since it is useful already in the sense that it fulfills its intended meaning (although I won't let it go into sarge). What a timing :-/ I still would be interested in it, but if you already have a package, then I won't stand in the way (although, to be honest, I feel a little bit fooled). But please tell other people about your intents by filing a proper ITP the next time! In the time I created the package I could as well have fixed some other bugs. Okay, maybe we could merge the efforts. IMHO it does not make much sense to have a separate package with lsusb and systool, they could be integrated into the udev package. I can send you all the additional stuff (library documentation, userspace tools and manpages) for inclusion) if you really want to merge the upstream packages. Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: recent spam to this list
Julian Mehnle <[EMAIL PROTECTED]> wrote: > Andreas Metzler wrote: >> Julian Mehnle <[EMAIL PROTECTED]> wrote: >> > It's about forging an e-mail sender's identity. By preventing the >> > unauthorized use of domains as the sender domain of e-mails, most of >> > the practiced cases of identity forgery are prevented. [...] >> If I send an e-mail over mail.nusrf.at with envelope-from >> [EMAIL PROTECTED] I am _not_ forging anything or making >> "unauthorized use of domains" > Yes, you are. The envelope-from address is not a reply-to address, > it's a sender address. If you are sending from mail.nusrf.at, you > are not sending from logic.univie.ac.at. So you should not specify > <[EMAIL PROTECTED]> as the envelope-from address, or you'd > be forging it. No, I am just specifying where I want bounces to go to. MAIL FROM: [SP ] This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors. That is practically all there is in rfc2821 about this issue. cu andreas
Bug#213822: ST Online Antivirus MAIL - pocitacovy virus detekovany! / computer virus detected!
-- ST Online Antivirus MAIL vysledky AV testu -- -- ST Online Antivirus MAIL AV tests resuluts -- ST Online Antivirus MAIL detekoval v mailovej sprave adresovanej do Vasej e-mailovej schranky pocitacovy virus. Odosielatel (sender): [EMAIL PROTECTED] Predmet e-mailu (subject): Newest Net Pack Nazov infikovanej prilohy (file name): (part0004:q988765.exe) Nazov virusu (virus name): Win32/[EMAIL PROTECTED] The file (part0004:q988765.exe) attached to mail (with subject:Newest Net Pack) sent by [EMAIL PROTECTED] to is infected with virus: Win32/[EMAIL PROTECTED] Subor nebolo mozne vyliecit. Cannot clean this file. Subor bol uspesne vymazany. The file was successfully deleted. --- Toto je kopia hlavicky E-mailu: Received: from nqegip (telecom-213-200-84.telecom.sk [213.81.200.84]) by smtp2.stonline.sk (STOnline ESMTP Server) with SMTP id <[EMAIL PROTECTED]>; Mon, 13 Oct 2003 10:10:36 +0200 (MEST) --- this is a copy of the e-mail header: Received: from nqegip (telecom-213-200-84.telecom.sk [213.81.200.84]) by smtp2.stonline.sk (STOnline ESMTP Server) with SMTP id <[EMAIL PROTECTED]>; Mon, 13 Oct 2003 10:10:36 +0200 (MEST) RAV AntiVirus for Linux i386 version: 8.4.2 (snapshot-20030212) Scan engine 8.11 for i386. Last update: Thu, 09 Oct 2003 02:30:25 +02 Scanning for 83249 malwares (viruses, trojans and worms). Tento e-mail bol skontrolovany sluzbou ST Online Antivirus MAIL This e-mail has been scanned by ST Online Antivirus MAIL.
Bug#215522: ITP: aspell-pt-br -- The Brazilian Portuguese dictionary for GNU Aspell
Package: wnpp Version: unavailable; reported 2003-10-13 Severity: wishlist * Package name: aspell-pt-br Version : Upstream Author : * URL : http://people.debian.org/~rafael/br.ispell * License : GPL Description : The Brazilian Portuguese dictionary for GNU Aspell Actually, aspell-pt-br does not represent a new source package, but rather the result of the reorganization of two other packages: aspell-pt and br.ispell. I thought, though, that it would be better to have this reorganization registered somewhere in the Debian BTS, hence this "ITP" announcement. Here is the tale: I was once the maintainer of the ibrazilian package, which is now maintained by Carlos Laviola. I decided to re-adopt it and when I compiled the last (beta) version of the br.ispell source package, I noticed that an aspell word list was generated, which is better than that shipped with the aspell-pt package. In order to have the word list in br.ispell superseding the one in aspell-pt, the development of these two source packages must be coordinated. I approached Brian Nelson (the maintainer of aspell-pt) and he offered the package to me. I prepared an apt-getable repository for the new packages at: http://people.debian.org/~rafael/br.ispell The name of the package was chosen following the language code pt_BR. The name aspell-br would be not appropriate, since br is the code for the Breton language (spoken in Britany, France). If there are no objections, I will soon upload the packages to unstable. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux laboiss0 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US
Re: recent spam to this list
On Mon, Oct 13, 2003 at 12:34:46AM +0200, Tollef Fog Heen wrote: > * Riku Voipio > I have mail-followup-set for a reason. In addition, it is normal > policy on Debian lists not to Cc people unless explicitly requested. Hmm. my mutt setup appears to be b0rken then. sorry about that. need to look that. > I don't want my bounces to go to the wrong place. I don't have root > at all the places I send mail from, nor do I trust all those who have > root there. So, I don't want my mail bounced to the wrong place. So then use a envelope-from from a domain you trust? You said that you use a specific relay to relay your mail already, so you could setup your domain (raw.no) so that only that specific IP is allowed to send mail to the world using raw.no domain? You can still put your university address in the "From: " field like you do right now. > | Second hint: If you insist on your right to forge your email address, > | anyone else can forge your address as well. Is that a right you really > | need? > Uhm, how would you forge your own mail address? It's like forging > your own signature, something which is, by definition not possible: To quote dark: A bad analogy is like an leaky screwdriver. If you have two IP's, one at home ISP and another at work, and you send packets from your home IP using the work IP, you are forging the sender IP, even if you happen to be affiliated with both IP's. > No, I can't. I don't control the DNS of my University, a few of my > ISPs and so on. Nor do I control Debian's DNS. And you don't need to, unless you want to send your bounces to your university or debian servers. Why would you want to do that? One could also argue, that since the university/debian owns the domain, they can setup whatever policy they want on what IP's can send mail in the name of their domain. Lots of opposers seem to assume that domain owners will immediately apply an policy that will force senders to use their mail relays for outgoing mail, without consulting their users first. > | The antipathy against the a POSSIBILITY of a domain owner to restrict > | sending mail in name of his own domain to few IP's is what is silly, > | not the proposal... > It's the wrong solution. And what is the right solution? One that even the blondes using hotmail can use? Just accept it as fact of life that viruses and spam use every now and then your domains? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Fwd: Re: Anyone interested in libical?
Am Mo, den 13.10.2003 schrieb Martin Michlmayr um 07:37: > Is anyone interested in adopting libical? It has been orphaned for > 193 days (#187030). I wouldn't mind removing it, but mozilla > build-depends on it (perhaps this can be changed, tho?). I had a look at it, but upstream seems to be not very active. There are some major problems with it (frequently changing API/ABI without any proper versioning scheme) and since I do not want to do upstream work I dismissed the idea of maintaining it. Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
faster boot
hello there has been a lot of interest lately on tecniques to obtain a faster boot; for example http://www-106.ibm.com/developerworks/linux/library/l-boot.html http://www.fefe.de/minit/ http://www.ussg.iu.edu/hypermail/linux/kernel/0204.0/0674.html http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/ I would be delighted to have a faster boot: my boot times (excluding BIOS) are 60sec-90sec (using the ditributed kernel by Herbert XU), and this is very long (particularly for my Freevo-box) is anyone trying to implement the above in Debian? is anyone interested? a.
Re: Which packages will hold up the release?
Colin Watson wrote: > In the first example, the fact that foo depends on bar while > simultaneously conflicting with the version of bar in the suite you're > looking at is the thing that's bad, because it means foo can't be > installed. The second example is OK, even though foo and bar can't be > installed simultaneously; in an ideal world we might check that one of > them is Priority: extra, but there's a bit too much other stuff going on > for this to be feasible right now. Thank you. > These examples are a bit contrived, but there are certainly real cases > in the archive. My script currently only finds one: - jpilot-backup depends on jpilot >= 0.99.4-1 but testing has 0.99.2-2 - jpilot-backup conflicts with jpilot << 0.99.4-1 but testing has 0.99.2-2 If you know of other cases, I'd appreciate a note so I can examine why my script doesn't find them. -- Björn
Re: faster boot
On Mon, 13 Oct 2003, Andrea Mennucc wrote: > there has been a lot of interest lately on tecniques to obtain a faster > boot; for example > > http://www-106.ibm.com/developerworks/linux/library/l-boot.html > http://www.fefe.de/minit/ > http://www.ussg.iu.edu/hypermail/linux/kernel/0204.0/0674.html > http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/ > > I would be delighted to have a faster boot: my boot times (excluding > BIOS) are 60sec-90sec (using the ditributed kernel by Herbert XU), and > this is very long (particularly for my Freevo-box) > > is anyone trying to implement the above in Debian? > is anyone interested? I was doing so, along with Doug... but I have been quite out of time to play with it lately. However, if you read the paper in http://people.d.o/~hmh, and implement the demultiplexer, we could probably modify one of the above methods to work well, while we implement ours... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: faster boot
On Mon, Oct 13, 2003 at 12:05:24PM +0200, Andrea Mennucc wrote: > I would be delighted to have a faster boot: my boot times (excluding > BIOS) are 60sec-90sec (using the ditributed kernel by Herbert XU), and > this is very long (particularly for my Freevo-box) > > is anyone trying to implement the above in Debian? > is anyone interested? I just hacked /etc/init.d/rcS to start services with the same number after the "S" in parallel, you can find it here: http://sliepen.eu.org/~guus/parallel-rcS - It works without problems, nothing seems to have failed. - I don't see much of a difference (but then again, I have a fast computer). - Unfortunately starting in the background means output of scripts gets lost. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Help needed: builds eating all memory
Adam Majer <[EMAIL PROTECTED]> writes: > On Sat, Oct 11, 2003 at 04:00:34PM +0200, Sam Hocevar wrote: >>My openvrml packages have been failing to build on arm [1], mips [2] >> and mipsel [3] for some time. From the build logs, it looks like g++ is >> eating all the memory and the OOM killer kills it. >> >>What can I do? Ask the buildd admins to add more swap? I would be >> happy to cross-compile the packages (they don't require any arch-specific >> bootstrapping) but I don't have enough hard drive space to build a cross- >> compiler. > > Whatabout removing the -O2 switch? It can save some compilation time and > memory for very large files.. > For very large files, it saves not some, but a lot of memory in my experience for gcc 3.3 -- compiling a ~140K lines generated C file with -O2 even caused my 396MB machine to trash heavily, while -O0 and gcc 3.2 -O2 were ok... Andy -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 This reality is really just a fucked-up dream -- Papa Roach
Bug#215556: ITP: gsysutils -- Set of utilities useful to system administrators
Package: wnpp Severity: wishlist * Package name: gsysutils * URL : http://savannah.gnu.org/projects/sysutils * License : GPL Description : Set of utilities useful to system administrators GNU Sysutils is intended to compliment coreutils. These utilities are ones that are either primarily useful to system administrators, or would need to be installed by a system administrator to be useful (Usually because they require extra priviledges in order to function) Some of these utils superceed existing implementations in Debian, I'll take care to rename them (i.e, add "g" prefix as usual) when that happens. Btw, "sysutils" is taken, so I take "gsysutils". Does someone prefer "gnu-sysutils"? Jeff: - Don't worry, I'll use CDBS. - I ack this is _your_ package, but I want it packaged right now. You'll be in Uploaders in first upload, feel free to put yourself as Maintainer when you like. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux aragorn 2.2.25 #1 Fri Jun 20 19:28:33 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#215556: ITP: gsysutils -- Set of utilities useful to system administrators
On Mon, Oct 13, 2003 at 01:45:07PM +, Robert Millan wrote: > GNU Sysutils is intended to compliment coreutils. These utilities > are ones that are either primarily useful to system administrators, > or would need to be installed by a system administrator to be useful > (Usually because they require extra priviledges in order to > function) > > Some of these utils superceed existing implementations in Debian, I'll take > care to rename them (i.e, add "g" prefix as usual) when that happens. > > Btw, "sysutils" is taken, so I take "gsysutils". Does someone prefer > "gnu-sysutils"? I would, as I associate gsomething with a Gnome-frontend for something (e.g gsudo), but I don't claim that is common conception. BTW is the this project actually alive? There was only activity in CVS from 2003-03-28 (project founded) to 2003-04-16. cu andreas
Bug#213822: ST Online Antivirus MAIL - pocitacovy virus detekovany! / computer virus detected!
-- ST Online Antivirus MAIL vysledky AV testu -- -- ST Online Antivirus MAIL AV tests resuluts -- ST Online Antivirus MAIL detekoval v mailovej sprave adresovanej do Vasej e-mailovej schranky pocitacovy virus. Odosielatel (sender): [EMAIL PROTECTED] Predmet e-mailu (subject): Message Nazov infikovanej prilohy (file name): (part:)->(IFRAME) Nazov virusu (virus name): HTML/IFrame_Exploit*. The file (part:)->(IFRAME) attached to mail (with subject:Message) sent by [EMAIL PROTECTED] to is infected with virus: HTML/IFrame_Exploit* Subor nebolo mozne vyliecit. Cannot clean this file. Subor bol uspesne vymazany. The file was successfully deleted. ST Online Antivirus MAIL detekoval v mailovej sprave adresovanej do Vasej e-mailovej schranky pocitacovy virus. Odosielatel (sender): [EMAIL PROTECTED] Predmet e-mailu (subject): Message Nazov infikovanej prilohy (file name): (part0001:buxmaqx.exe) Nazov virusu (virus name): Win32/[EMAIL PROTECTED] The file (part0001:buxmaqx.exe) attached to mail (with subject:Message) sent by [EMAIL PROTECTED] to is infected with virus: Win32/[EMAIL PROTECTED] Subor nebolo mozne vyliecit. Cannot clean this file. Subor bol uspesne vymazany. The file was successfully deleted. --- Toto je kopia hlavicky E-mailu: Received: from zpcafavm (infovek2-vs-213-81-217-49.telecom.sk [213.81.217.49]) by smtp2.stonline.sk (STOnline ESMTP Server) with SMTP id <[EMAIL PROTECTED]>; Mon, 13 Oct 2003 14:28:25 +0200 (MEST) --- this is a copy of the e-mail header: Received: from zpcafavm (infovek2-vs-213-81-217-49.telecom.sk [213.81.217.49]) by smtp2.stonline.sk (STOnline ESMTP Server) with SMTP id <[EMAIL PROTECTED]>; Mon, 13 Oct 2003 14:28:25 +0200 (MEST) RAV AntiVirus for Linux i386 version: 8.4.2 (snapshot-20030212) Scan engine 8.11 for i386. Last update: Thu, 09 Oct 2003 02:30:25 +02 Scanning for 83249 malwares (viruses, trojans and worms). Tento e-mail bol skontrolovany sluzbou ST Online Antivirus MAIL This e-mail has been scanned by ST Online Antivirus MAIL.
Bug#213822: ST Online Antivirus MAIL - pocitacovy virus detekovany! / computer virus detected!
-- ST Online Antivirus MAIL vysledky AV testu -- -- ST Online Antivirus MAIL AV tests resuluts -- ST Online Antivirus MAIL detekoval v mailovej sprave adresovanej do Vasej e-mailovej schranky pocitacovy virus. Odosielatel (sender): [EMAIL PROTECTED] Predmet e-mailu (subject): Latest Internet Patch Nazov infikovanej prilohy (file name): (part0004:Patch8865.exe) Nazov virusu (virus name): Win32/[EMAIL PROTECTED] The file (part0004:Patch8865.exe) attached to mail (with subject:Latest Internet Patch) sent by [EMAIL PROTECTED] to is infected with virus: Win32/[EMAIL PROTECTED] Subor nebolo mozne vyliecit. Cannot clean this file. Subor bol uspesne vymazany. The file was successfully deleted. --- Toto je kopia hlavicky E-mailu: Received: from uggtpdf (infovek2-vs-213-81-217-49.telecom.sk [213.81.217.49]) by smtp2.stonline.sk (STOnline ESMTP Server) with SMTP id <[EMAIL PROTECTED]>; Mon, 13 Oct 2003 14:26:18 +0200 (MEST) --- this is a copy of the e-mail header: Received: from uggtpdf (infovek2-vs-213-81-217-49.telecom.sk [213.81.217.49]) by smtp2.stonline.sk (STOnline ESMTP Server) with SMTP id <[EMAIL PROTECTED]>; Mon, 13 Oct 2003 14:26:18 +0200 (MEST) RAV AntiVirus for Linux i386 version: 8.4.2 (snapshot-20030212) Scan engine 8.11 for i386. Last update: Thu, 09 Oct 2003 02:30:25 +02 Scanning for 83249 malwares (viruses, trojans and worms). Tento e-mail bol skontrolovany sluzbou ST Online Antivirus MAIL This e-mail has been scanned by ST Online Antivirus MAIL.
RE: recent spam to this list
Andreas Metzler wrote: > Julian Mehnle <[EMAIL PROTECTED]> wrote: > > Andreas Metzler wrote: > > > If I send an e-mail over mail.nusrf.at with envelope-from > > > [EMAIL PROTECTED] I am _not_ forging anything or making > > > "unauthorized use of domains" > > > > Yes, you are. The envelope-from address is not a reply-to address, > > it's a sender address. If you are sending from mail.nusrf.at, you > > are not sending from logic.univie.ac.at. So you should not specify > > <[EMAIL PROTECTED]> as the envelope-from address, or you'd > > be forging it. > > No, I am just specifying where I want bounces to go to. > > MAIL FROM: [SP ] > >This command tells the SMTP-receiver that a new mail transaction is >starting and to reset all its state tables and buffers, including any >recipients or mail data. The portion of the first or >only argument contains the source mailbox (between "<" and ">" >brackets), which can be used to report errors. There you have it. It's the "source mailbox", and while it can be used to report errors, it can *not only* be used to report errors. I'm relieved that the RFC doesn't contradict my common sense understanding of a "sender address".
Re: APT: Errors when replacing syslog by syslog-ng
On Sun, Oct 12, 2003 at 04:54:07PM +0200, Frans Pop wrote: > I just got the following messages replacing syslog by syslog-ng from dselect > (Woody). > Should this be reported as a bug? Against which package (syslog, syslog-ng, > apt)? > > The following packages will be REMOVED: > sysklogd > The following NEW packages will be installed: > syslog-ng > 0 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded. > Need to get 198kB of archives. After unpacking 217kB will be used. > Do you want to continue? [Y/n] > Get:1 http://security.debian.org stable/updates/main syslog-ng 1.5.15-1.1 > [155kB] > Fetched 155kB in 5s (31.0kB/s) > Preconfiguring packages ... > dpkg: sysklogd: dependency problems, but removing anyway as you request: > klogd depends on sysklogd | system-log-daemon; however: > Package sysklogd is to be removed. > Package system-log-daemon is not installed. > Package sysklogd which provides system-log-daemon is to be removed. > anacron depends on sysklogd | system-log-daemon; however: > Package sysklogd is to be removed. > Package system-log-daemon is not installed. > Package sysklogd which provides system-log-daemon is to be removed. > klogd depends on sysklogd | system-log-daemon; however: > Package sysklogd is to be removed. > Package system-log-daemon is not installed. > Package sysklogd which provides system-log-daemon is to be removed. > anacron depends on sysklogd | system-log-daemon; however: > Package sysklogd is to be removed. > Package system-log-daemon is not installed. > Package sysklogd which provides system-log-daemon is to be removed. > (Reading database ... 59235 files and directories currently installed.) > Removing sysklogd ... > Stopping system log daemon: syslogd. > (Reading database ... 59222 files and directories currently installed.) > Preparing to replace nfs-common 1:1.0-2woody1 (using > .../nfs-common_1%3a1.0-2woody1_i386.deb) ... > Unpacking syslog-ng (from .../syslog-ng_1.5.15-1.1_i386.deb) ... > Setting up syslog-ng (1.5.15-1.1) ... > Starting system logging: syslog-ng. > Stopping system logging: syslog-ng. > Starting system logging: syslog-ng. Given that it finished successfully, there's no bug as far as apt is concerned. See, dpkg isn't too happy when you remove one package from a dependency chain, but this is exactly what apt needs to do before putting in another package in its place. So apt tells dpkg to proceed nevertheless, but dpkg still reports it just in case. The doubled restart, on the other hand, is something you should ask the syslog-ng maintainer about. -- 2. That which causes joy or happiness.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 02:47:44PM +0200, Julian Mehnle wrote: > Andreas Metzler wrote: >> Julian Mehnle <[EMAIL PROTECTED]> wrote: >>> Andreas Metzler wrote: If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making "unauthorized use of domains" >>> Yes, you are. The envelope-from address is not a reply-to address, >>> it's a sender address. If you are sending from mail.nusrf.at, you >>> are not sending from logic.univie.ac.at. So you should not specify >>> <[EMAIL PROTECTED]> as the envelope-from address, or you'd >>> be forging it. >> No, I am just specifying where I want bounces to go to. >> MAIL FROM: [SP ] >>This command tells the SMTP-receiver that a new mail transaction is >>starting and to reset all its state tables and buffers, including any >>recipients or mail data. The portion of the first or >>only argument contains the source mailbox (between "<" and ">" >>brackets), which can be used to report errors. > There you have it. It's the "source mailbox", and while it can be > used to report errors, it can *not only* be used to report errors. > I'm relieved that the RFC doesn't contradict my common sense > understanding of a "sender address". I does not confirm it. There is no such thing as "the domain part of the should/has to/must be identical to the domain name of the machine the mail was written on originally", it just states that can be used to report errors to. cu andreas
RE: recent spam to this list
Andreas Metzler wrote: > On Mon, Oct 13, 2003 at 02:47:44PM +0200, Julian Mehnle wrote: > > There you have it. It's the "source mailbox", and while it can be > > used to report errors, it can *not only* be used to report errors. > > I'm relieved that the RFC doesn't contradict my common sense > > understanding of a "sender address". > > I does not confirm it. Confirm what? My common sense understanding of a sender address? Hopefully RFCs wouldn't have to define *everything* they relate to, since common sense already defines a lot of it. Don't you agree on my understanding of a sender address (or source mailbox) being the address (or source mailbox) the sender sends from? If so, please state it explicitly, so I have something I can argue against. :-) > There is no such thing as "the domain part of the > should/has to/must be identical to the domain name of the machine the > mail was written on originally", it just states that > can be used to report errors to. RFC 2821 may not state that. So the cited proposals (like SPF, etc.) were created as proposed amendments to RFC 2821, and *they* do demand that -- for domains that have been configured that way, not for other domains. So where do you see a problem?
Re: Packaging sysfsutils: static library?
On Oct 13, Martin Pitt <[EMAIL PROTECTED]> wrote: >> BTW, I may have been missing something as I did not read the beginning >> of this thread, but I don't see the point of packaging sysfsutils: >It is a separate upstream package. Then feel free to package it, as long as I keep udev I don't mind. :-) Back to the topic, I think you should discuss with the upstream author the reasons for having no shared library. If he is only waiting for a stable ABI then I think you should really keep the library static. >> (which I ITP'ed some weeks ago) >Am I missing something? bugs.d.o/wnpp does not contain the word >'udev' and only once 'sysfs' (#215257, the ITP I'm talking about). I Probably I only sent mail to debian-devel, I was expecting to upload it sooner. -- ciao, | Marco | [2365 acrToiAT0AyME]
Re: recent spam to this list
Julian Mehnle writes: > Don't you agree on my understanding of a sender address (or source > mailbox) being the address (or source mailbox) the sender sends > from? If so, please state it explicitly, so I have something I can > argue against. :-) Mail is not sent from any particular address at all; it is sent by a person or program. It is delivered to one or more addresses. The From: address and SMTP and envelope sender addresses are for human understanding and status reporting. Forgery generally means to create written authorization that shows false provenance. A user who indicates status messages should go to his own address is not forging that address, even if it is not an obvious address given the user's hostname. It probably is useful to perform checks on those addresses, to verify that the administrator of the domain allows the sender to claim an identity under the domain. If such an authorization check fails, forgery is just one possible explanation. Michael
reiser on /, fsck and ro: bug?
hello
I have set up a box that uses reiserfs as the root filesystem
I have noticed 3 facts that seem to be bugs (but I could not tell for sure)
1-
I use a stock kernel by Herbert XU, which uses initrd; when initrd's
/sbin/init is run, eventually it mounts the root from the hard disk, and
it always mounts it read-only, without checking if the kernel option
'ro' was given: is this a bug? what package's bug?
2-
Then /sbin/init is executed from the hard disk, and this calls all
/etc/rcS.d/* that do an fsck on /
When this happens, though, fsck.reiserfs says: "filesystem is mounted
read-only: skipping journal replay": so it seems that the journal will
never be replyed, even if the filesystem is dirty (I am not sure that
this is the case, but I am not willing of doing extensive testing on
this issue).
This is the opposite of what fsck.ext3 would do: AFAIK it does a journal
replay and a fsck ONLY IF the root is mounted read-only.
3-
Then, fsck.reiserfs does a fsck of the disk. Regardless of it being
dirty or not (that is, ignoring the absence of the '-f' flag). This is
another difference with fsck.ext{2,3}. This is a minor bug, but annoying
(it wastes time).
---
problem 2 is the most worrisome.
What is the right boot configuration to avoid it? should I mount / as
read-write?
But (if this is the case) then this cannot be used as a general solution
: ext2 and ext3 cannot be fsck-ed if rw
the problem is also worrisome since debian-installer will be able to
install Debian with a reiserfs partition
a.
Re: [debian-devel] Re: APT: Errors when replacing syslog by syslog-ng
Hi! The doubled restart of syslog-ng is already reported as bug #204631 Will try to sort out RSN. A levelezőm azt hiszi, hogy Josip Rodin a következőeket írta: > On Sun, Oct 12, 2003 at 04:54:07PM +0200, Frans Pop wrote: > > I just got the following messages replacing syslog by syslog-ng from > > dselect > > (Woody). > > Should this be reported as a bug? Against which package (syslog, syslog-ng, > > apt)? [] > > Package sysklogd is to be removed. > > Package system-log-daemon is not installed. > > Package sysklogd which provides system-log-daemon is to be removed. [] > > Unpacking syslog-ng (from .../syslog-ng_1.5.15-1.1_i386.deb) ... > > Setting up syslog-ng (1.5.15-1.1) ... > > Starting system logging: syslog-ng. > > Stopping system logging: syslog-ng. > > Starting system logging: syslog-ng. > > Given that it finished successfully, there's no bug as far as apt is > concerned. See, dpkg isn't too happy when you remove one package from a [] > The doubled restart, on the other hand, is something you should ask the > syslog-ng maintainer about. -- GNU GPL: csak tiszta forrásból
RE: recent spam to this list
Michael Poole wrote: > Julian Mehnle writes: > > Don't you agree on my understanding of a sender address (or source > > mailbox) being the address (or source mailbox) the sender sends > > from? If so, please state it explicitly, so I have something I can > > argue against. :-) > > Mail is not sent from any particular address at all; it is sent by a > person or program. It is delivered to one or more addresses. The > From: address and SMTP and envelope sender addresses are for human > understanding and status reporting. It does very well make sense to specify a "sender address" for an e-mail, and that's exactly what the SMTP "MAIL FROM" command AKA envelope-from (and the "Sender:" header) is meant to be. Even RFCs (2)821 and (2)822 articulate it that way. Nowhere do these RFCs state that the envelope-from can or should be used for status reporting *only*, do they? > Forgery generally means to create written authorization that shows > false provenance. No. You can also forge paintings as well as originator address specifications and other information. Call it counterfeiting, but essentially it's the same thing. > A user who indicates status messages should go to his own address is > not forging that address, even if it is not an obvious address given > the user's hostname. Agreed, but a user indicating a "MAIL FROM: <[EMAIL PROTECTED]>" while sending from a host in the "bar.org" domain is forging the "MAIL FROM" address. > It probably is useful to perform checks on those addresses, to verify > that the administrator of the domain allows the sender to claim an > identity under the domain. If such an authorization check fails, > forgery is just one possible explanation. Generally true, but in part it depends on how you define "forgery".
Re: recent spam to this list
Julian Mehnle writes: > It does very well make sense to specify a "sender address" for an e-mail, > and that's exactly what the SMTP "MAIL FROM" command AKA envelope-from > (and the "Sender:" header) is meant to be. Even RFCs (2)821 and (2)822 > articulate it that way. Nowhere do these RFCs state that the > envelope-from can or should be used for status reporting *only*, do they? If I go to Eau Claire and drop a letter in a letter box am I required to put the address of the box on the letter? Am I forging if I put my Elmwood address on it instead? How about if I go into a library in Eau Claire and send an email? Why should I not put my Elmwood address on it? Of what possible use to anyone would the address of the machine I sent it from be? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: recent spam to this list
Julian Mehnle writes: > Michael Poole wrote: >> Mail is not sent from any particular address at all; it is sent by a >> person or program. It is delivered to one or more addresses. The >> From: address and SMTP and envelope sender addresses are for human >> understanding and status reporting. > > It does very well make sense to specify a "sender address" for an > e-mail, and that's exactly what the SMTP "MAIL FROM" command AKA > envelope-from (and the "Sender:" header) is meant to be. Even RFCs > (2)821 and (2)822 articulate it that way. Nowhere do these RFCs > state that the envelope-from can or should be used for status > reporting *only*, do they? In that context, I think the reasonable interpretation for "sender address" is one that will reach the sender. There need not be a unique valid "sender address" for any person, any role, any host, or any combination of those three -- unless the relevant administrators dictate it. I contend that a from or sender address is forged *only* if that address reaches neither the actual originator nor anyone who delegated that identity to the actual originator. A valid sender may be rejected if they are acting contrary to how their administrator desires them to act -- specifically, if they send email with that address through unauthorized servers. That is a failed authorization check, not a failed forgery check, since you do not know whether the sender is or is not the proper person. [snip] > Agreed, but a user indicating a "MAIL FROM: <[EMAIL PROTECTED]>" while > sending from a host in the "bar.org" domain is forging the "MAIL > FROM" address. That is what I disagree with. You have given no clear argument for that claim -- or even a definition of what 'a host in the "bar.org" domain' means. I assume you mean that the IP resolves using DNS PTR records to a host matching either *.bar.org or bar.org, and that the hostname has a DNS A record that points back to the IP. Forged emails generally have that domain mismatch, but some valid emails share it. For example, my host is "in" the troilus.org domain, and about half of my mail uses the address I send this email from. Most of the rest uses another address, and the remainder is from a third. The latter two refer unambiguously to me and eventually end up in the same mailbox as the rest of my mail, so I do not see why using them in MAIL FROM: should be considered forgery. On the other hand, it is possible for a user to forge an envelope sender to make himself look like another user "in" the same domain. Your naive detection scheme for forgery fails to detect this. >> It probably is useful to perform checks on those addresses, to verify >> that the administrator of the domain allows the sender to claim an >> identity under the domain. If such an authorization check fails, >> forgery is just one possible explanation. > Generally true, but in part it depends on how you define "forgery". Without getting into a debate over semantics, it seems that you define "forgery" in a counter-intuitive way by ignoring ways that real people use protocols: specifically, arguing that SMTP forgery is defined by hostnames rather than user identity. Michael
RE: recent spam to this list
John Hasler wrote: > Julian Mehnle writes: > > It does very well make sense to specify a "sender address" for an > > e-mail, and that's exactly what the SMTP "MAIL FROM" command AKA > > envelope-from (and the "Sender:" header) is meant to be. Even RFCs > > (2)821 and (2)822 articulate it that way. Nowhere do these RFCs state > > that the envelope-from can or should be used for status reporting > > *only*, do they? > > If I go to Eau Claire and drop a letter in a letter box am I required to > put the address of the box on the letter? No, but this again is one of these broken "e-mail vs. real world" analogies. You can't receive mail through such a letter box, but a sender address is inherently meant to be a valid address through which you can be contacted (among other criteria). Sender address forgery is not a serious problem with snail mail, but it is with e-mail. And with e-mail, it is possible to do things that are hardly possible with snail mail, e.g. checking the authenticity of the sender address. An e-mail's sender address domain should (in this regard) better be compared to the stamp of the post office where the letter was accepted. > How about if I go into a library in Eau Claire and send an email? Why > should I not put my Elmwood address on it? You may put your Elmwood address into the From: or Reply-To: fields, but should not specify it as the envelope-from. > Of what possible use to anyone would the address of the machine I sent > it from be? If the sender address (envelope-from) of an e-mail was unforgeable (for a given domain), the sender would be guaranteed to have an account at this domain (and be it only to *send* mail), and any abuse could be reliably traced back to the sender's account (not just to the sending host). That's what address forgers fear.
Re: recent spam to this list
Julian Mehnle writes: > No, but this again is one of these broken "e-mail vs. real world" > analogies. You can't receive mail through such a letter box, but a > sender address is inherently meant to be a valid address through which > you can be contacted (among other criteria). I can no more be contacted via the machine in that library than I can via the letterbox. I go in there, spend five minutes sending an email and leave, expecting any replies or bounces to go to my real address. If my message is bounced to that box or a reply sent there it will vanish without a trace. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Re: APT: Errors when replacing syslog by syslog-ng
>> dpkg: sysklogd: dependency problems, but removing anyway as you request: >> klogd depends on sysklogd | system-log-daemon; however: >> Package sysklogd is to be removed. >> Package system-log-daemon is not installed. >> Package sysklogd which provides system-log-daemon is to be removed. >> anacron depends on sysklogd | system-log-daemon; however: >> Package sysklogd is to be removed. >> Package system-log-daemon is not installed. >> Package sysklogd which provides system-log-daemon is to be removed. >> klogd depends on sysklogd | system-log-daemon; however: >> Package sysklogd is to be removed. >> Package system-log-daemon is not installed. >> Package sysklogd which provides system-log-daemon is to be removed. >> anacron depends on sysklogd | system-log-daemon; however: >> Package sysklogd is to be removed. >> Package system-log-daemon is not installed. >> Package sysklogd which provides system-log-daemon is to be removed. > >Given that it finished successfully, there's no bug as far as apt is >concerned. See, dpkg isn't too happy when you remove one package from a >dependency chain, but this is exactly what apt needs to do before putting in >another package in its place. So apt tells dpkg to proceed nevertheless, >but dpkg still reports it just in case. OK, but why are there _two_ identical messages for both klogd and anacron?
RE: recent spam to this list
John Hasler wrote: > Julian Mehnle writes: > > No, but this again is one of these broken "e-mail vs. real world" > > analogies. You can't receive mail through such a letter box, but a > > sender address is inherently meant to be a valid address through which > > you can be contacted (among other criteria). > > I can no more be contacted via the machine in that library than I can via > the letterbox. I go in there, spend five minutes sending an email and > leave, expecting any replies or bounces to go to my real address. If my > message is bounced to that box or a reply sent there it will vanish > without a trace. Then it's up to the library to decide whether to offer this feature (envelope-from forgery, or call it envelope-from pretendery) or protect its domain from unauthorized use in envelope-froms. Of course the latter option implies restrictions for users like you, but the library is not at all required to implement these restrictions for its domain. I still don't understant why so many people object against the cited proposals... The implementation on the sending side (i.e. the DNS configuration) is entirely optional.
trust
I am Mr. Kolapo Omidire,company secretary/Manager, internal and external services of COMMERCIAL BANK OF AFRICA.I was the accounts officer of late Mr. Alan a national of your country, who used to work with The Nigerian Mining Corporation(NMC) here in Nigeria who was banking with our bank. On the 21st of April 2000, my client, his wife and their only son were involved in a car accident along sagbama express road. All occupants of the vehicle unfortunately lost their lives. Since then I have made several enquiries to your embassy to locate any of my clients extended relatives this has also proved unsuccessful. After these several unsuccessful attempts, I decided to track his last name over the Internet,to locate any member of his family hence I contacted you. I have contacted you to assist in repatriating the assets and Capital valued at USD21.5million left behind by my client before they get confiscated or declared unserviceable by the share holders of this bank ,so that they can share his funds as dividends amongst themselves. The Bank has issued me a notice to provide the next-of-kin or have the account confiscated within the next fourteen official working days, because as at the time of his demise I was his accounts officer(although i have since been promoted to my present position-- company sec.) and ever since I have been unsuccessful in locating the relatives for over 2years now. I seek your consent therefore to present you as the next of kin to the deceased since you have the same last names and from same country so that the proceeds of this account can be paid to you. Therefore, on receipt of your positive response, we shall then discuss modalities for transfer. We shall also discuss what I get as my share. I have all necessary formation and legal documents needed to back you up for the claims. All I require from you is your honest cooperation to enable us see this transaction through. I gurantee that this will be executed under a legitimate arrangement that will protect you and me from any breach of the law, both locally and internationally. I await hearing from you soon. Best regards, Mr. Kolapo Omidire. DO SEND YOUR RESPONSE ALSO TO [EMAIL PROTECTED]
Uploader field in debian/control?
Hi! In the policy manual there is no mention ofthe Uploader field of debian/control. (version 3.6.1.0) In the developers' reference I read: * Add the co-maintainer's correct maintainer name and address to the Uploaders field in the global part of the debian/control file It seemed to me that only the fields explicitly mentioned and those starting with X should be in the control files, but I cannot find it explicitly stated. Did I miss something? -- GNU GPL: csak tiszta forrásból
Re: Packaging sysfsutils: static library?
Hi! On 2003-10-13 15:26 +0200, Marco d'Itri wrote: > >It is a separate upstream package. > Then feel free to package it, as long as I keep udev I don't mind. :-) Okay :-) We only have to get the dependencies right, as long as libsysfs provides only a shared lib, udev should build-depend on it. I will contact you when I switch to a shared library. Agreed? > Back to the topic, I think you should discuss with the upstream author > the reasons for having no shared library. If he is only waiting for a > stable ABI then I think you should really keep the library static. I sent a mail to upstream two days ago, but didn't receive an answer yet. I will wait with uploading (or rather, looking for a sponsor) until I get an answer or run out of patience (maybe after a week of silence). Have a nice day! Martin BTW: No need to CC me, I'm subscribed (see mail-followup-to). -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Hardcoding of .la file paths in .la files
Le dim 12/10/2003 à 03:31, Steve Langasek a écrit : > If I was comfortable that .la files were completely dispensable on > GNU/Linux systems, I wouldn't hesitate to do that, but I'm not. They > *do* provide additional information that's useful to people linking > applications statically; and while we never (rarely) use the static libs > ourselves, policy does require us to ship them in packages, so it makes > sense to also provide the additional glue information in the .la's > whenever possible. When it causes problems for shared libs, though, I > think it's clear which should take precedence. All this additional information can be provided as well by pkg-config, which is much more flexible and doesn't cause random breakages. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Re: Hardcoding of .la file paths in .la files
On Mon, Oct 13, 2003 at 09:02:06PM +0200, Josselin Mouette wrote: > Le dim 12/10/2003 à 03:31, Steve Langasek a écrit : > > If I was comfortable that .la files were completely dispensable on > > GNU/Linux systems, I wouldn't hesitate to do that, but I'm not. They > > *do* provide additional information that's useful to people linking > > applications statically; and while we never (rarely) use the static libs > > ourselves, policy does require us to ship them in packages, so it makes > > sense to also provide the additional glue information in the .la's > > whenever possible. When it causes problems for shared libs, though, I > > think it's clear which should take precedence. > > All this additional information can be provided as well by pkg-config, > which is much more flexible and doesn't cause random breakages. $ pkg-config libgnomecanvas-2.0 --libs -Wl,--export-dynamic -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 $ Hmm, nope, pkg-config can at least cause one of the most popular forms of libtool breakage, which is that applications will be linked unnecessarily against indirect library dependencies, making ABI transitions much more difficult than they should be. It also doesn't even provide a complete list of all the indirect library dependencies, so this pkg-config line will even fail on platforms where libtool will succeed. (E.g., try to statically link a binary using the above list without having to append '-lX11'.) And if you use the pkg-config output as input for a libtool-using application, you'll get double the pleasure. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Simplicity Pattern Co. AutoReply
Hello, I purchased "NEW LOOK HIS & HERS" Pattern # 6307. The front pattern piece for all of the fronts for the tops was missing. I'm going to Wal Mart to get another one, but thought I should let you know what happened. Thank you, Cindy Bulick
Re: Hardcoding of .la file paths in .la files
Le lun 13/10/2003 à 21:36, Steve Langasek a écrit : > > All this additional information can be provided as well by pkg-config, > > which is much more flexible and doesn't cause random breakages. > > $ pkg-config libgnomecanvas-2.0 --libs > -Wl,--export-dynamic -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 > -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 > $ This looks like a broken .pc file. > It also doesn't even provide a complete list of all the indirect library > dependencies, so this pkg-config line will even fail on platforms where > libtool will succeed. (E.g., try to statically link a binary using the > above list without having to append '-lX11'.) And if you use the > pkg-config output as input for a libtool-using application, you'll get > double the pleasure. You're right as for static linking, I thought pkg-config supported --static while it doesn't. Well, maybe it is better that way; I personally feel we should deprecate the whole static linking stuff. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Re: recent spam to this list
On Mon, Oct 13, 2003 at 08:06:33PM +0200, Julian Mehnle wrote: > John Hasler wrote: > > Julian Mehnle writes: > > > No, but this again is one of these broken "e-mail vs. real world" > > > analogies. You can't receive mail through such a letter box, but a > > > sender address is inherently meant to be a valid address through which > > > you can be contacted (among other criteria). > > > > I can no more be contacted via the machine in that library than I can via > > the letterbox. I go in there, spend five minutes sending an email and > > leave, expecting any replies or bounces to go to my real address. If my > > message is bounced to that box or a reply sent there it will vanish > > without a trace. > > Then it's up to the library to decide whether to offer this feature > (envelope-from forgery, or call it envelope-from pretendery) or protect > its domain from unauthorized use in envelope-froms. Of course the latter > option implies restrictions for users like you, but the library is not at > all required to implement these restrictions for its domain. > > I still don't understant why so many people object against the cited > proposals... The implementation on the sending side (i.e. the DNS > configuration) is entirely optional. Probably because systems which expect it and don't see it will do something such as give the message a positive SpamAssassin score. Of course, if you're going to do something that happens to look like what a lot of spammers do, you should probably expect that, just like it's not wise (anymore) to put a lot of !s in your subject, or to use a known open relay, even if you have absolute permission to use it for legitimate email... Really, this just isn't that difficult a concept, even if it doesn't map directly to real world mail. Your identity, as given in various places, is multi-part; both a user part, *and* a domain part. The owners of the domain part are free to set any policy they wish (including "we don't care"), regarding the behavior of people who wish to claim association with them (perhaps the cloest analogy would be fufilling any requirements for using, say, the official Debian name). In fact, the debian.org domain is a very good example. The policies say that you shouldn't use it for a variety of purposes; they could (though I don't think they *should*) also say "due to problems with forged email claiming to be from Debian, all Debian-official email must relay through the following servers: ". For Debian, which has little interest in running relay servers, highly technical users, and a relatively small problem with spam claiming to be from the domain, in general, it isn't worth the annoyance to the users (IMO). For a University, who are very liability-shy, who mostly have users using a single system, and who already run significant outbound relays for most of their users... it may be much more of a win. It's just (another) tool for enforcing policy, like everything in layers 1-7; it can help make certain policies practical, but it cannot decide when or where to make those policies the case. If you don't like the policy someone implements with it, you can complain to them - maybe they'll listen, maybe not. For a lot of us who've been dealing with the load on mailservers for years, I'm sorry, but your individual desire to be able to send mail from anywhere on the planet, claiming to be anyone on the planet, does not (in my policy decisions) outweight my desire to get fewer spams every day. If adding .1 to your SA score for lacking a repudiation protocol, and 3 (or 5, or whatever) for claiming to be from a domain that denies that it origionates mail to the rest of the world from your IP, is enough to help me sort through my mailbox - so be it. If it isn't, I won't use it, and you have nothing to worry about. However, arguments about 'it will make my life harder' apply just as well to things like open relays, and they are the heart of a large number of anti-spam lists, since there is a very high correlation between having it open, and origionating large amounts of spam. Nearly 100%, in fact. If lacking a domain-authorized relay point comes to eventually have the same statistics, you'd better bet that you'll have the same sorts of penalties in spamfilters. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpMt0YodGu7F.pgp Description: PGP signature
Re: Hardcoding of .la file paths in .la files
On Mon, Oct 13, 2003 at 09:44:47PM +0200, Josselin Mouette wrote: > Le lun 13/10/2003 à 21:36, Steve Langasek a écrit : > > > All this additional information can be provided as well by pkg-config, > > > which is much more flexible and doesn't cause random breakages. > > $ pkg-config libgnomecanvas-2.0 --libs > > -Wl,--export-dynamic -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 > > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 > > -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 > > $ > This looks like a broken .pc file. > > It also doesn't even provide a complete list of all the indirect library > > dependencies, so this pkg-config line will even fail on platforms where > > libtool will succeed. (E.g., try to statically link a binary using the > > above list without having to append '-lX11'.) And if you use the > > pkg-config output as input for a libtool-using application, you'll get > > double the pleasure. > You're right as for static linking, I thought pkg-config supported > --static while it doesn't. Well, maybe it is better that way; I > personally feel we should deprecate the whole static linking stuff. In which case, we could easily fix all libtool installations by simply removing the .la files altogether, and we'll never have any more problems with mislinked dynamic executables or libraries. But if we're going to do that, then most of the available pkg-config settings are *still* wrong; in the above instance, the correct answer for dynamic linking is '-Wl,--export-dynamic -lgnomecanvas-2', and lose the other 50 entries on that line. Both of these tools are designed primarily to solve problems that do not affect stock Debian packages. We are not part of their target userbase, and as such, the tools are suboptimal for what we're trying to achieve. -- Steve Langasek postmodern programmer pgplkLF0iQm8T.pgp Description: PGP signature
Re: gltron maintainer MIA
Ari, On Mon, Oct 13, 2003 at 02:17:43PM +1000, Martin Michlmayr wrote: > * Ari Pollak <[EMAIL PROTECTED]> [2003-10-12 17:14]: > > It seems that the Debian gltron maintainer, Gregory J. Oschwald, has > > been MIA for at least a year now. I can't find him anywhere in the > > developers DB, and haven't seen any recent mail activity at all on > > either bugs or mailing lists. I'd like to hijack this > > That's why the package was orphaned in April (Bug #190816). Ben > Armstrong wanted to adopt it, but obviously never did. I assume you > can just take it, but I'm copying Ben to this mail. Be my guest. I had no end of grief with it and gave up. Also, my son *loves* gltron and will be very happy to see bugfixes and new releases. Ben -- ,-. nSLUGhttp://www.nslug.ns.ca [EMAIL PROTECTED] \`' Debian http://www.debian.org[EMAIL PROTECTED] ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
Re: gltron maintainer MIA
Thanks. Sorry for the short notice, I hadn't realized how outdated gltron and the ITAs were until I started getting comments from friends like "gentoo has newer games" and "gltron is so old." Needless to say, it was rather embarassing, especially since the sarge release is tentatively December 1st at the very earliest. On Mon, Oct 13, 2003 at 05:02:46PM -0300, Ben Armstrong wrote: > Ari, > > Be my guest. I had no end of grief with it and gave up. Also, my son > *loves* gltron and will be very happy to see bugfixes and new releases.
Re: Uploader field in debian/control?
Magosányi Árpád <[EMAIL PROTECTED]> wrote: > In the policy manual there is no mention of the Uploader field of > debian/control. (version 3.6.1.0) > In the developers' reference I read: > * Add the co-maintainer's correct maintainer name and address to the > Uploaders field in the global part of the debian/control file > It seemed to me that only the fields explicitly mentioned and those > starting with X should be in the control files, but I cannot find > it explicitly stated. > Did I miss something? | Additional user-defined fields may be added to the source package | control file. Such fields will be ignored, and not copied to (for | example) binary or source package control files or upload control | files. You only need the X-stuff if the "unsupported field" should end up in the package control files. However Uploaders ends up in the dsc file and is not unsupported. Afaict you are right, I'll try to come up with a patch. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: recent spam to this list
Joel Baker writes: > I'm sorry, but your individual desire to be able to send mail from > anywhere on the planet, claiming to be anyone on the planet... What makes you think I want to claim to be "anyone on the planet"? I have a valid domain and I want replies and bounces to go to it. > If adding .1 to your SA score for lacking a repudiation protocol, and 3 > (or 5, or whatever) for claiming to be from a domain that denies that it > origionates mail to the rest of the world from your IP... I have no IP. Outgoing mail from home goes via my ISP's smarthost. Incoming mail goes to his POP server. > If lacking a domain-authorized relay point comes to eventually have the > same statistics, you'd better bet that you'll have the same sorts of > penalties in spamfilters. What do you mean by "a domain-authorized relay point"? It was my understanding that the idea behind SPF was that I would list in the DNS for my domain the IPs that were authorized to send mail claiming to be from my domain. That would be fine with me, but I evidently misunderstood. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: language-chooser: Language order shouldn't be alphabetical
On Sat, Oct 11, 2003 at 11:32:33PM +0100, Jochen Voss wrote: > > > Also, how do you display the names of the continents so that all of your > > non-English-speaking users can understand them? :) > I did not try a fresh install of Debian for a long time. How > do we display the language names now so that all of your > non-English-speaking users can understand them? Would the (...) With a proper map. Make it point & click. That's by far the "easiest" way to make the user choose it. That has the caveat that the d-i has to support graphics (unless somedoby makes a really good ASCII map). Regards Javi pgpwbuBUY6JGh.pgp Description: PGP signature
RE: recent spam to this list
John Hasler wrote: > Joel Baker writes: > > If adding .1 to your SA score for lacking a repudiation protocol, and > > 3 (or 5, or whatever) for claiming to be from a domain that denies > > that it origionates mail to the rest of the world from your IP... > > I have no IP. Outgoing mail from home goes via my ISP's smarthost. > Incoming mail goes to his POP server. Consider your ISP's smarthost's IP address "your IP". It makes no difference. > > If lacking a domain-authorized relay point comes to eventually have > > the same statistics, you'd better bet that you'll have the same sorts > > of penalties in spamfilters. > > What do you mean by "a domain-authorized relay point"? It was my > understanding that the idea behind SPF was that I would list in the DNS > for my domain the IPs that were authorized to send mail claiming to > be from my domain. That would be fine with me, but I evidently > misunderstood. No, you understood it correctly. That's exactly the point.
Re: recent spam to this list
On Mon, Oct 13, 2003 at 04:26:35PM -0500, John Hasler wrote: > Joel Baker writes: > > I'm sorry, but your individual desire to be able to send mail from > > anywhere on the planet, claiming to be anyone on the planet... > > What makes you think I want to claim to be "anyone on the planet"? > I have a valid domain and I want replies and bounces to go to it. If you're doing what these proposals are meant to block - that is, sending email from a random IP on the internet without cryptographic authentication data at the protocol level - then you can claim to be "[EMAIL PROTECTED]" just as easily as you can claim to be your legitimate email. Opening up the ability to do it for legitimate uses opens up the ability to use it for illegitimate ones, as well - and this has a proven (and high) cost. > > If adding .1 to your SA score for lacking a repudiation protocol, and 3 > > (or 5, or whatever) for claiming to be from a domain that denies that it > > origionates mail to the rest of the world from your IP... > > I have no IP. Outgoing mail from home goes via my ISP's smarthost. > Incoming mail goes to his POP server. I'm going to gloss over the utter mistake of your first statement (unless you happen to connect to your mail server over SNA, IPX, or some stranger option), and point out that the second statement automatically removes you - entirely - from the issue at hand. If you're sending your email to your ISP's smarthost, then *it*, not *you*, are what talks to the remote mailserver - and, as such, it's IP (not yours) is what will be checked. So, unless your ISP pulls a boneheaded misconfiguration, either there will be no published policy (that is, anyone can send), or the policy will list that smarthost as authorized. > > If lacking a domain-authorized relay point comes to eventually have the > > same statistics, you'd better bet that you'll have the same sorts of > > penalties in spamfilters. > > What do you mean by "a domain-authorized relay point"? It was my > understanding that the idea behind SPF was that I would list in the DNS for > my domain the IPs that were authorized to send mail claiming to be from my > domain. That would be fine with me, but I evidently misunderstood. Understand that there are five normal situations that cover pretty much all non-pathological sources of email on the Internet today: 1) Private mailserver run by a business, co-op, or highly technical single user (enterprise servers). 2) ISP mailservers (just what they sound like) 3) Normal end-users relaying through their connection ISP (Joe Dialup) 4) Normal end-users relaying through their home ISP, organization, or business (The Road Warrior) 5) Normal end-users delivering directly. Class #1 is generally a "business" account of some sort; it costs more than $19.95/mo, and is expected to be able to send and receive email directly, as a rule. Also, as a rule, they can control their own DNS (either by running a server, or by having update control from whomever they pay to do hosting for their domain). Class #2 is fairly obvious, though the line between "normal business" and "ISP" can blur somewhat if your business has an IT department serving tens of thousands of users. They almost certain run their own DNS servers, and can afford someone compentant to run them. These two classes have a strong business case for needing to send their own email rather than let an ISP handle it for them; they frequently have access through more than one ISP, and can easily (and legitimately) generate hundreds of thousands of emails an hour, which would put an excessive load on the mailservers of an ISP for one customer, if so. Classes 3 appears to be your situation; both this, and class 4, are removed entirely from the question of SPF/RMX/etc, because they relay through their ISP's smarthost (and thus, that smarthost is what will be checked for being allowed to send to a remote site). Class 5 are the people who regularly used to use open relays (instead of smarthosting), and who now want to be able to send emails directly (without having to smarthost). They are the only ones such proposals hamper in any significant way. Your understand above is correct - note that you would list your *ISP's* mailservers (probably the same smarthost you send to as their customer, but possibly others; they would be able to tell you which ones) for your domain, since that's where mail is expected to come from. In fact, if you have something spiffy like Dynamic DNS updates arranged, you can even send directly from your current IP, by updating the DNS to say "This dynamic IP I got is authorized to send email for my domain". What you *won't* be able to do, if the proposals are widely adopted, is to send email claiming to be from "[EMAIL PROTECTED]", unless one of the following things is true: 1) The DNS for turkey.com has no published policy (entries in the DNS for whatever protocol is adopted, saying "only these mailservers can send"). Lacking a polic
Re: Anyone interested in libical?
Hi, > > Is anyone interested in adopting libical? It has been orphaned for > > 193 days (#187030). I wouldn't mind removing it, but mozilla > > build-depends on it (perhaps this can be changed, tho?). > Mozilla builds fine without libical. What does happen, then? Will it still be able to read iCalendar events? Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
Re: faster boot
On Mon, 2003-10-13 at 06:57, Henrique de Moraes Holschuh wrote: > However, if you read the paper in http://people.d.o/~hmh, and implement the > demultiplexer, we could probably modify one of the above methods to work > well, while we implement ours... After hearing your talk about init systems at debconf and reading your paper, I switched an embedded machine from using busybox init to simpleinit from util-linux, which supports 'need', 'provide', etc. It reduced the 70s boot time by approximately 10s. This is potentially an even bigger win on a machine with more than a RAM-based filesystem. -- Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> My weblog doesn't detail my personal life: http://me.woot.net
Re: recent spam to this list
Julian Mehnle writes: > Consider your ISP's smarthost's IP address "your IP". It makes no > difference. It would if the proposed system was unusable by those of us without static IPs, which was the impression I was getting. Evidently that impression was incorrect: good. > No, you understood it correctly. That's exactly the point. If I can configure my domain with a list of IPs from which mail claiming to originate from it must come without having a static IP and without the cooperation of the administrators of those IPs I have exactly what I want. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server
On Mon, 2003-10-13 at 01:47, David B Harris wrote: > > If you think 35 characters is too long, feel free to start filing > > thousands and thousands of bugs on all the other packages, suggesting > > that they remove little bits and pieces. > > (And if you don't, please don't bother people about it - instead file a > bug on Policy asking for the short description guidelines to > specifically say "do not mention the application's toolkit".) I will feel free to comment on ITPs where I feel it's necessary. I haven't got the time to look through every single package's description, though I tend to comment on the description of packages I install where I feel it's necessary. Dependencies tell you whether a given package runs in a given environment. The average user does not give a shit whether the program they are running uses Qt or GTK. (Does your Aunt Tillie reject a Windows program because it uses the Borland win32 toolkit?) The description should talk about the capabilities of a package, not its implementation details. Take these sentences as a set and derive the conclusion, "the description should not mention toolkits." (At least, for applications. It's hard for a toolkit to not mention the toolkit.) A compromise: The fact that the average Debian user might want to know (in a commonly searchable way) whether a program uses a given toolkit is reason enough to place it in the long description, along the lines of "foo is a GNOME application which frobs data especially for Tillie. [etc]" -- Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> My weblog doesn't detail my personal life: http://me.woot.net
Re: recent spam to this list
Joel Baker writes: > I'm going to gloss over the utter mistake of your first statement I am on a dialup with a "dynamic" IP number: I am allowed to borrow a number from my ISP at need. There is no IP number over which I have any administrative control. Thus I have no IP in that I would be unable to implement any system that required control of "my" IP number. > 4) Normal end-users relaying through their home ISP, organization, or > business (The Road Warrior) My ISP does not permit this. It is the only one available to me. > Classes 3 appears to be your situation; both this, and class 4, are > removed entirely from the question of SPF/RMX/etc, because they relay > through their ISP's smarthost (and thus, that smarthost is what will be > checked for being allowed to send to a remote site). I cannot relay through my ISP's smarthost from outside his system. > You smarthost your email to a server configured to handle turkey.com > email, which is presumably listed in the policy, and *it* sends the email > on to the remote site (which then sees it coming from that server, not > you, and will accept it as coming from an approved server). That is how I thought SPF worked. This would be fine with me. However, statements made earlier in this thread seemed to me to imply that the cooperation of the administrators of domains from which mail would be originating would be required. This would be useless to me: I doubt I could get the cooperation of even my ISP, let alone some hospital or library. > If it's a choice between being nice to the people in class 5, and having > a thousand fewer emails a week to sift through in *my* mailbox, they can > take a flying leap. None of them are important enough (right now) that I > want to get their emails *more* than I want to *not* get that many > spams/broken autoresponders/viruses/etc. I get several hundred per day, many indicating that some SOB is sending libelous and obscene spams in my name. If SPF works as it seems I want it ASAP. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: faster boot
In article <[EMAIL PROTECTED]>, Joe Drew <[EMAIL PROTECTED]> wrote: >On Mon, 2003-10-13 at 06:57, Henrique de Moraes Holschuh wrote: >> However, if you read the paper in http://people.d.o/~hmh, and implement the >> demultiplexer, we could probably modify one of the above methods to work >> well, while we implement ours... > >After hearing your talk about init systems at debconf and reading your >paper, I switched an embedded machine from using busybox init to >simpleinit from util-linux, which supports 'need', 'provide', etc. It >reduced the 70s boot time by approximately 10s. Now that sysvinit has been split into 3 packages, it would be possible to replace one part (sysv-rc) with something that does exactly that. Mike. -- Never trust a statistic you didn't fake yourself.
Re: APT: Errors when replacing syslog by syslog-ng
Frans Pop <[EMAIL PROTECTED]> writes: > OK, but why are there _two_ identical messages for both klogd and anacron? Probably once for the real package "sysklogd" and once for the virtual package "system-log-daemon", since the dependencies explicitly list both. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Anyone interested in libical?
Simon Richter wrote: Hi, Is anyone interested in adopting libical? It has been orphaned for 193 days (#187030). I wouldn't mind removing it, but mozilla build-depends on it (perhaps this can be changed, tho?). Mozilla builds fine without libical. What does happen, then? Will it still be able to read iCalendar events? Simon For my mozilla build at least, libmozical.a is built from modified libical sources distributed with mozilla[or at least checked out from mozilla cvs, I am not sure if it is included with the normal source tarball] and included with the build[assuming you have enabled calendar]. I just uninstalled libical and mozilla calendar still seems to work fine for me. pgpgWPUR8aSrl.pgp Description: PGP signature
Re: recent spam to this list
On Mon, Oct 13, 2003 at 06:51:01PM -0500, John Hasler wrote: > Joel Baker writes: > > I'm going to gloss over the utter mistake of your first statement > > I am on a dialup with a "dynamic" IP number: I am allowed to borrow a > number from my ISP at need. There is no IP number over which I have any > administrative control. Thus I have no IP in that I would be unable to > implement any system that required control of "my" IP number. This is not a problem with Dynamic DNS updates. Many places do hosting of DNS domains (only; no web or mail, etc) for absurdly cheap rates ($5/mo in some cases), and allow either DDNS or an automateable webpage to do updates with. > > 4) Normal end-users relaying through their home ISP, organization, or > > business (The Road Warrior) > > My ISP does not permit this. It is the only one available to me. Your ISP probably doesn't permit outbound connections from dialups to port 25 (gee, can't imagine why that might be the case...); it is amazingly rare to find an ISP that actively blocks VPN, IPSEC, *and* SSH traffic, and is still in business, however. Both for bypassing ISP filters, and for security reasons, relaying this way is fairly standard for the Road Warrior sorts (in no small part because it also protects the bare passwords that are still mostly used in POP3/IMAP servers in most situations; yes, I know about IMAP over SSL, but that doesn't do well when you need to coordinate remote salesdroids with local management, and they all use Outlook's calendar stuff to handle it). > > Classes 3 appears to be your situation; both this, and class 4, are > > removed entirely from the question of SPF/RMX/etc, because they relay > > through their ISP's smarthost (and thus, that smarthost is what will be > > checked for being allowed to send to a remote site). > > I cannot relay through my ISP's smarthost from outside his system. Not at all uncommon, though it might be worth trying to convince them to allow you to do *authenticated* relay from outside. Oddly enough, preventing random IPs from relaying is because... spam comes through. > > You smarthost your email to a server configured to handle turkey.com > > email, which is presumably listed in the policy, and *it* sends the email > > on to the remote site (which then sees it coming from that server, not > > you, and will accept it as coming from an approved server). > > That is how I thought SPF worked. This would be fine with me. However, > statements made earlier in this thread seemed to me to imply that the > cooperation of the administrators of domains from which mail would be > originating would be required. This would be useless to me: I doubt I > could get the cooperation of even my ISP, let alone some hospital or > library. *Mail* has an return path that includes domain names (normally). SMTP *sessions* have a source IP. All of the protocols I saw obviously listed on the ASRG page (including at least RMX, SPF, and Vixie's proposal) use the *claimed* domain (which can be anything), and the *actual* source IP (which cannot be forged without having access to the routing hardware in between the machines, at which point you can do damned near anything you want), to decide whether it's kosher. The library's domain is irrelevant, in this case, since you're not claiming a return address in the library's domain. As a real world counterpart: if I sign up for a thousand 'free catalogs', using the address of my next door neighbor and arch nemesis Fred, he will, in fact, probably be deluged under a mountain of advertisements for lawn aeration shoes and crystal healing methods. I can do this from thousands of miles away, in fact; maybe Fred moved to Texas, and this is my long delayed revenge. Now, Fred can ask the post office to stop sending them through (and in fact, they'll probably notice it in the first place) - ISPs do similar things in a lot of cases, today, for their customers. The problem is that rather than being a rare incident of juvenile humor or mild spite, it's a business with a fairly serious amount of money involved. Now, imagine if the folks giving out catalogs had access to a "no mail" database in which Fred could (if he wanted to register at all), say that any attempt to request catalogs that didn't come postmarked by his local post office should be ignored. I can still mailbomb George, who hasn't signed up on the list; there may be ways to send my mail from Fred's local post office (note that the analogy stretches a bit thin on this point), but I can no longer send email from Nome, Alaska claiming to be Fred in Texas wanting catalogs. There are established ways of dealing with folks who are on the road all the time and legitimately might be anywhere in the world, but still want to get catalogs sent to their house; before I started mailbombing Fred, maybe he was fine with just sending them in with no limitations. Now he's tired of it, and it's less time and effort to deal with the hassle of updati
