Re: greylisting on debian.org?

[Henrique de Moraes Holschuh]

On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
> I don't think I understand just what you're saying.  Can you spell out
> the details for me?  

Does the second email I sent (with the missing stuff) provides the
clarification you asked for?

> It distresses me that I have said twice now that a "solution" which

Read below.  When you do, please remember that many of us consider that a
fully-open system which drowns us in SPAM is also broken, because you do
lose information for failure of locating it among the noise.

> dumb one in my book.  I want a solution which specifically *never*
> needs any preset hardcoded "this set of addresses/domains gets a
> pass".

There is no hardcoding.  Please use more exact terms.  I think I understood
what you wanted to say, but whitelists are not *hardcoded*.  They have never
been, they are updated in runtime.  So use the proper terms next time.

> > In their dumbest form, match using big, static netmasks like 255.255.128.0.
> > That should give you a hint of what I am talking about.
> 
> A hardcoded list is the problem.  Got it?  A loose hardcoded list is
> still a problem.  

What I believe you mean is that for you, a non-perfect solution for
identifying outgoing SMTP clusters is not acceptable, as it gives a non-zero
possibility of permanent delivery failure to a graylisted destination.

Well, there are solutions that are good enough in practice.  If you do not
like them because they are not perfect (as in guaranteed zero fail rate),
then there is no solution I know of that will be acceptable to you.

But please remember that people operating outgoing SMTP clusters *want* to
deliver email, and that they are aware of graylisting practices and also of
the diminishing probability of sucessful delivery when the sending site has
broken DNS configuration, or is listed in popular blackists and dial-up
IP space lists.

Also, keep in mind that the Debian graylisting proposal specifically states
that graylisting is not to be applied to every single incoming connection,
but rather to those coming from broken DNS sources, and blacklisted sources,
which are extremely unlikely to be the class of sending cluster that would
break graylisting in the first place.

So you do NOT need a perfect theorical solution to get zero fail rate in
practice for the proposed graylisting scheme.  You don't get any guarantees
of a zero fail rate, however.

> > Here's what I understood of what you wrote:
> > Alice wants to send email to Bob.  Alice graylists incoming email.  Bob does
> > sender verification trying to email people back before accepting a message.
> >
> > You claim Alice cannot send mail to Bob because Bob will attempt to "almost
> > send email back to Alice", thus Bob's verification attempt will be
> > graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message
> > with a 4xx.
> >
> > If that's not correct, please clarify.
> >
> > If it is correct, I am asking you *why* Alice's system will never let Bob's
> > verification probe through (thus allowing her email to be delivered to Bob).
> 
> Because Bob never sends a complete email message to Alice.

That is a broken graylist implementation, then.  It should be fixed (or
avoided at all costs).  Which graylister was that one?

For graylisting, you need to verify that the sender will retry.  This is not
done through verification of completed email delivery!  It is done as soon
as you got enough information to identify it as the same sender and message.
If the sender will retry, you are to approve him through the graylist
regardless of any delivery taking place.

> > I *can* see a scenario where delivery might never happen (I am ignoring
> > configuration error scenarios on Alice's side), but it depends on Alice also
> > doing the same type of sender verification, and on one or both sides
> > violating RFC 2821.
> 
> Doing sender verification and graylisting are both violations of the
> RFCs.  You can hardly say "this will work as long as everyone else
> follows the RFC" when you aren't doing so yourself.  My point is that

Agreed, you cannot say that.  But nobody did say it.  And the scenario you
experienced for Alice's failure to deliver email to Bob requires a broken
graylisting implementation that acts in a specific *wrong* way, and that was
the answer to my question.

Now, I am a bit annoyed with the "graylisting violates the RFCs" generic
statement, so I'd really appreciate if you could make it more specific.
Please explain how the idea behind graylisting ("force a host to retry a
SMTP transaction at a later time") violates RFC 2821.   RFC 2821, AFAIK,
requires that the sending side deal with that scenario, and anyone who
doesn't deal with it is the one violating the RFC.

There is an issue with current graylisting implementations that *I know of*
(and I certainly am no expert in the area), in that they *will* fail to
recognize shared-queue outgoing clusters in theory, and *may* fail to do so
in practice (depends on suc

ITP: ri-li -- Control a toy wood engine and collect the items

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: ri-li
 Version : 1.0.3
 Upstream Author : Dominique Roux-Serret <[EMAIL PROTECTED]>
  Maf464 <[EMAIL PROTECTED]>
* URL : http://www.ri-li.org
* License : GNU GPL
 Description : Control a toy wood engine and collect the items
This is an arcade game where you control a wooden toy train and
collect items.
.
Homepage: http://www.ri-li.org


-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Andreas Metzler]

Thomas Bushnell BSG  becket.net> writes:
> martin f krafft  debian.org> writes:
[...] 
> It assumes, for example, that the remote MTA will use the same IP
> address each time it sends the message. 
[...]

eh no. Standard greylisting practise nowadays (it already was standard when 
sarge was released) is to not greylist on host IP but at least on the /27 
netblock.

cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Pierre Habouzit]

Le lun 10 juillet 2006 02:17, Matthew R. Dempsky a écrit :
> On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > Another problem is with hosts that do not accept a message from an
> > MTA unless that MTA is willing to accept replies.  This is a common
> > spam prevention measure.
>
> It also prevents mail from setups that use different servers for
> inbound and outbound mail.

which is highly unlikely if you never greylist hosts that are not listed 
in rbl's.

so your reproach is completely irelevant to the suggestion.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgphsQ8uvDkrR.pgp
Description: PGP signature

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> Another way to avoid problems with clusters is to assume certain common
> setup patterns for server farms, like a cheap netmask match.  This does, in
> a way, "require you to know in advance the setup of remote networks", in the
> sense that you need to know the common patterns that will be used.   At
> least now you are dealing with patterns, and not specific instances.

This is not adequate, sorry, at least, not in my book.

I am concerned that you not use a spam-defeating technique which
blocks perfectly legitimate and standards-compliant email.

What I object to is specifically the attempt to create *new*
standards, by blocking legitimate email.  There is no standard
requirement that a server farm use a small netmask or one of a set of
common patterns.  If you want such a requirement, please propose one
to the IETF.  You know how.

Saying "if everyone followed rule X (and heck, lots of people already
do!) my system would work perfectly" is irrelevant to me.  What
matters to me is "my scheme works when everyone follows the actual
public standards for email."

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
>> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>> > You can, for example, use dynamic IP supersets to do the greylisting
>> > "triplet" match.  Now the problem is a matter of creating the supersets in 
>> > a
>> > way to not break incoming email from outgoing-SMTP clusters.
>> 
>> Is there a way of doing this which doesn't require you to know in
>> advance the setup of remote networks and such?  Does it scale?
>
> Yes.  The most absurd way is to consider every non-stolen, valid for the
> public Internet IPv4 netblock as belonging to a single IP superset, and
> flushing the graylisted database often (but mind your outgoing email retry
> policy!).

I don't think I understand just what you're saying.  Can you spell out
the details for me?  

>> > You can also only graylist sites which match a set of conditions that flag
>> > them as suspicious.  Depending on what conditions you set, you do not have
>> > the risk of blocking any server farms we would want to talk SMTP to.
>> 
>> You don't have the risk?  Are you saying that there is exactly *zero*
>> risk?  Please, if you don't mean that, be more precise.
>
> We == Debian.
>
> Server farms we want to talk to == those professionaly run by
> non-botnet-.   We also want to talk to MTAs run by geeks on their
> home connections, but those are *not* outgoing SMTP farms, so they are not
> an issue.

Keeping a list of such server farms is exactly what I meant by a
nonworking pseudo-solution.  I said, specifically, "is there a way of
doing this which doesn't require you to know in advance the setup of
remote networks and such?"  This was the same idea I had already said
in terms of "all I have seen is to...[include] an exactly accurate
hardcoded list of all such sites."  

It distresses me that I have said twice now that a "solution" which
requires a hardcoded list of special sites exempted from the rules is
not a solution I regard as answering my objection.

> Never mind nobody suggested using a dumb, deprecated graylister for @d.o.

Any graylister which requires a specific list of sites counts as a
dumb one in my book.  I want a solution which specifically *never*
needs any preset hardcoded "this set of addresses/domains gets a
pass".

> In their dumbest form, match using big, static netmasks like 255.255.128.0.
> That should give you a hint of what I am talking about.

A hardcoded list is the problem.  Got it?  A loose hardcoded list is
still a problem.  

>> >> Another problem is with hosts that do not accept a message from an MTA
>> >> unless that MTA is willing to accept replies.  This is a common spam
>> >> prevention measure.  The graylisting host cannot then send mail to
>> >> such sites until they've been whitelisted, because when they try the
>> >> reverse connection out, it always gets a 4xx error.  I've been bitten
>> >
>> > Why will the host implementing incoming graylisting *always* get a 4xx 
>> > error
>> > on his outgoing message?  I am curious.
>> 
>> The other way round.
>
> Here's what I understood of what you wrote:
>
> Alice wants to send email to Bob.  Alice graylists incoming email.  Bob does
> sender verification trying to email people back before accepting a message.
>
> You claim Alice cannot send mail to Bob because Bob will attempt to "almost
> send email back to Alice", thus Bob's verification attempt will be
> graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message
> with a 4xx.
>
> If that's not correct, please clarify.
>
> If it is correct, I am asking you *why* Alice's system will never let Bob's
> verification probe through (thus allowing her email to be delivered to Bob).

Because Bob never sends a complete email message to Alice.

> I *can* see a scenario where delivery might never happen (I am ignoring
> configuration error scenarios on Alice's side), but it depends on Alice also
> doing the same type of sender verification, and on one or both sides
> violating RFC 2821.

Doing sender verification and graylisting are both violations of the
RFCs.  You can hardly say "this will work as long as everyone else
follows the RFC" when you aren't doing so yourself.  My point is that
this is a case where two RFC-noncompliant spam pseudo-solutions
interact badly, because each is making up their own new requirements,
not in the RFCs, and those new requirements interact poorly.

If your system causes any RFC-compliant mail to lose, then your system
loses.  So far you have argued at best that you are willing to ignore
the cases where it loses.  Great.  I'm not.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: doc compilations: build-time or pre-built?

[marciotex]

[EMAIL PROTECTED] writes:

> Hi.
>
> My dillema:
>
> 1) compile docs pre-build-time; or
> 2)  compile docs in build-time
>
>
> Pros of 1: < build-time and < Build-Depends
>
> Pros of 2: < diff.gz and unnecessary manual intervention of downstream
> maintainer (me :) )
>
> So, what are best practices about this?

[cut]

Rewriting dillema, after answers: (re)buildability versus maintenance
cost. (Re)buildability wins :). If in doubt, compile build-time
docs. Rebuildability is important per se, since is condition of better
softwares. So, build-time doc compiles is better option (generally).

I'm a newbie and I'm learning. Fix me if I am wrong about something,
please.

Thanks all.

Regards,
-- 
Marcio Roberto Teixeira
___
I use newsreader (nntp). Don't send messages directly to my email, please
 (even replies or follow-ups); keep all threads here and only here. 
^^^

keys: hkp://wwwkeys.pgp.net
 http://marciotex.googlepages.com/keypub_8709626B.asc

home page (building): http://marciotex.googlepages.com

"tchê" Debian/GNULinux user

Porto Alegre - RS - Brasil


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Henrique de Moraes Holschuh]

On Mon, 10 Jul 2006, Henrique de Moraes Holschuh wrote:
> > Is there a way of doing this which doesn't require you to know in
> > advance the setup of remote networks and such?  Does it scale?
> 
> Yes.  The most absurd way is to consider every non-stolen, valid for the
> public Internet IPv4 netblock as belonging to a single IP superset, and
> flushing the graylisted database often (but mind your outgoing email retry
> policy!).
> 
> Another is to 

Argh. I must have deleted part of the message by mistyping in vim and didn't
notice it before sending. Sorry about that.

Another way to avoid problems with clusters is to assume certain common
setup patterns for server farms, like a cheap netmask match.  This does, in
a way, "require you to know in advance the setup of remote networks", in the
sense that you need to know the common patterns that will be used.   At
least now you are dealing with patterns, and not specific instances.

It is not as bad as it sounds.  Small clusters of less than five machines
are not supposed to be an issue (you will graylist-approve the entire
cluster before the retry limit is over for reasonable retry policies).

Large clusters are almost always made of a number of islands of nodes with
IPs close to each other, and graylist-approving different islands will also
work if you don't manage to match all islands as a single set).

Scaling is obviously a problem if you have many incoming SMTP hosts, as the
graylisting knowledge should be shared among all of them.  Other scaling
issues depend on how you calculate the IP sets, but for IP distance like the
above example, it is pratically the same as for dumb graylisting.

-- 
  "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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Henrique de Moraes Holschuh]

On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > You can, for example, use dynamic IP supersets to do the greylisting
> > "triplet" match.  Now the problem is a matter of creating the supersets in a
> > way to not break incoming email from outgoing-SMTP clusters.
> 
> Is there a way of doing this which doesn't require you to know in
> advance the setup of remote networks and such?  Does it scale?

Yes.  The most absurd way is to consider every non-stolen, valid for the
public Internet IPv4 netblock as belonging to a single IP superset, and
flushing the graylisted database often (but mind your outgoing email retry
policy!).

Another is to 

> > You can also only graylist sites which match a set of conditions that flag
> > them as suspicious.  Depending on what conditions you set, you do not have
> > the risk of blocking any server farms we would want to talk SMTP to.
> 
> You don't have the risk?  Are you saying that there is exactly *zero*
> risk?  Please, if you don't mean that, be more precise.

We == Debian.

Server farms we want to talk to == those professionaly run by
non-botnet-.   We also want to talk to MTAs run by geeks on their
home connections, but those are *not* outgoing SMTP farms, so they are not
an issue.

If you graylist only people on DUL and with severily broken DNS, you don't
hit professionaly run SMTP farms like the one for gmail, yahoo, or any other
gigantic email provider.  Chance is not zero, it is very small.  And it is
even smaller if you consider it over a three-days retry window.

Never mind nobody suggested using a dumb, deprecated graylister for @d.o.

> >> So far, all I have seen in response to this particular problem is to
> >> say that "properly configured" includes an exactly accurate hardcoded
> >> list of all such sites on the internet.
> >
> > Then you are hearing differently now.
> 
> What ar the "dynamic IP supersets" you speak of, then?

In their dumbest form, match using big, static netmasks like 255.255.128.0.
That should give you a hint of what I am talking about.

> >> Another problem is with hosts that do not accept a message from an MTA
> >> unless that MTA is willing to accept replies.  This is a common spam
> >> prevention measure.  The graylisting host cannot then send mail to
> >> such sites until they've been whitelisted, because when they try the
> >> reverse connection out, it always gets a 4xx error.  I've been bitten
> >
> > Why will the host implementing incoming graylisting *always* get a 4xx error
> > on his outgoing message?  I am curious.
> 
> The other way round.

Here's what I understood of what you wrote:

Alice wants to send email to Bob.  Alice graylists incoming email.  Bob does
sender verification trying to email people back before accepting a message.

You claim Alice cannot send mail to Bob because Bob will attempt to "almost
send email back to Alice", thus Bob's verification attempt will be
graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message
with a 4xx.

If that's not correct, please clarify.

If it is correct, I am asking you *why* Alice's system will never let Bob's
verification probe through (thus allowing her email to be delivered to Bob).

I *can* see a scenario where delivery might never happen (I am ignoring
configuration error scenarios on Alice's side), but it depends on Alice also
doing the same type of sender verification, and on one or both sides
violating RFC 2821.

-- 
  "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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> You can, for example, use dynamic IP supersets to do the greylisting
> "triplet" match.  Now the problem is a matter of creating the supersets in a
> way to not break incoming email from outgoing-SMTP clusters.

Is there a way of doing this which doesn't require you to know in
advance the setup of remote networks and such?  Does it scale?

> You can also only graylist sites which match a set of conditions that flag
> them as suspicious.  Depending on what conditions you set, you do not have
> the risk of blocking any server farms we would want to talk SMTP to.

You don't have the risk?  Are you saying that there is exactly *zero*
risk?  Please, if you don't mean that, be more precise.

>> So far, all I have seen in response to this particular problem is to
>> say that "properly configured" includes an exactly accurate hardcoded
>> list of all such sites on the internet.
>
> Then you are hearing differently now.

What ar the "dynamic IP supersets" you speak of, then?

>> Another problem is with hosts that do not accept a message from an MTA
>> unless that MTA is willing to accept replies.  This is a common spam
>> prevention measure.  The graylisting host cannot then send mail to
>> such sites until they've been whitelisted, because when they try the
>> reverse connection out, it always gets a 4xx error.  I've been bitten
>
> Why will the host implementing incoming graylisting *always* get a 4xx error
> on his outgoing message?  I am curious.

The other way round.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Henrique de Moraes Holschuh]

On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
> It assumes, for example, that the remote MTA will use the same IP
> address each time it sends the message. If the remote MTA is a big

The earlier *implementations* of greylisting did that, true.  They were
simple-minded at best.

> server farm, with a lot of different hosts that could be processing
> the mail, what is your strategy for preventing essentially infinite
> delay?

You can, for example, use dynamic IP supersets to do the greylisting
"triplet" match.  Now the problem is a matter of creating the supersets in a
way to not break incoming email from outgoing-SMTP clusters.

You can also only graylist sites which match a set of conditions that flag
them as suspicious.  Depending on what conditions you set, you do not have
the risk of blocking any server farms we would want to talk SMTP to.

> So far, all I have seen in response to this particular problem is to
> say that "properly configured" includes an exactly accurate hardcoded
> list of all such sites on the internet.

Then you are hearing differently now.

> Another problem is with hosts that do not accept a message from an MTA
> unless that MTA is willing to accept replies.  This is a common spam
> prevention measure.  The graylisting host cannot then send mail to
> such sites until they've been whitelisted, because when they try the
> reverse connection out, it always gets a 4xx error.  I've been bitten

Why will the host implementing incoming graylisting *always* get a 4xx error
on his outgoing message?  I am curious.

-- 
  "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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

"Matthew R. Dempsky" <[EMAIL PROTECTED]> writes:

> On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
>> Another problem is with hosts that do not accept a message from an MTA
>> unless that MTA is willing to accept replies.  This is a common spam
>> prevention measure.
>
> It also prevents mail from setups that use different servers for inbound 
> and outbound mail.

Yes that's right. This is what happens when people start breaking
protocols in attempts to defeat spam.  This is why I'm against
graylisting.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#377556: ITP: sork-vacation-h3 -- autovacation module for Horde Framework

[Gregory Colpart]

Package: wnpp
Severity: wishlist
Owner: Gregory Colpart (evolix) <[EMAIL PROTECTED]>

* Package name: sork-vacation-h3
  Version : 3.0
  Upstream Author : The Horde Team <[EMAIL PROTECTED]>
* URL : http://www.horde.org/vacation/
* License : Apache License 1.1-like
  Description : autovacation for Horde Framework

 Vacation is the Horde module for setting user e-mail
 "autoresponses" via the vacation mechanism supported by several
 popular mailers.  Vacation provides fairly complete support for
 managing .forward style vacation notices on Sendmail or Courier
 mail based systems via an FTP transport. It also has some
 support for LDAP, Qmail, and Exim SQL based servers.
 

I use Vacation on my personal mail server. You can find beta
packages : http://gcolpart.evolix.net/debian/sork-vacation-h3/
Note that Vacation will probably switch his license to BSD-like
license in next months.


Regards,
-- 
Gregory Colpart <[EMAIL PROTECTED]>  GnuPG:1024D/C1027A0E
Evolix - Informatique et Logiciels Libres http://www.evolix.fr/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: select() to /dev/rtc to wait for clock tick timed out. : a different solution

[Junichi Uekawa]

At Sun, 09 Jul 2006 09:43:49 +0900,
Junichi Uekawa wrote:
> 
> Hi,
> The question I have is how to accomplish this.  It looks like hotplug
> is loading stuff at boot-time, and it's not quite clear as how to make
> it not load rtc.
> 
> I have tried not loading rtc with blacklisting, but apparently that
> makes my system hang after hotplug does its job. Modules set to load
> in modconf seems to get loaded very much later than hotplug.

I worked around the problem with making rtc-dev the built-in driver.


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Matthew R. Dempsky]

On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> Another problem is with hosts that do not accept a message from an MTA
> unless that MTA is willing to accept replies.  This is a common spam
> prevention measure.

It also prevents mail from setups that use different servers for inbound 
and outbound mail.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> Anyway, I'll be interested to hear a summary of their arguments, as
> Christian Perrier requested. I find it hard to imagine how properly
> configured greylisting should cause any problems.

It's a violation of the standard.  It is especially problematic,
because it is a violation against the spirit of being liberal in what
you accept, and conservative in what you require.

It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message. If the remote MTA is a big
server farm, with a lot of different hosts that could be processing
the mail, what is your strategy for preventing essentially infinite
delay?

So far, all I have seen in response to this particular problem is to
say that "properly configured" includes an exactly accurate hardcoded
list of all such sites on the internet.

Another problem is with hosts that do not accept a message from an MTA
unless that MTA is willing to accept replies.  This is a common spam
prevention measure.  The graylisting host cannot then send mail to
such sites until they've been whitelisted, because when they try the
reverse connection out, it always gets a 4xx error.  I've been bitten
by this one before.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Broken applications: Could we be honest?

[Wouter Verhelst]

On Sat, Jul 08, 2006 at 07:23:54PM +0300, Török Edvin wrote:
> Btw, what is the appropriate severity level for a package that doesn't
> work on a certain architecture at all? Is it release critical?

If the architecture is a release candidate, yes.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Bug Tracking System

[Wouter Verhelst]

On Sat, Jul 08, 2006 at 01:02:44AM +0530, Ritesh Raj Sarraf wrote:
> Hi,
> 
> Not trying to start a flame war but can somebody give a convincing
> explanation as to why don't we have a standard BTS ?

Because most "standard" BTSes suck?

> If I need to subscribe to a bug I can't use the web interface.
> The answer you might give is, "Oh! Send am email to
> [EMAIL PROTECTED]"

You can't do any manipulation of bugs through the web interface; the
Debbugs web interface is read-only. If you want a helpful command-line
interface, there's the "bts" script in the "devscrits" package which
will allow you to do a lot of things easily without having to remember
the exact command.

[...]
-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#377551: ITP: libvrb -- Virtual Ring Buffer library

[Székelyi Szabolcs]

Package: wnpp
Severity: wishlist
Owner: "Székelyi Szabolcs" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libvrb
  Version : 0.5.0
  Upstream Author : Philip Howard <[EMAIL PROTECTED]>
* URL : http://vrb.slashusr.org/
* License : LGPL
  Programming Lang: C
  Description : Virtual Ring Buffer library

 The Virtual Ring Buffer (VRB) is an implementation of a character FIFO ring
 buffer. It provides direct access to the buffer so the calling program can
 construct output data in place, or parse input data in place, without the
 extra step of copying data to or from a calling program provided buffer
 area.
 .
 Homepage: http://vrb.slashusr.org/

- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.5
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEsX7JGJRwVVqzMkMRApcRAJ9SvSbBJ35fSgn8EdoReVaFmF6q2wCdGEnb
71Q+uaT8m9Mw/jK1bRDNTs8=
=tOxR
-END PGP SIGNATURE-

Re: Marcelo Magallon (lib3ds maintainer) MIA?

[Miles Bader]

Thanks for the advice; I've sent Marcelo another message, this time
GPG-signed...

-Miles
-- 
"Though they may have different meanings, the cries of 'Ye-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Long blurbs repeated in many package descriptions considered harmful

[Helmut Wollmersdorfer]

Enrico Zini wrote:


While these blurbs are informative, they provide information not
strictly related to the package itself.  As a consequence, if you do
"apt-cache search image" you get all of pike, including irrelevant
things like "pike7.6-public.network.pcap" or
"pike7.6-public.protocols.syslog".


ACK.

Another example is

$ apt-cache search perl | grep php

which results in a long list.

The reason is one and the same paragraph in all(?) PHP-packages:

snip
PHP4 is an HTML-embedded scripting language. Much of its syntax is 
borrowed from C, Java and Perl with a couple of unique PHP-specific 
features thrown in. The goal of the language is to allow web developers 
to write dynamically generated pages quickly.

snap

Helmut Wollmersdorfer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Pierre Habouzit]

Le dim 9 juillet 2006 14:30, Marc Haber a écrit :
> On Sun, 9 Jul 2006 08:14:20 +0200, Christian Perrier
>
> <[EMAIL PROTECTED]> wrote:
> >Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]):
> >> martin f krafft <[EMAIL PROTECTED]> writes:
> >> > This has been brought up. Basically I don't think people were
> >> > opposed to it, but there was noone available to implement it.
> >>
> >> There were people opposed to it, in fact.
> >
> >What were their arguments?
>
> For example, that greylisting puts significant load on systems that
> deliver mail to us, and that it is only a question of time before
> spam zombies retry.

hence a good way to achieve that, is to apply greylisting on hosts that 
do not seem to be a valid SMTP server. good hints are:
 * beeing listed in some RBL's (like 'dynamic IPs' rbls),
 * not having a valid reverse DNS,
 * using very curious EHLO/HELO,
 * ...

all those checks are really cheap, and almost never makes the thing 
greylist really big and well known SMTP's, since it's useless to 
greylist SMTP's anyway, it only makes them unhappy (which is your 
point).

as said a couple of times in that thread, such a policy is already in 
place on alioth with quite a good result IMHO.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQ4d6yU0gxS.pgp
Description: PGP signature

Bug#377546: ITP: schedtools -- Queries/alters process's scheduling policy; supports the -ck kernel patch

[Thibaut VARENE]

Package: wnpp
Severity: wishlist
Owner: Thibaut VARENE <[EMAIL PROTECTED]>

* Package name: schedtools
  Version : 1.2.6
  Upstream Author : Freek 
* URL : http://freequaos.host.sk/schedtool/
* License : GPLv2
  Programming Lang: C
  Description : Queries/alters process's scheduling policy; supports the 
-ck kernel patch

schedtool can be used to query or alter a process' scheduling policy
under Linux. Support for CPU-affinity has also been added and most recently
(re-)nicing of processes. Thus, schedtool is the definitive interface to
Linux's scheduler.

It can be used to avoid skipping for A/V-applications, to lock
processes onto certain CPUs on SMP/NUMA systems, which may be
beneficial for networking or benchmarks, or to adjust nice-levels
of lesser important jobs to maintain a high amount of interactive
responsiveness under high load.

If you don't know about scheduling policies, you probably don't want to
use this program - or learn and read "man sched_setscheduler".

Certain modes (as of this writing: SCHED_IDLE and SCHED_ISO) need a
patched kernel (such as Con Kolivas' -ck patchset, from
http://members.optusnet.com.au/ckolivas/kernel/)

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'testing-proposed-updates'), (90, 
'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-ck1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cdrtools

[Nathanael Nerode]

Eduard Bloch wrote:
>#include 
>* Kevin Bube [Fri, Jul 07 2006, 11:29:21AM]:
>> Eduard Bloch <[EMAIL PROTECTED]> writes:
>> > * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]:
>> 
>> >> * dvdrtools, a fork of the last GPLed version, is in non-free
>> >
>> > Please look at dvdrtools' files, eg. cdrecord.c before claiming that.
>> 
>> What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to
>> me.
>
>Grep for "not.allowed" and decide yourself whether such remarks are
>applicable to the GPL (as applicable in your country).
>
>Eduard.

OK.  Here are the "not allowed" elements in dvdrtools:

First, cdrecord.c:
/*
 * Warning: you are not allowed to modify or to remove
this
 * version checking code!
 */

This is false and unacceptable.  I believe this constitutes an error on the 
part of the dvdrtools upstream maintainer, who thought he'd forked from 
before this was introduced.  I suggest reporting this upstream and seeing if 
there's an earlier version which it can be forked from.

librscg/scsi-remote.c
libscg/scsi-*.c

These are all shim layers for interfacing with different kernels' 
implementations of SCSI.

My suspicion is that the best move would be to replace this library entirely.  
Doesn't the Linux kernel have a fairly clean and reasonable interface to 
CD-ROMs these days?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#359073: Net/RBLClient.pm (postgreyreport)

[Adrian von Bidder]

> On Sun, 09 Jul 2006 21:51, Adrian von Bidder wrote:
  ^
[... package doesn't exist, perhaps somebody on [EMAIL PROTECTED] has time to 
do 
the package? ... ]

On Sunday 09 July 2006 22:17, you wrote:
   ^
> Done.

Now that is what I call response time!  Huge thank you!  And this even 
during the soccer WM finale (congrats to you Italians down there! ;-)

> The package is in the Debian Perl Group's svn repository.
> Could someone please check/upload it?

Sorry, got to go to bed now, so your effort won't bear fruits just now.  
Kinda spoils the fun :-(

cheers
-- vbi

-- 
featured product: the KDE desktop - http://kde.org


pgpcT9GY3x43y.pgp
Description: PGP signature

Re: Alioth Tracker: no correspondence to BTS?

[Roland Mas]

Peter Samuelson, 2006-07-09 21:30:11 +0200 :

> [Toni Mueller]
>> I've just poked around a bit in Alioth for a project I'm working on
>> and found a bug report with a bug number that has no resemblance to
>> anything in BTS, quite contrary to my initial assumption.
>
> Yeah, the sourceforge software includes a primitive bug tracker
> which, as far as I know, people don't really use on alioth.

Some do (the Alioth admins, for a start :-).  Oh, and it's Gforge, not
Sourceforge (which has ceased to be free for years).

>> Imho this would only make sense if integrating these two is hard,
>> and if non-Debian projects are hosted on Alioth (I don't know).
>
> Yeah, I couldn't tell you why that feature is even enabled on
> alioth.

  Because having it available doesn't hurt, and project admins can
enable/disable trackers on their project as they see fit.

> Do people actually use it?  I certainly never check the tracker for
> alioth projects I'm involved with; I just assume people will use the
> Debian BTS instead.

  Some people do use it.  Not many, admittedly: we have a total of
about 3600 tracker items in the database.  But since we have a few
cases of upstream development hosted on Alioth, it makes sense to
offer an alternative to the Debian BTS that not everyone likes.

Roland.
-- 
Roland Mas

Bonjour, je suis un virus de signature.  Propagez-moi dans la vôtre !

Re: Alioth Tracker: no correspondence to BTS?

[Nigel Jones]

On 7/10/06, Frans Pop <[EMAIL PROTECTED]> wrote:

On Sunday 09 July 2006 21:29, Peter Samuelson wrote:
> > I've just poked around a bit in Alioth for a project I'm working on
> > and found a bug report with a bug number that has no resemblance to
> > anything in BTS, quite contrary to my initial assumption.
>
> Yeah, the sourceforge software includes a primitive bug tracker which,
> as far as I know, people don't really use on alioth.

Note that the project admins can disable this (and other) feature.





And if your going to reference non-debian bts bugs around Debian
Community, why not prefix with a U, or an A? (Ubuntu and Alioth
respectively), i.e. U#943242

(Whoops, forgot to CC it, sorry Frans)
--
N Jones


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alioth Tracker: no correspondence to BTS?

[Christian Perrier]

Quoting Peter Samuelson ([EMAIL PROTECTED]):

> Yeah, I couldn't tell you why that feature is even enabled on alioth.
> Do people actually use it?  I certainly never check the tracker for
> alioth projects I'm involved with; I just assume people will use the
> Debian BTS instead.

We (iso-codes maintenance team and, more precisely Tobias Toedter)
discovered that some people reported bugs in the Alioth BTS (or
tracker?) without us even knowing about it..:-)

The action has of course been to re-report these to the Debian BTS
andshut down the feature.

Of course, this makes me think that the feature should indeed be
disabled by default in new projects.


-- 




signature.asc
Description: Digital signature

Re: Alioth Tracker: no correspondence to BTS?

[Frans Pop]

On Sunday 09 July 2006 21:29, Peter Samuelson wrote:
> > I've just poked around a bit in Alioth for a project I'm working on
> > and found a bug report with a bug number that has no resemblance to
> > anything in BTS, quite contrary to my initial assumption.
>
> Yeah, the sourceforge software includes a primitive bug tracker which,
> as far as I know, people don't really use on alioth.

Note that the project admins can disable this (and other) feature.


pgpVsC5sx8YDr.pgp
Description: PGP signature

Re: Alioth Tracker: no correspondence to BTS?

[Peter Samuelson]

[Toni Mueller]
> I've just poked around a bit in Alioth for a project I'm working on
> and found a bug report with a bug number that has no resemblance to
> anything in BTS, quite contrary to my initial assumption.

Yeah, the sourceforge software includes a primitive bug tracker which,
as far as I know, people don't really use on alioth.

> Imho this would only make sense if integrating these two is hard, and
> if non-Debian projects are hosted on Alioth (I don't know).

Yeah, I couldn't tell you why that feature is even enabled on alioth.
Do people actually use it?  I certainly never check the tracker for
alioth projects I'm involved with; I just assume people will use the
Debian BTS instead.


signature.asc
Description: Digital signature

Re: Alioth Tracker: no correspondence to BTS?

[martin f krafft]

also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.07.09.2017 +0200]:
> I've just poked around a bit in Alioth for a project I'm working
> on and found a bug report with a bug number that has no
> resemblance to anything in BTS, quite contrary to my initial
> assumption. Imho this would only make sense if integrating these
> two is hard, and if non-Debian projects are hosted on Alioth (I
> don't know).

A reference would help. Is it maybe an Ubuntu bug?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.


signature.asc
Description: Digital signature (GPG/PGP)

Alioth Tracker: no correspondence to BTS?

[Toni Mueller]

Hello,

I've just poked around a bit in Alioth for a project I'm working on
and found a bug report with a bug number that has no resemblance to
anything in BTS, quite contrary to my initial assumption. Imho this
would only make sense if integrating these two is hard, and if
non-Debian projects are hosted on Alioth (I don't know).

Any comments, please?


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#377527: ITP: liboping -- C library to generate ICMP_ECHO requests

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: liboping
  Version : 0.3
  Upstream Author : Florian Forster <[EMAIL PROTECTED]>
* URL : http://verplant.org/liboping/
* License : GPLv2
  Description : C library to generate ICMP_ECHO requests

liboping is a C library to generate ICMP_ECHO requests (better known as "ping
packets"). It features pinging multiple hosts in parallel using IPv4 or IPv6
transparently. The interface is object oriented.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#377513: ITP: libcam-pdf-perl -- library for PDF manipulation

[Zak B. Elep]

Package: wnpp
Severity: wishlist
Owner: "Zak B. Elep" <[EMAIL PROTECTED]>

* Package name: libcam-pdf-perl
  Version : 1.06
  Upstream Author : Clotho Advanced Media, Inc. <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~clotho/
* License : Dual License (Artistic/GPL)
  Programming Lang: Perl
  Description : library for PDF manipulation

The CAM::PDF library, from Clotho Advanced Media, Inc., provides a
way to read and write PDF documents from within Perl.  In
particular, CAM::PDF is optimized for reading and manipulating
existing PDF documents, offering an alternative to other well-known
PDF manipulation libraries such as PDF::API2 and PDFlib which are
better suited for programmatically creating new PDF documents from
scratch.

CAM::PDF supports the PDF v1.4 format, with the exception of the
"linearized" or "optimized" output format which this library can
only read from, but not write to.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-25-386
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Christian Perrier]

Quoting Marc Haber ([EMAIL PROTECTED]):

> For example, that greylisting puts significant load on systems that
> deliver mail to us, and that it is only a question of time before spam
> zombies retry.


Yep, I know about these arguments but Pierre Habouzit bringed an
interesting enhancement to greylisting by greylisting only systems
that are in some carefully chosen blacklists.

This is what is currently operational on lists.alioth.d.o

I see this as an interesting combination of RBL (which I dislike A LOT
when used alone) and greylisting. It reduced the amount of spam in
Alioth mailing list significantly.




signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[martin f krafft]

also sprach Thijs Kinkhorst <[EMAIL PROTECTED]> [2006.07.09.1622 +0200]:
> Indeed, the current Alioth config only greylists those hosts that have
> some kind of 'problem', like no reverse DNS entry or are featured on
> some kind of RBL.
> 
> Any decent mailserver is allowed right through. Any indecent mailserver
> is told to wait just a little bit, but is still allowed to send its
> mail.

postgrey, for instance, whitelists hosts that have 5 successful
deliveries. In the presence of this option, you can just greylist
*everything*.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
mumlutlitithtrhreeaadededd s siigngnatatuurere


signature.asc
Description: Digital signature (GPG/PGP)

Re: greylisting on debian.org?

[Thijs Kinkhorst]

On Sun, 2006-07-09 at 16:14 +0200, martin f krafft wrote:
> > A far more reasonable solution is to only greylist mail with an
> > unreasonably high spamassassin score. Normal mail I assume generally
> > doesn't score high and is not susceptable to greylisting.
> 
> Sure. Or greylist only when it's from a dynIP address.

Indeed, the current Alioth config only greylists those hosts that have
some kind of 'problem', like no reverse DNS entry or are featured on
some kind of RBL.

Any decent mailserver is allowed right through. Any indecent mailserver
is told to wait just a little bit, but is still allowed to send its
mail.

On Sun, 09 Jul 2006 14:30:33 +0200, Marc Haber wrote:
> and that it is only a question of time before spam zombies retry.

That's not really relevant: if we can block spam now, we should do it
now. Sure, we still need to be looking for new measures for when
greylisting stops to work, but that doesn't exclude using it now in any
way.


Thijs


signature.asc
Description: This is a digitally signed message part

Re: greylisting on debian.org?

[Andreas Metzler]

Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
[...]
> The point was about mailers sending mail to debian. If they receive a
> 4xx they have to queue the mail and retry later. It's cheap for
> debian, but expensive for everyone else.

> A far more reasonable solution is to only greylist mail with an
> unreasonably high spamassassin score. Normal mail I assume generally
> doesn't score high and is not susceptable to greylisting.

Greylisting after DATA sounds like a bad idea to me:

1. The bandwith has already been wasted.
2. The bandwith will be wasted again if the host retries
3. spamassassin is a performance hog, and you'll need to rerun it when
the host retries.

*If* you want to be picky about greylisting use something *cheap*,
e.g.
- greylist only hosts listed on a DNS blacklist.
- Don't greylist on host/sender/receipient triples but check
  network/sender/receipient. And possibly combine this with *not*
  greylisting _any_ sender/receipient tuple iff $host already passed
  greylisting for another sender/receipient tuple. (We already know
  the host to do proper retries, no use in greylisting again.)

> Not that I mind, the amount of spam received via this mailing list is
> so marginal I can hardly imagine people worrying about it.

We are not (only) talking about lists.d.o. primarly but the
[EMAIL PROTECTED] addresses. /These/ gather loads of spam.

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: greylisting on debian.org?

[martin f krafft]

also sprach Martijn van Oosterhout <[EMAIL PROTECTED]> [2006.07.09.1548 +0200]:
> The point was about mailers sending mail to debian. If they receive a
> 4xx they have to queue the mail and retry later. It's cheap for
> debian, but expensive for everyone else.

My point was: even 100 such queued mails are not expensive nowadays
(unless your MTA is crap). If you have more than 100 queued mails
due to greylisting on debian.org, you are either a big provider and
can handle it, or a spammer.

> A far more reasonable solution is to only greylist mail with an
> unreasonably high spamassassin score. Normal mail I assume generally
> doesn't score high and is not susceptable to greylisting.

Sure. Or greylist only when it's from a dynIP address.

> Not that I mind, the amount of spam received via this mailing list is
> so marginal I can hardly imagine people worrying about it.

Your email address doesn't appear to be plastered all over Debian
package control files, changelogs, the bug tracking system, and the
mailing lists. Or at least not as much as some others. I get
somewhere between 200-400 spam messages into my debian.org account
per day.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
*** important disclaimer:
by sending an email to any address, that will eventually cause it to
end up in my inbox without much interaction, you are agreeing that:
 
  - i am by definition, "the intended recipient"
  - all information in the email is mine to do with as i see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. in particular, i may quote it on usenet.
  - i may take the contents as representing the views of your company.
  - this overrides any disclaimer or statement of confidentiality that
may be included on your message.


signature.asc
Description: Digital signature (GPG/PGP)

Re: greylisting on debian.org?

[Martijn van Oosterhout]

On 7/9/06, martin f krafft <[EMAIL PROTECTED]> wrote:

also sprach Marc Haber <[EMAIL PROTECTED]> [2006.07.09.1430 +0200]:
> For example, that greylisting puts significant load on systems
> that deliver mail to us,

I am sorry, I don't buy this argument at all. First, a 4xx is not
"significant load" on any mailer unless you're running some piece of
crap. Sure, when you reach the thousands, even postfix could break
the occasional sweat, but which one server delivers thousands of
messages to continuously new from/rcpt combinations -- because
remember, greylisting caches.


The point was about mailers sending mail to debian. If they receive a
4xx they have to queue the mail and retry later. It's cheap for
debian, but expensive for everyone else.

A far more reasonable solution is to only greylist mail with an
unreasonably high spamassassin score. Normal mail I assume generally
doesn't score high and is not susceptable to greylisting.

Not that I mind, the amount of spam received via this mailing list is
so marginal I can hardly imagine people worrying about it.

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[martin f krafft]

also sprach Thomas Bushnell BSG <[EMAIL PROTECTED]> [2006.07.09.0557 +0200]:
> There were people opposed to it, in fact.

Sure, nobody expected it to be any different. This is Debian, after
all. :)

There will always be opposers. If we let our work be hindered by
them, we're going to stagnate.

Anyway, I'll be interested to hear a summary of their arguments, as
Christian Perrier requested. I find it hard to imagine how properly
configured greylisting should cause any problems.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
no micro$oft components were used
in the creation or posting of this email.
therefore, it is 100% virus free
and does not use html by default (yuck!).


signature.asc
Description: Digital signature (GPG/PGP)

Re: greylisting on debian.org?

[martin f krafft]

also sprach Marc Haber <[EMAIL PROTECTED]> [2006.07.09.1430 +0200]:
> For example, that greylisting puts significant load on systems
> that deliver mail to us,

I am sorry, I don't buy this argument at all. First, a 4xx is not
"significant load" on any mailer unless you're running some piece of
crap. Sure, when you reach the thousands, even postfix could break
the occasional sweat, but which one server delivers thousands of
messages to continuously new from/rcpt combinations -- because
remember, greylisting caches.

> and that it is only a question of time before spam zombies retry.

Yeah sure, which is why some of us wanted greylisting years ago, so
the question of time would have been longer regardless.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"man kann die menschen nur von ihren eigenen meinungen überzeugen."
-- charles tschopp


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#376521: ITP: kwlan -- wpasupplicant frontend for KDE

[Adrian von Bidder]

On Monday 03 July 2006 17:16, Fathi Boudra wrote:
> Hi Reinhard,
>
> > Perhaps you are interested in joining the pkg-wpa team on alioth [1]?
[...]
> There's many K wireless tools but none really perfect maybe
> we can cooperate to have only one good tool nicely integrated with
> wpa_supplicant.

Yodel!

As a user: can we please try to have wireless network profiles etc. stored 
as far away from the gui as possible?  No need for the commandline, gnome, 
KDE, xfce and gnustep wireless applets have their own set of stored 
profiles, when they're using the same backend logic anyway...

(Perhaps this is already the case here, so sorry for bugging you, but in 
general the scenario I describe above is what usually happens.  mobile 
network is still new enough so that maybe this time the mess can be 
avoided...)

cheers
-- vbi

-- 
Error: Problem exists between keyboard and chair.


pgp4G86vYsyAy.pgp
Description: PGP signature

New LSB compliance list of init-scripts and guide for maintainers (SoC 2006)

[Carlos Villegas]

Hi, a list containing the LSB-compliance to runtime dependencies of init 
scripts is now available at 
http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/lsblist.html>. 



It has currently only the desktop task init-script subset for Sid and 
relates each script with a bug report issued to correct the LSB compliance.


Besides, a small guide to make scripts LSB compliant is available at:
http://wiki.debian.org/LSBInitScripts

BTW, I'm working for Debian as part of the google summer of code in the 
project to improve the boot process http://initscripts-ng.alioth.debian.org/soc2006-bootsystem>. For this 
project we use mostly the initscripts-ng-devel mailing list and the IRC 
#pkg-sysvinit.


cheers,

Carlos


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: greylisting on debian.org?

[Marc Haber]

On Sun, 9 Jul 2006 08:14:20 +0200, Christian Perrier
<[EMAIL PROTECTED]> wrote:
>Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]):
>> martin f krafft <[EMAIL PROTECTED]> writes:
>> > This has been brought up. Basically I don't think people were
>> > opposed to it, but there was noone available to implement it.
>> 
>> There were people opposed to it, in fact.
>
>What were their arguments?

For example, that greylisting puts significant load on systems that
deliver mail to us, and that it is only a question of time before spam
zombies retry.

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

Bug#377467: RFH: svn-buildpackage -- helper programs to maintain Debian packages with Subversion

[Eduard Bloch]

Package: wnpp
Severity: normal

I request assistance with maintaining the svn-buildpackage package. My
spare time is exhausted by other things IRL and other more urgent
projects. The codeveloper should ideally be a good perl coder.

The package description is:
 svn-buildpackage (formerly svn-devscripts) contains tools that help to
 automate the task of maintaining Debian packages inside of a Subversion
 repository. They are intended to be used by Debian developers to
 simplify the error-prone actions with the svn, devscripts and
 dpkg-dev utilities.
 .
  - svn-inject: creates the initial directory structure of
 Debian-SVN repository and imports existing packages
  - svn-upgrade: imports upstream changes into the upstream branch and
 updates the Debian trunk directory, merging and tagging as needed
  - svn-buildpackage: wrapper around dpkg-buildpackage,
 exporting/merging/tagging source as needed (similar to
 cvs-buildpackage)
 .
 The package also includes a detailed HOWTO document.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.4
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Another weird tar issue (100 character filenames)

[Ingo Saitz]

On Tue, Jun 27, 2006 at 01:09:40PM +0200, Jeroen van Wolffelaar wrote:
> On Tue, Jun 27, 2006 at 09:07:03AM +0100, Roger Leigh wrote:
> > It sounds like a bug that dpkg is using the old v7 tar format which
> > had that 99 char limitation.s

tar has a fixed-length field for short (upto 100 bytes) filenames which
is not neccessarily null-terminated. Older versions of dpkg did not care
about filenames being exactly 100 bytess long and copied everything
before the next null character (which happenes to be the filemode).

> It looks like this issue returned, the question is whether the bug in
> dpkg was fixed in sarge or not, since by now woody's version of dpkg
> doesn't really matter that much anymore.

The corresponding dpkg-bug is #232025, which was fixed in dpkg 1.10.19,
way before the release of sarge.

Ingo
-- 
print<<''x2,$/
print<<''x2,$/



signature.asc
Description: Digital signature