Re: greylisting on debian.org?

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> So the meaning of 4xx is "temporary local problem".  Sending that when
> you don't have a temporary local problem is a violation, right there.
> Must the standard repeat after every sentence, "oh, and don't lie".

Actually, that's just the error message most MTA's give out.  The RFC
has finer grained meanings for the range of 4xx messages.  Would you be
happier if greylisting gave back a 451 (error in processing)?  This is
factually true - processing began, but one of the preconditions failed.
That is not a lie.

You might want to go back and reread the RFCs about all of this.
Most of what you are saying isn't actually in the RFCs, but is part of
the mythology that has grown up around them.  Try to find 'be liberal in
what you accept ... ' in RFC 2821.  Notice also that local site policy
_always_ trumps the RFC, but with a note to the effect that you _should_
(not must) take care to not violate interoperability when implementing
site policy.  I would argue greylisting doesn't violate interoperability.

But maybe you have another assertion.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

gnucash on alpha

[Thomas Bushnell BSG]

There is a grave bug (#378346) filed against gnucash on alpha which
seems to be quite arch specific.  Mail to the debian-alpha team for
assistance has not been answered (though I have been told that the
team is very small).  Is there someone with access to an alpha that
will look at this bug, and perhaps provide a stack trace?

AFAICT there is no developer alpha machine available at present.

Thomas


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

Re: greylisting on debian.org?

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> Loïc Minier <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
> >> If the anti-spam advocates consistently said "our measures impose
> >> such-and-such a cost, but we think it's worth it", I would be
> >> delighted.
> >
> >  the measures impose a cost, but we think it's worth it
> 
> Can you detail what the cost is for the specific procedures in use on
> Debian's servers?  No, because you are apparently unaware it exists
> already.  But yet, without knowing the cost, you are sure it's worth
> it.  Bah.

The specific cost right now is that we have load averages on master in
excess of 300.  Fairly consistently.

Greylisting promises to ease that load by quite a bit.  It imposes a
small cost: some legitimate mail that doesn't meet whatever criteria is
decided on (rDNS, RBL, whatever) will be delayed.  None will be rejected
by this measure, unless the sending site itself can't be bothered with
RFC compliance.  That doesn't bother me that much.  If it bothers you,
use your non-Debian email address for all your package related work,
and hardly any of your mail will pass through master.

And I notice you still haven't been able to come up with anything
resembling a link for your earlier assertions.  Can we take it as read
that they were, in fact, unfounded?

> >  Can we get greylisting now?
> 
> We have it, duh.  Have you not been paying attention?

We don't have it yet.  Have you not been paying attention?  The only
delay we have now is due to spam clogged queues and load.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

minimizing downtime of a daemon

[Justin Pryzby]

One of the template NM questions is about "how to minimize the
downtime of a daemon during package upgrade (in maintainer scripts)".
ssh does an "/etc/init.d/ssh restart" in postinstall, which (with
luck) means that there will be *no* downtime.  This doesn't seem to be
necessary for allowing ssh upgrades, since running "/etc/init.d/ssh
stop" over an ssh connection doesn't disconnect existing ssh
connections, but only prevents establishing new connections until the
next "start".  This is different from how everybody else seems to do
it, but does accomplish the goal.

But, Debian doesn't seem to do actively persue this goal.  Of course,
apt-get install  should always work, and really
minimize the downtime, but doesn't solve the general problem for the
dist-upgrade case, or for apt-get install , where it
would be a small pain to have to figure out which packages are running
daemons.

The service isn't actually guaranteed to work during the upgrade
anyway, even if it isn't stopped, due to the potential for
inconsistencies between files on disk (eg. changed config file format,
reread at each connection by a daemon child process, or interrelated
files).

Packages using debhelper dh_installinit end up with an
"/etc/init.d/foo stop" in prerm and an "/etc/init.d/foo start" in
postinst .  During eg. a dist-upgrade, a maximal number of packages
are "dpkg --unpack"ed, and afterwards are "dpkg --configure"d.  This
decidedly does *not* minimize daemon downtime, since it allows an
arbitrarily large number of packages to be unpacked and configured
before the daemon is restarted.

debhelper intends to do what's needed with a simple interface.  If it
was acceptable to require more package-specific information, it would
be possible to only stop the service if it wasn't provided by the new
version of the package.  (Since binary packages with multiple daemons
are uncommon, it is more realistic to think of the same scenario with
info documents, which also get registered in postinst, and
deregistered in prerm).  debhelper would then need an interface to
specify that a daemon was included in certain previous versions of the
package, and removed at some critical versions.  Or, versions in which
a daemon is removed (and versions between that version and the next
stable release) could be required to have custom, not-generated
maintscripts.  This is an uncommon problem for daemons, but removal of
info documents is much more frequent, and presents the same trouble.

The implementation would involve the following in preinst (*not*
prerm, since it may not be known in advance that those files/daemons
would be removed):

ver_removed=1.2-3
( [ "$1" = "install" ] || [ "$1" = "upgrade" ] ) &&
dpkg --compare-versions "$2" lt $ver_removed &&
deregister_info && stop_server && ...
# postrm abort-[install|upgrade] should re-register them, and restart
# the server.

With this code, the info document and server will always be available
*during* upgrades of earlier versions, since dpkg uses an atomic
rename().  Upgrading to the critical version correctly stops the
server and deregisters the document *before* it is removed.

I'm particularly interested in this question since I'm writing a
document about dpkg, and, in particular, about use of maintainer
scripts.  I'm going through NM, and (so far) haven't been asked about
this.  If you don't want to spoil the fun for other NM's, you might
reply to me personally, or think of the same question phrased in terms
of info documents and dh_installdocs instead of daemon's and
dh_installinit.

Justin


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

lilypond and python

[Thomas Bushnell BSG]

I have been criticized for not uploading the new lilypond packages and
being quite a bit behind the public releases.  Unfortunately, the
current lilypond requires python 2.4, and expects to call it as
"python", not just in the build process, but at run time.

I had been assuming that the python team was telling me the truth when
they said that python-defaults would be updated to 2.4 very soon.
Indeed, the relevant wishlist bug on python 2.4 has been marked
"pending" for some time now, which seems to be not quite the truth.
Perhaps it's not a lie, but I have no way to judge and have been
stymied by the utter lack of responsiveness by the python team in
response to queries.

If the python team had told me, months ago, that it would be months
before python-defaults was updated, I would have then begun work on a
workaround for lilypond.  But I was trusting that it was really a
quick matter, at least, that's what people told me.  Unfortunately,
the python-defaults maintainer ignores all mail on the subject.

So, let me make plain: I am entirely happy to accept a workaround
patch for lilypond's current upstream stable release that will make it
build and use python 2.4 even when that is not installed as "python".
If such a functional patch appears and is mailed to the appropriate
lilypond bug, it would immediately become a high priority matter for
me to upload it.  I have wanted to do so for months.

But I don't alas, have the time to spend on a workaround patch myself,
which will (supposedly) become obselete very quickly.

Thomas


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

Re: Congrats to the ftpmasters

[Gustavo Franco]

On 7/18/06, Nathanael Nerode <[EMAIL PROTECTED]> wrote:

The NEW queue is down to *22* packages, which is totally unheard of.
Only three packages have been waiting longer than a month -- so
Javier's package is no longer in the 'endless wait' state.

At the same time, the RM bugs are in fairly good shape, and clearly
removals are also being processed pretty well.  Meanwhile,
infrastructure work appears to still be progressing.  (The substantial
bugs are all very new.)

Impressive.  :-)

As an aside, bug 248043 looks fixed to me, so I closed it.  :-)



Yes, i blogged about this a week ago. Congrats to the ftpmaster,
assistants and the other people involved in this again!

thanks,
-- stratus


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

Re: Congrats to the ftpmasters

[Ross Burton]

On Tue, 2006-07-18 at 16:57 -0400, Nathanael Nerode wrote:
> The NEW queue is down to *22* packages, which is totally unheard of.
> Only three packages have been waiting longer than a month -- so
> Javier's package is no longer in the 'endless wait' state.

Agreed, I've uploaded three new packages in the last fortnight, and all
of them were in the archive by the next day.  Yay ftpmasters!

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



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

Re: Bits from the Package Tracking System

[Gustavo Franco]

On 7/18/06, Denis Barbier <[EMAIL PROTECTED]> wrote:

On Tue, Jul 18, 2006 at 05:33:45PM -0300, Gustavo Franco wrote:
> On 7/18/06, Denis Barbier <[EMAIL PROTECTED]> wrote:
> >On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> >> Hello everybody,
> >>
> >> here are some news about the latest changes made to the Package Tracking
> >> System.
> >>
> >> New derivatives keyword
> >> ---
> >>
> >> The PTS will be used to relay informations from derivative distributions.
> >> Therefore, a new keyword "derivatives" has been implemented. By default,
> >a
> >> PTS subscriber won't receive the messages associated to this keyword
> >> unless he has already manually activated the "cvs" keyword (i.e. the set
> >> of users having the "derivatives" keyword has been initialized as the
> >set of
> >> users having the "cvs" keyword because those people can read patches and
> >> are most probably interested in them).
> >
> >So by default it is assumed that I should make Ubuntu's work and dig
> >into these patches to see if some pieces should be applied into Debian?
> >No thanks, I am getting tired of all those Debian developers who are
> >more interested in improving Ubuntu than Debian, and just added the
> >following rules to my .procmailrc:
> >[...]
>
> No, this is just a service. If you want to dig into these patches, you
> need to subscribe, otherwise you can live without them like you did
> until now, didn't you?

No, I have to unsubscribe, this is exactly what upsets me.  There are
also cases where messages will be sent to lists, like
  http://lists.debian.org/debian-dpkg/2006/07/msg00021.html
So my procmail rule is the best option.


I think you were subscribed using the 'cvs' keyword, right?

cvs
   CVS commit notifications, if the package has a CVS repository and
the maintainer has set up forwarding commit notifications to the PTS.

Source: 
http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-pkg-tracking-system

If it's ok for you "dig into these patches" that you or somebody else
(other maintainer) is forwarding to the PTS but not dig into patches
coming from derivatives, i'm sorry but you will need to unsubscribe.
The intention was the best possible, really.

regards,
-- stratus


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

Congrats to the ftpmasters

[Nathanael Nerode]

The NEW queue is down to *22* packages, which is totally unheard of.
Only three packages have been waiting longer than a month -- so
Javier's package is no longer in the 'endless wait' state.

At the same time, the RM bugs are in fairly good shape, and clearly
removals are also being processed pretty well.  Meanwhile,
infrastructure work appears to still be progressing.  (The substantial
bugs are all very new.)

Impressive.  :-)

As an aside, bug 248043 looks fixed to me, so I closed it.  :-)


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

Re: Bits from the Package Tracking System

[Matthew Garrett]

Denis Barbier <[EMAIL PROTECTED]> wrote:

> So by default it is assumed that I should make Ubuntu's work and dig
> into these patches to see if some pieces should be applied into Debian?
> No thanks, I am getting tired of all those Debian developers who are
> more interested in improving Ubuntu than Debian, and just added the
> following rules to my .procmailrc:

How does dropping potentially useful patches improve Debian?
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Bits from the Package Tracking System

[Denis Barbier]

On Tue, Jul 18, 2006 at 05:33:45PM -0300, Gustavo Franco wrote:
> On 7/18/06, Denis Barbier <[EMAIL PROTECTED]> wrote:
> >On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> >> Hello everybody,
> >>
> >> here are some news about the latest changes made to the Package Tracking
> >> System.
> >>
> >> New derivatives keyword
> >> ---
> >>
> >> The PTS will be used to relay informations from derivative distributions.
> >> Therefore, a new keyword "derivatives" has been implemented. By default, 
> >a
> >> PTS subscriber won't receive the messages associated to this keyword
> >> unless he has already manually activated the "cvs" keyword (i.e. the set
> >> of users having the "derivatives" keyword has been initialized as the 
> >set of
> >> users having the "cvs" keyword because those people can read patches and
> >> are most probably interested in them).
> >
> >So by default it is assumed that I should make Ubuntu's work and dig
> >into these patches to see if some pieces should be applied into Debian?
> >No thanks, I am getting tired of all those Debian developers who are
> >more interested in improving Ubuntu than Debian, and just added the
> >following rules to my .procmailrc:
> >[...]
> 
> No, this is just a service. If you want to dig into these patches, you
> need to subscribe, otherwise you can live without them like you did
> until now, didn't you?

No, I have to unsubscribe, this is exactly what upsets me.  There are
also cases where messages will be sent to lists, like
  http://lists.debian.org/debian-dpkg/2006/07/msg00021.html
So my procmail rule is the best option.

Denis


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

Re: Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)

[Pierre Habouzit]

Le mar 18 juillet 2006 21:26, Thomas Bushnell BSG a écrit :
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > For the record (it was already said in the thread IIRC), the setup
> > we are discussing is in production on alioth since sth like 4 or 5
> > monthes now (maybe a bit less) on my idea, and thanks to Raphael
> > Hertzog for actually using his alioth admin hat to put it together.
>
> Can you document on the relevant web page exactly how the graylisting
> works and what specific things get blocked and when?

  I've already gived numbers in the thread (even graphs), for a similar 
setup.

  I don't have access to alioth logs, but the setup is world readable, 
log on alioth and read it ;) Moreover, as there is quite few valid 
aliases, alioth greylist do not takes care of the recipient in account 
for the greylisting, but only the MAIL FROM + SENDER IP, which a good 
trade off for alioth, but may not be true for DD accounts. that's the 
sole "deviation" of what has been discussed here, and is not very 
relevant to the discussion anyway.

  Technically, I don't know what you want me to say more than what is 
explained on my blog and in that thread (or in alioth's world readable 
exim.conf).

 Moreover I don't see what value the 6 or 7 mails that you posted less 
than 1 hour ago, in the same quarter, answering to at least half of the 
most recents posts in the thread, have made the discussion make any 
progress.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp2b0E7CPZll.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[Gustavo Franco]

On 7/18/06, Denis Barbier <[EMAIL PROTECTED]> wrote:

On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> Hello everybody,
>
> here are some news about the latest changes made to the Package Tracking
> System.
>
> New derivatives keyword
> ---
>
> The PTS will be used to relay informations from derivative distributions.
> Therefore, a new keyword "derivatives" has been implemented. By default, a
> PTS subscriber won't receive the messages associated to this keyword
> unless he has already manually activated the "cvs" keyword (i.e. the set
> of users having the "derivatives" keyword has been initialized as the set of
> users having the "cvs" keyword because those people can read patches and
> are most probably interested in them).

So by default it is assumed that I should make Ubuntu's work and dig
into these patches to see if some pieces should be applied into Debian?
No thanks, I am getting tired of all those Debian developers who are
more interested in improving Ubuntu than Debian, and just added the
following rules to my .procmailrc:
[...]


No, this is just a service. If you want to dig into these patches, you need to
subscribe, otherwise you can live without them like you did until now,
didn't you?

Please, think before replying my message and who you're hitting with your anger.

regards,
-- stratus


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

Re: Bits from the Package Tracking System

[Denis Barbier]

On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> Hello everybody,
> 
> here are some news about the latest changes made to the Package Tracking
> System.
> 
> New derivatives keyword
> ---
> 
> The PTS will be used to relay informations from derivative distributions.
> Therefore, a new keyword "derivatives" has been implemented. By default, a
> PTS subscriber won't receive the messages associated to this keyword
> unless he has already manually activated the "cvs" keyword (i.e. the set
> of users having the "derivatives" keyword has been initialized as the set of
> users having the "cvs" keyword because those people can read patches and
> are most probably interested in them).

So by default it is assumed that I should make Ubuntu's work and dig
into these patches to see if some pieces should be applied into Debian?
No thanks, I am getting tired of all those Debian developers who are
more interested in improving Ubuntu than Debian, and just added the
following rules to my .procmailrc:
  :0
  * ^From.*(ubuntu|canonical).com
  /dev/null

Denis, pissed off
PS: No, I am not joking


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
>> If the anti-spam advocates consistently said "our measures impose
>> such-and-such a cost, but we think it's worth it", I would be
>> delighted.
>
>  the measures impose a cost, but we think it's worth it

Can you detail what the cost is for the specific procedures in use on
Debian's servers?  No, because you are apparently unaware it exists
already.  But yet, without knowing the cost, you are sure it's worth
it.  Bah.

>  Can we get greylisting now?

We have it, duh.  Have you not been paying attention?

Thomas

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 18, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> Yes, and this is not the point.  The point is that the standard does
> *not* say that the retry must come from the same place, or even
> anything like the same place.
The point is that in the real world nobody cares that this is not
specified in a standard.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 18, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> > Because there is no reason to do this, this is not a standard issue but
> > plain operations.
> Really?  So you think the IETF would happily issue a statement
> agreeing?
Yes.

> Of course, the facts are that the IETF regards graylisting as a
> violation of the email protocols and not to be implemented.
When (and how?) did the IETF express such an opinion?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Loïc Minier]

On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
> If the anti-spam advocates consistently said "our measures impose
> such-and-such a cost, but we think it's worth it", I would be
> delighted.

 the measures impose a cost, but we think it's worth it

 Can we get greylisting now?

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

Re: Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)

[Thomas Bushnell BSG]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> For the record (it was already said in the thread IIRC), the setup we 
> are discussing is in production on alioth since sth like 4 or 5 monthes 
> now (maybe a bit less) on my idea, and thanks to Raphael Hertzog for 
> actually using his alioth admin hat to put it together.

Can you document on the relevant web page exactly how the graylisting
works and what specific things get blocked and when?

Thomas


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Jul 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> Still, if you think it's just nitpicking, then why not ask the IETF to
>> amend the standard to clearly permit this practice?

> Because there is no reason to do this, this is not a standard issue but
> plain operations.

Really?  So you think the IETF would happily issue a statement
agreeing?

Of course, the facts are that the IETF regards graylisting as a
violation of the email protocols and not to be implemented.


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Adam Borowski <[EMAIL PROTECTED]> writes:

> Even worse, there's nothing preventing a site from saying it has a
> temporary local problem when it _does_.  Thus, if your mail server
> can't handle retrying, it will drop mail every time something is not
> in perfect working order.  And hardware or network failures are
> something to be expected.
>
> Any legitimate server must support retrying.  For any reason.

Yes, and this is not the point.  The point is that the standard does
*not* say that the retry must come from the same place, or even
anything like the same place.


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This one time, at band camp, Thomas Bushnell BSG said:
>> And finally, if we don't care about standards conformance, I have said
>> that a good second-best is to document exactly what our requirements
>> are, rather than burying them in apparent secrecy.
>
> What standards, exactly?  Can you be specific?  I have seen you assert
> this several times, but I see nothing in the RFCs preventing a site from
> saying it has a temporary local problem when it doesn't.  You've been
> asked this before in response to your assertion, and haven't answered.

So the meaning of 4xx is "temporary local problem".  Sending that when
you don't have a temporary local problem is a violation, right there.
Must the standard repeat after every sentence, "oh, and don't lie".

Thomas


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> I have refused greylisting for a long time for that exact reason.
> However the setup Pierre Habouzit describes does not delay most of
> legitimate mail. Frankly, the remaining delays are sporadic and one can
> live with them.

What bothers me is that we hear "it never delays legitimate mail!" and
then "well, ok, it delays some".

If the anti-spam advocates consistently said "our measures impose
such-and-such a cost, but we think it's worth it", I would be
delighted.

But what I seem to hear is not that.  It's "hey, this imposes no
costs!" or "spam is evil, so any cost is worth bearing to fight it!"

Thomas


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

Re: Bits from the Package Tracking System

[Christoph Berg]

Re: Wouter Verhelst 2006-07-18 <[EMAIL PROTECTED]>
> > On the contrary people who want to have the "derivatives" keyword on all
> > their subscriptions can use one of those commands:
> > keywordall + derivatives
> > keywordall [EMAIL PROTECTED] + derivatives
> 
> This is so cool that I immediately went and did this...
> 
> ... only to find out that it did this for debian-installer only (for
> which I'm subscribed to the 'cvs' keyword) rather than all my own
> packages (as I'd expected).

This was fixed by Raphaël earlier today; try again. It will now also
update the default list of keywords for packages you haven't specified
any keywords for when you subscribed. (For the details, look in
master:/org/packages*/db/*.db)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bits from the Package Tracking System

[martin f krafft]

also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2006.07.18.1452 +0200]:
> If I'm wrong, could you please point me to where is documented where I
> can subscribe to all packages with "Maintainer: [EMAIL PROTECTED]" so that
> when I upload a new package to the archive I will be subscribed to it
> without having to chat again with the PTS? That's what was asked by
> Wouter at the beginning of this thread, I believe.

Ah, then I misunderstood. However, what you are trying to do will
hopefully soon be unnecessary as there are plans to auto-subscribe
maintainers to the PTS and redirecting @packages.d.o mail there.
Raphael has more details, but some are here:

  http://wiki.debian.org/qa.debian.org/pts

-- 
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 usually takes more than three weeks
 to prepare a good impromptu speech.
 -- mark twain


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

Bug#378746: ITP: chameleon-cursor-theme -- a modern but not gaudy X11 mouse theme

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski <[EMAIL PROTECTED]>

* Package name: chameleon-cursor-theme [1]
  Version : 0.5-1
  Upstream Author : Giuseppe Benigno 
* URL : 
http://www.{gnome,kde,xfce[2]}-look.org/content/show.php?content=38459
* License : GPL
  Description : a modern but not gaudy X11 mouse theme
 Package comes with 15 different mouse themes for X11.
 5 colors (anthracite, sky blue, dark sky blue, white, pearl)
 3 different sizes (small, regular and large)
 .
 Preview: http://www.kde-look.org/content/show.php?content=38459


The default, industrial-cursor-theme, comes in just one size.  The two
other good themes we have, comixcursors and crystalcursors are really
compatible only with desktop themes matching ".*k.*".  xcursor-themes
are only so-so, so adding one more package won't hurt...

Speaking from a more complete point of view, the only themes worth
being packaged left on http://www.foo-look.org are perhaps silver and
yellowdot -- the rest is either redundant or ugly.  Of course, you do
know that my opinion is the highest authority in the realm of
aesthethics.


[1]. Should I stick to *-cursor-theme or *cursors?  Or keep the
upstream name, chameleon Xcursors?

[2]. Alas, they don't seem to support WindowMaker or BlackBox :p


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

Bug#378734: ITP: axtls -- TLSv1 SSL library designed for embedded platforms

[Roberto Lumbreras]

Package: wnpp
Severity: wishlist
Owner: Roberto Lumbreras <[EMAIL PROTECTED]>

* Package name: axtls
  Version : 1.01
  Upstream Author : Cameron Rich <[EMAIL PROTECTED]>
* URL : http://www.axtls.co.nr/
* License : LGPL
  Description : TLSv1 SSL library designed for embedded platforms

 axTLS is a highly configurable client/server TLSv1 SSL library designed
 for embedded platforms.


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


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

Re: These new diffs are great, but...

[Paul Slootman]

On Fri 30 Jun 2006, Martin Schulze wrote:
> 
> You know that you can easily turn off this feature by adjusting apt.conf:
> 
>Acquire::Pdiffs { "false"; };

Ah, great :)

After not having done "aptitude update" for a month or so, after
downloading all the hunderds (!) of diffs, I got the following dreaded
message again:

E: Dynamic MMap ran out of room
E: Read error - read (14 Bad address)
E: The package lists or status file could not be parsed or opened.
E: Dynamic MMap ran out of room
E: Read error - read (14 Bad address)
E: The package lists or status file could not be parsed or opened.

I thought that this was something from bygone days... pretty dismal,
having such a fixed limit on an amd64 with 2GB of memory.
After adding "APT::Cache-Limit "2000";" in /etc/apt/apt.conf
(the old example of 8MB wasn't enough) it proceeded, and now I don't
need that anymore. The high memory need was apparently related to
processing all those diffs.


Paul Slootman


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

Re: flash drive automount.

[Josselin Mouette]

Le mercredi 19 juillet 2006 à 00:36 +0545, Basanta Shrestha a écrit :
> Dear Debian Developers,
> 
> I have a 512MB DataTraveller Flash Disk. It is automounted under
> ubuntu but fails to automount under debian. Has ubuntu patched things
> up to get this result? Can this  not be achieved under debian? 

If it happens only with some drives and not others, this is most
probably a kernel issue. Every new version includes workarounds for more
or less broken hardware.

You can get a more recent kernel for sarge at backports.org.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: flash drive automount.

[Colin Tuckley]

Basanta Shrestha wrote:
> Dear Debian Developers,
> 
> I have a 512MB DataTraveller Flash Disk. It is automounted under ubuntu
> but fails to automount under debian. Has ubuntu patched things up to get
> this result? Can this  not be achieved under debian?
> 
> There is no problem automounting other kinds to flash/thumb drivers! 90%
> of them work/automount.

Automounting of fat/vfat formatted usb drives is disabled in Debian. See the
comments at the top of /etc/usbmount for the reasons.

Colin

-- 
Colin Tuckley  |  [EMAIL PROTECTED]  |  PGP/GnuPG Key Id
+44(0)1903 236872  |  +44(0)7799 143369  | 0x1B3045CE

"Heisenberg may have slept here"


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

Re: Getting the buildds to notice new architectures in a package

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Tue, Jul 18, 2006 at 09:56:22AM +0200, Goswin von Brederlow wrote:
>> Two things:
>> 
>> - control files are part of the source. w-b would have to download and
>> unpack every source package to get that file.
>
> Exactly.
>
>> - control files can be auto generated during build (e.g. glibc) and
>> might not even list the packages and architectures
>
> Well, yeah, but if that changes anything about the control file that is
> of importance (like supported architectures or package names), then this
> information is quite blatantly ignored. And the build may fail.

Aeh, the only part that MUST not change is the source entry in
debian/control. Any binary entry is afaik only used by tools forked
from debian/rules (usualy dh_*). If you create the binary entries
before you use them then everything works. Look at glibc for an
example.

MfG
Goswin


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

Re: Recent sid amd64 rpath oddity?

[Goswin von Brederlow]

Simon Huggins <[EMAIL PROTECTED]> writes:

> Hi,
>
> On the 3rd May I built libxfce4util and generated
> libxfce4util2_4.3.90.1-1_amd64.deb.  This is in the archive exactly as I
> built it.  It has a couple of lintian failures that I missed and have since
> been fixed in our SVN.
>
> Upstream have released recently and whilst checking these packages more
> thoroughly I've fixed up the lintian errors but I've also built the new
> package and I noticed that it's defining an rpath.  So I rooted around and
> tried to work out why but couldn't really work it out.  Upstream's
> libtool and autotools looked recent to me.  If I relibtoolize though
> this does go away.
>
> Out of curiousity I rebuilt the previous package i.e. 4.3.90.1-1 again from
> the same source files as before but with current sid and this time it fails
> with two extra lintian warnings:
> W: libxfce4util2: binary-or-shlib-defines-rpath 
> ./usr/lib/libxfce4util.so.2.1.0 /usr/lib
> W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/sbin/xfce4-kiosk-query 
> /usr/lib
>
> If I rebuild the same package on i386 current sid then I don't get the rpath
> installed.
>
> I guess I have several questions:
>   - how can the same source package over a few months build
> differently in this way?
>   - am I really going to have to relibtoolize every xfce package
> before I upload or make them do it themselves? :-/
>   - how evil is an rpath on /usr/lib anyway?
>
> I'd welcome any testers on amd64 or not and on recent sid or not to narrow
> this down.  Or any clues as to how on earth this can happen.
>
> If you do want to relibtoolize then install xfce4-dev-ools and run
> xdt-autogen in the package dirrectory.

Your package, or more likely libtool, has different ideas about what
amd64 system library dirs are to what debian has.  Other distributions
use /usr/lib64 and debian has /usr/lib. That confuses libtool into
adding a rpath. The fix is to force libtool to never ever use rpath.
If you can't get libtool to leave well enough alone then use 'chrpath
-d'.

With rpath your package will afaik break when the library moves,
e.g. to /usr/lib64 for biarch systems as we use at my workplace, or
the multiarch /usr/lib/x86_64-linux-gnu directory.

MfG
Goswin


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

flash drive automount.

[Basanta Shrestha]

Dear Debian Developers,

I have a 512MB DataTraveller Flash
Disk. It is automounted under ubuntu but fails to automount under
debian. Has ubuntu patched things up to get this result? Can this  not
be
achieved under debian?


There is no problem automounting other kinds to flash/thumb drivers!
90% of them work/automount. 

I get a little strange kind of log (as follows) when debian fails to
automont flash drives. 


$ /sbin/fdisk -l
--
---

Disk /dev/sda: 513 MB, 513802240 bytes
16 heads, 32 sectors/track, 1960 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

   Device Boot  Start End  Blocks   Id  System
/dev/sda1   *   1    1960  501744    e  W95 FAT16 (LBA)


Disk /dev/sda1: 2082.3 GB, 2082317979648 bytes
16 heads, 32 sectors/track, 7943412 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

 Device Boot  Start End  Blocks   Id  System

/dev/sda1p1   *   1   
1960  501744    e  W95 FAT16 (LBA)
---


$ tail -f  /var/log/messages
---

Jul 14 16:45:29 localhost kernel: usb 5-8: new high speed USB device
using ehci_hcd and address 6

Jul 14 16:45:29 localhost kernel: scsi6 : SCSI emulation for USB Mass
Storage devices
Jul 14 16:45:34 localhost kernel:   Vendor: Kingston  Model:
DataTraveler 2.0  Rev: 1.04
Jul 14 16:45:34 localhost kernel:   Type:  
Direct-Access  ANSI SCSI revision: 00

Jul 14 16:45:34 localhost kernel: SCSI device sda: 1003520 512-byte
hdwr sectors (514 MB)
Jul 14 16:45:34 localhost kernel: sda: Write Protect is off
Jul 14 16:45:34 localhost kernel: SCSI device sda: 1003520 512-byte
hdwr sectors (514 MB)

Jul 14 16:45:34 localhost kernel: sda: Write Protect is off
Jul 14 16:45:34 localhost kernel: 
sda: [CUMANA/ADFS] sda1<5>sd 6:0:0:0: Attached scsi removable
disk sda
___


Please suggest.

Regards
Basanta 

[EMAIL PROTECTED]

Re: Bits from the Package Tracking System

[Stefano Zacchiroli]

On Tue, Jul 18, 2006 at 01:36:47PM +0200, martin f krafft wrote:
> also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2006.07.18.1318 +0200]:
> > Each subscription subscribe you to a given (source) package. Keywords
> > are actually a filter, but filter notification for a given package.
> 
> No, you can have filters per email and filters per email/package
> tuple to override the former.

I think you're referring to the following commands of the PTS email
interface:

  keyword [] {+|-|=} 
  keyword  [] {+|-|=} 

You're right in stating that you can filter both per email and
email/package, but the subscriptions are per-package.

If I'm wrong, could you please point me to where is documented where I
can subscribe to all packages with "Maintainer: [EMAIL PROTECTED]" so that
when I upload a new package to the archive I will be subscribed to it
without having to chat again with the PTS? That's what was asked by
Wouter at the beginning of this thread, I believe.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)

[Pierre Habouzit]

Le mar 18 juillet 2006 13:20, Adrian von Bidder a écrit :
> Apart from the fact that the opinions seem to be set (and haven't
> really changed since the last time the discussion came up IIRC, so we
> really can stop arguing - nothing new for quite some time...): am I
> correct in my observation that nobody who has participated in this
> discussion up to now is involved in Debian email administration?  I
> had a quick look at , but I
> didn't really check all names.

For the record (it was already said in the thread IIRC), the setup we 
are discussing is in production on alioth since sth like 4 or 5 monthes 
now (maybe a bit less) on my idea, and thanks to Raphael Hertzog for 
actually using his alioth admin hat to put it together.

so as a matter of a fact, yes, I've already worked in a way so that such 
solutions can be implemented where there is reachable and listening 
people to work with.

> So even if the discussion leans in favor of greylisting on RBL
> (SBL+XBL? Or also DUL, spamcop, ...?): is there any chance of this
> getting anywhere?

I'm not sure the DSA team is a very open one, if I'm mistaken, then take 
that mail as an official application request, either for a temporary 
delegation (or for a more permanent thing) to work on implementing more 
efficient mail delivery on debian MX'es.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpzougW7nRbL.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[martin f krafft]

also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2006.07.18.1318 +0200]:
> Each subscription subscribe you to a given (source) package. Keywords
> are actually a filter, but filter notification for a given package.

No, you can have filters per email and filters per email/package
tuple to override the former.

-- 
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 isn't pollution that's harming the environment.
 it's the impurities in our air and water that are doing it." 
  - dan quayle


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

Greylisting: discussion should stop here, for now (Re: greylisting on debian.org?)

[Adrian von Bidder]

Apart from the fact that the opinions seem to be set (and haven't really 
changed since the last time the discussion came up IIRC, so we really can 
stop arguing - nothing new for quite some time...): am I correct in my 
observation that nobody who has participated in this discussion up to now 
is involved in Debian email administration?  I had a quick look at 
, but I didn't really check all 
names.

So even if the discussion leans in favor of greylisting on RBL (SBL+XBL? Or 
also DUL, spamcop, ...?): is there any chance of this getting anywhere?

cheers
-- vbi

-- 
Computer programmers don't byte, they nibble a bit.


pgp9ga3YUdUgE.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[Stefano Zacchiroli]

On Tue, Jul 18, 2006 at 01:04:06PM +0200, martin f krafft wrote:
> also sprach Wouter Verhelst <[EMAIL PROTECTED]> [2006.07.18.1157 +0200]:
> > command to set the keyword subscriptions for any current and future
> > packages maintained by a given maintainer?
> 
> The keywords are actually more a filter, so if you have derivatives
> on for an email and you subscribe with that email to a new package,
> you'll get the derivatives mails.

This doesn't seem to answer Wouter question, or ... I'm misreading the
PTS documentation.

Each subscription subscribe you to a given (source) package. Keywords
are actually a filter, but filter notification for a given package.
Wouter was asking about a subscription that let you subscribe to all
packages of a given maintainer e-mail address (of course with
late-binding of the set of packages).

This is something I'm very interested to have as well, but I don't think
it is actually implemented.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Bits from the Package Tracking System

[martin f krafft]

also sprach Wouter Verhelst <[EMAIL PROTECTED]> [2006.07.18.1157 +0200]:
> Would it be possible to implement something like a 'keywordmaint'
> command to set the keyword subscriptions for any current and future
> packages maintained by a given maintainer?

The keywords are actually more a filter, so if you have derivatives
on for an email and you subscribe with that email to a new package,
you'll get the derivatives mails.

-- 
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
 
"health? what good is your health when you're otherwise an idiot?"
-- theodor w. adorno


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

Re: Bits from the Package Tracking System

[Riku Voipio]

On Mon, Jul 17, 2006 at 06:59:41PM -0300, Gustavo Franco wrote:
> >Is an archive of those mails available somewhere? This way the "small
> >patches" will be available even for packages of people not subscribed to
> >the PTS. Or for people who subscribe after some version has been
> >uploaded to ubuntu.
 
> https://lists.ubuntu.com/archives/ubuntu-patches/

I think having those patches sorted by per-package 
would be more usefull. Thus there could be a link
on the packages.qa.debian.org/source page to these
patches.

But this is a great start. Now we just need to
pressure Linspire, Xandros and friends to produce
similar feeds. (Or write a big-brother script to
monitor them ;)

Cheers,
Riku


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

Re: Bits from the Package Tracking System

[Frank Küster]

(btw, why was there a Mail-Followup-To: d-d-a?)

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

> The maintainer can thus subscribe to this specific keyword and be informed
> when Ubuntu introduces changes to their Debian package.

Is there any documentation about which keywords the address in the
Maintainer field of a package is subscribed to by default?  Is it the
same set that is described as "default" in
http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system,
in other words the maintainer has to explicitly subscribe to the
services upload-binary, cvs, ddtp and derivatives?

TIA, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: greylisting on debian.org?

[Wouter Verhelst]

On Tue, Jul 18, 2006 at 09:47:13AM +0200, Lionel Elie Mamane wrote:
> On Tue, Jul 18, 2006 at 12:47:49AM +0200, Josselin Mouette wrote:
> >   * Exim sender/callout fails with a fatal error.
> 
> "Fatal" means not temporary?

Yes. It means exim did this to one of the MX hosts listed for the
domain:

EHLO 
MAIL FROM:<>
RCPT TO:
QUIT

and received a 5xx error in reply to the RCPT TO: line (not 4xx).

-- 
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: Getting the buildds to notice new architectures in a package

[Wouter Verhelst]

On Tue, Jul 18, 2006 at 09:56:22AM +0200, Goswin von Brederlow wrote:
> Two things:
> 
> - control files are part of the source. w-b would have to download and
> unpack every source package to get that file.

Exactly.

> - control files can be auto generated during build (e.g. glibc) and
> might not even list the packages and architectures

Well, yeah, but if that changes anything about the control file that is
of importance (like supported architectures or package names), then this
information is quite blatantly ignored. And the build may fail.

-- 
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: Bits from the Package Tracking System

[Wouter Verhelst]

On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> Changing keyword on all subscriptions
> -
> 
> The control bot has been expanded to support new commands to add/remove
> keyword on all subscriptions. People who are subscribed to packages with
> the cvs keyword and which do not wish to receive the mails sent to the new 
> "derivatives" keyword can send one of those commands to
> [EMAIL PROTECTED] to deactivate this last keyword in all their
> subscriptions:
> keywordall - derivatives
> keywordall [EMAIL PROTECTED] - derivatives
> 
> On the contrary people who want to have the "derivatives" keyword on all
> their subscriptions can use one of those commands:
> keywordall + derivatives
> keywordall [EMAIL PROTECTED] + derivatives

This is so cool that I immediately went and did this...

... only to find out that it did this for debian-installer only (for
which I'm subscribed to the 'cvs' keyword) rather than all my own
packages (as I'd expected).

Now of course I could go through all my packages and manually subscribe
to the derivatives keyword for each, but that's going to require me to
remember to set the derivatives keyword for any future package that I
start maintaining.

Would it be possible to implement something like a 'keywordmaint'
command to set the keyword subscriptions for any current and future
packages maintained by a given maintainer?

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

[Pierre Habouzit]

Le mar 18 juillet 2006 11:51, Christian Perrier a écrit :
> > Then it would be OK to implement it. The very best would be to do
> > the same I do on my mail server, where users can individually
> > choose greylisting or not for personal mail to them, by a settings
> > file in their home directory. But if a strong majority wants
> > greylisting, it is OK to just do it on all mail (except
> > postmaster@, maybe).
>
> Well, if per-user settings are possible, then it would be a *very*
> valuable feature to have. That would certainly allow avoiding
> concerns like yours (or minimize them as much as possible).
>
> Dunno if that is possible with Pierre Habouzit greylisting
> system...Pierre?

it is, and it's not.

the historical way to perform greylist is to do it on a per user basis, 
answering your 200/400 answers to each RCPT TO command.

so basically, the greylister could know he should not greylist some 
recipients.

*but*:
 (1) many broken MTA do not understand that you give a 400 to some
 RCPT's and not others, and have erratic behaviours that may result
 in:
 - many resents of the same mail for the people that do not use
   greylisting
 - delay even for the one that do not user greylisting
 (2) "modern" greylisting usually do it at DATA now (I mean at the DATA
  command, where the smtpd usually anser sth like:
  321 please end your command with . or sth
  similar), because it makes checks beeing done only once.

but basically, what I've suggested alread some time ago, is not to 
refine the greylisting method, here you can use whatever greylister you 
want, with whatever customization you need/want. I just suggested to do 
conditionnal greylisting, the rest is up to the greylister you use, 
really. everything is possible.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpgGNtDYLpPw.pgp
Description: PGP signature

Bug#378671: ITP: jpnevulator - Serial sniffer

[Freddy Spierenburg]

Package: wnpp
Severity: wishlist
Owner: Freddy Spierenburg <[EMAIL PROTECTED]>

* Package name: jpnevulator
  Version : 1.2.2
  Upstream Author : Freddy Spierenburg
* URL : http://jpnevulator.snarl.nl/
* License : GPL
  Programming Lang: C
  Description : Serial sniffer

 jpnevulator is a handy serial sniffer. You can use it to send
 data on a serial device too. You can read or write from/to one or
 more serial devices at the same time.
 .
 In write mode data to be send on the serial device(s) is read
 from a file or stdin in hexadecimal notation. Data is send on the
 serial device(s) line by line.
 .
 In read mode data to be read from the serial device(s) is written
 to a file or stdout in hexadecimal notation. Several options
 enhance the way the data is displayed.


-- 
$ cat ~/.signature
Freddy Spierenburg <[EMAIL PROTECTED]>  http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1  E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Christian Perrier]

> Then it would be OK to implement it. The very best would be to do the
> same I do on my mail server, where users can individually choose
> greylisting or not for personal mail to them, by a settings file in
> their home directory. But if a strong majority wants greylisting, it
> is OK to just do it on all mail (except postmaster@, maybe).


Well, if per-user settings are possible, then it would be a *very*
valuable feature to have. That would certainly allow avoiding concerns
like yours (or minimize them as much as possible).

Dunno if that is possible with Pierre Habouzit greylisting
system...Pierre?


-- 

Re: Measuring "should I greylist?" false positive rate [was: greylisting on debian.org?]

[Pierre Habouzit]

Le mar 18 juillet 2006 10:27, Lionel Elie Mamane a écrit :
> On Tue, Jul 18, 2006 at 10:03:59AM +0200, Pierre Habouzit wrote:
> > it's the number of mails that are beeing resubmited per week with
> > my system. so in fact, in them, there is 49 spams.
>
> Fascinating. Which RBL's do you use for that? Or do you have atypical
> mail patterns? Exactly two of my 50-or-so mail users use greylisting,
> based on RBLs *only*. They are kinda high-traffic mail users, but
> still, they, on their own, push the greylisting "this triplet is
> allowed" database entries to the thousands. The "this triplet tried
> once, but not more, in the alloted time" database entries are more
> numerous only by about an order of magnitude.

I already told before what I use for my personnal setup. on those 
servers it's:

rbl:  cbl.abuseat.org
rbl:  dynablock.njabl.org

we used to use dul.dnsbl.sorbs.net, but it recently got mad and took 
ages to answer, making us greylist the whole planet.

The 50 resubmitted mails are what we have now that the 'postgrey' 
database is trained. it was a bit higher during the earlier days. and 
the efficiency is remarkable: http://madism.org/~madcoder/pub/glist.png 
(it's only one of the MX's)

the green area is the amount of accepted mails.
the red/blue/orange curves are what our bayesian filter thinks of those 
mails.

the grey curve is unrelated to the others, and is the amount of mails we 
temporarily refused. Like said, very few are resubmited after. sadly we 
don't draw them, we should...

since we have that setup, our servers rarely have a load over 0.8 (only 
when a big mail list delivers), whereas it was over 3 to 4 frequently 
due to spam before. mails are always delivered in less than 3 seconds 
(against sth up to the minute before).

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpPxRD01nBHD.pgp
Description: PGP signature

Recent sid amd64 rpath oddity?

[Simon Huggins]

Hi,

On the 3rd May I built libxfce4util and generated
libxfce4util2_4.3.90.1-1_amd64.deb.  This is in the archive exactly as I
built it.  It has a couple of lintian failures that I missed and have since
been fixed in our SVN.

Upstream have released recently and whilst checking these packages more
thoroughly I've fixed up the lintian errors but I've also built the new
package and I noticed that it's defining an rpath.  So I rooted around and
tried to work out why but couldn't really work it out.  Upstream's
libtool and autotools looked recent to me.  If I relibtoolize though
this does go away.

Out of curiousity I rebuilt the previous package i.e. 4.3.90.1-1 again from
the same source files as before but with current sid and this time it fails
with two extra lintian warnings:
W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/lib/libxfce4util.so.2.1.0 
/usr/lib
W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/sbin/xfce4-kiosk-query 
/usr/lib

If I rebuild the same package on i386 current sid then I don't get the rpath
installed.

I guess I have several questions:
- how can the same source package over a few months build
  differently in this way?
- am I really going to have to relibtoolize every xfce package
  before I upload or make them do it themselves? :-/
- how evil is an rpath on /usr/lib anyway?

I'd welcome any testers on amd64 or not and on recent sid or not to narrow
this down.  Or any clues as to how on earth this can happen.

If you do want to relibtoolize then install xfce4-dev-ools and run
xdt-autogen in the package dirrectory.

Thanks.

Simon.

heh, good sigmonster.

-- 
oOoOo Open source is about letting go of complete control. Accept  oOoOo
 oOoOo   the fact that other people are wonderful resources tooOoOo
  oOoOo fixing problems, and let them help you. - Linus Torvalds oOoOo
  htag.pl 0.0.22 ::: http://www.earth.li/~huggie/


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Lionel Elie Mamane]

On Tue, Jul 18, 2006 at 10:22:41AM +0200, Christian Perrier wrote:
> Lionel Elie Mamane a écrit :


>> Bingo: Legitimate mail slowed down. You think the price is worth
>> it, which is a valid opinion. I happen not to think so.

> The question becomes: aren't you in a small minority?

That may very well be. A message was sent saying "only Thomas
disagrees", I just wanted to say that if we go the voice-counting way,
I have one, too.

> We certainly all know that it's perfectly impossible to reach a 100%
> consensus on such a topic. But what would be your point if a strong
> majority of DD agrees with the use of greylisting (as described by
> Pierre)

Then it would be OK to implement it. The very best would be to do the
same I do on my mail server, where users can individually choose
greylisting or not for personal mail to them, by a settings file in
their home directory. But if a strong majority wants greylisting, it
is OK to just do it on all mail (except postmaster@, maybe).

>> I don't remember the "master cannot cope under mail load, we need
>> desperate measures" point being brought up before. I may have
>> missed it.

> Well, given the way I received debian lists mail last day, there has 
> probably been something somewhere..:)

I meant "in this thread". I do not read all threads, nor all mailing
lists.

-- 
Lionel


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

Re: Measuring "should I greylist?" false positive rate [was: greylisting on debian.org?]

[Lionel Elie Mamane]

On Tue, Jul 18, 2006 at 10:03:59AM +0200, Pierre Habouzit wrote:
> Le mar 18 juillet 2006 10:00, Lionel Elie Mamane a écrit :
>> On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote:
>>> Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :

>>> the discussion (...) was about enabling greylisting on *certain*
>>> *specificaly* *suspicious* hosts. a suspicious
>>> host is:
>>>  * either listed on some RBL's (rbl listing "dynamic" blocks are a
>>> good start usually)
>>>  * either having no reverse DNS set
>>>  * either having curious EHLO lines (that one may catch too much
>>> good mail sadly, so it's to handle with care).
>>>  * ...

>>> I apply greylisting on the two first criteriums on a quite used
>>> mail server (around 300.k mails per week, which is not very big,
>>> but should be representative enough).

>>> there is less than 50 mails a week over those that *may* be
>>> legitimate mails that are actually slowed down.

>> On second thought, I'm very interested in how you measured this false
>> positive rate.

> it's the number of mails that are beeing resubmited per week with my
> system. so in fact, in them, there is 49 spams.

Fascinating. Which RBL's do you use for that? Or do you have atypical
mail patterns? Exactly two of my 50-or-so mail users use greylisting,
based on RBLs *only*. They are kinda high-traffic mail users, but
still, they, on their own, push the greylisting "this triplet is
allowed" database entries to the thousands. The "this triplet tried
once, but not more, in the alloted time" database entries are more
numerous only by about an order of magnitude.

-- 
Lionel


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

Re: greylisting on debian.org?

[Christian Perrier]

(afaik, it's very obvious that I'm subscribed to -devel and, unless I'm 
wrong, I never requeted for being CC'ed in private)


Lionel Elie Mamane a écrit :


Wrong. Disagreeing with you is not the same as not reading your
arguments. Sorry that you were not convincing.

 



I'm afraid you failed to make it clear. Glad that you cleared this out.


This will still include legitimate mail.

 



Sure...just like legitimate mail is very likely to be slowed...or lost 
on DD machines because most of us *have* to use anti-spam measures on 
our own machines (most often without the needed complete knowledge, /me 
being the first).


Or, even without this, slowing down because our @debian.org addresses 
are overspammed and we may be likely to jst miss one important mail.


Or (already happened to me) losing information because a legitimate 
mail, lost in a bunch of spam crap, was infortunate enough to just 
appear like spam...and be discarded or not read.


There is a price to pay and slowing down (not losing...slowing down) a 
very small portion of legitimate mail is a small part of it.



Bingo: Legitimate mail slowed down. You think the price is worth it,
which is a valid opinion. I happen not to think so.

 



The question becomes: aren't you in a small minority? We certainly all 
know that it's perfectly impossible to reach a 100% consensus on such a 
topic. But what would be your point if a strong majority of DD agrees 
with the use of greylisting (as described by Pierre)




I don't remember the "master cannot cope under mail load, we need
desperate measures" point being brought up before. I may have missed
it.
 




Well, given the way I received debian lists mail last day, there has 
probably been something somewhere..:)




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

Re: Measuring "should I greylist?" false positive rate [was: greylisting on debian.org?]

[Pierre Habouzit]

Le mar 18 juillet 2006 10:03, Pierre Habouzit a écrit :
> Le mar 18 juillet 2006 10:00, Lionel Elie Mamane a écrit :
> > On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote:
> > > Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :
> > >
> > >
> > > the discussion (...) was about enabling greylisting on *certain*
> > > *specificaly* *suspicious* hosts. a suspicious
> > > host is:
> > >  * either listed on some RBL's (rbl listing "dynamic" blocks are
> > > a good start usually)
> > >  * either having no reverse DNS set
> > >  * either having curious EHLO lines (that one may catch too much
> > > good mail sadly, so it's to handle with care).
> > >  * ...
> > >
> > > I apply greylisting on the two first criteriums on a quite used
> > > mail server (around 300.k mails per week, which is not very big,
> > > but should be representative enough).
> > >
> > > there is less than 50 mails a week over those that *may* be
> > > legitimate mails that are actually slowed down.
> >
> > On second thought, I'm very interested in how you measured this
> > false positive rate. Do all the recipients of the 300k mails per
> > week check for every mail if it was greylisted (that means you
> > would put a header or something like that saying "this mail was
> > greylisted"?), and they _always_ check on _every_ legitimate mail
> > and _always_ report false positives to you? Probably not. So, are
> > these 50 mails a week all the mail that undergoes greylisting but
> > *still* goes through (i.e. gets retried, roughly)? Something else?
>
> it's the number of mails that are beeing resubmited per week with my
> system. so in fact, in them, there is 49 spams.

oh and as a matter of a fact, I just happen to see that you Cc-ed me on 
the exchanges, I just received the first mail you sent. Just see by 
yourself how fast and furious master runs:

Received: from master.debian.org (master.debian.org [70.103.162.30])
by mx1.polytechnique.org (Postfix) with ESMTP id 7512D33176
for <[EMAIL PROTECTED]>; Tue, 18 Jul 2006 10:05:31 +0200 (CEST)
Received: from 5.xs4all.nl ([213.84.114.29] helo=capsaicin.mamane.lu)
by master.debian.org with esmtp (Exim 4.50)
id 1G2k5n-0007ft-48; Tue, 18 Jul 2006 02:34:07 -0500

Yeah, master took 31 minutes to deliver the mail to the next SMTP 
server, and I'm an admin on it (that's the mail server I was speaking 
of earlier in the thread) and it was its first submission.

so maybe it's time you revise your jugements on how efficient debian.org 
mails servers are recently.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpRFeDq5zoAC.pgp
Description: PGP signature

Re: Getting the buildds to notice new architectures in a package

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Mon, Jul 17, 2006 at 05:53:25AM +0200, Goswin von Brederlow wrote:
>> The buildd package could just be a central hub where two or three
>> knowlegable people sift through the bug reports and then distribute it
>> to the affected/responsible person.
>
> Who would you suggest would do that? I know it's not going to be me.

Make a job description, sign it and post it to debian-devel-announce
and the jobs page. If there is no volunteer that is it. Otherwise you
have your person.

MfG
Goswin


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

Re: Measuring "should I greylist?" false positive rate [was: greylisting on debian.org?]

[Pierre Habouzit]

Le mar 18 juillet 2006 10:00, Lionel Elie Mamane a écrit :
> On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote:
> > Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :
> >
> >
> > the discussion (...) was about enabling greylisting on *certain*
> > *specificaly* *suspicious* hosts. a suspicious
> > host is:
> >  * either listed on some RBL's (rbl listing "dynamic" blocks are a
> > good start usually)
> >  * either having no reverse DNS set
> >  * either having curious EHLO lines (that one may catch too much
> > good mail sadly, so it's to handle with care).
> >  * ...
> >
> > I apply greylisting on the two first criteriums on a quite used
> > mail server (around 300.k mails per week, which is not very big,
> > but should be representative enough).
> >
> > there is less than 50 mails a week over those that *may* be
> > legitimate mails that are actually slowed down.
>
> On second thought, I'm very interested in how you measured this false
> positive rate. Do all the recipients of the 300k mails per week check
> for every mail if it was greylisted (that means you would put a
> header or something like that saying "this mail was greylisted"?),
> and they _always_ check on _every_ legitimate mail and _always_
> report false positives to you? Probably not. So, are these 50 mails a
> week all the mail that undergoes greylisting but *still* goes through
> (i.e. gets retried, roughly)? Something else?

it's the number of mails that are beeing resubmited per week with my 
system. so in fact, in them, there is 49 spams.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgprK1lXgWxgo.pgp
Description: PGP signature

Re: Getting the buildds to notice new architectures in a package

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Mon, Jul 17, 2006 at 02:40:28PM -0400, Joe Smith wrote:
>> "Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message 
>> >There is no such general solution. See
>> >
>> 
>> That says:
>> >However, wanna-build does not look at the control file of a package
>> >when creating its database; only at the packages' name and section,
>> >its urgency, and its priority.
>> 
>> Shouldn't wanna-build use the control file?
>
> Perhaps. The issue is that wanna-build needs to know whether a package
> has already been built for its architecture; one can only find that out
> by looking at the Packages file, and comparing that with the Sources
> file.
>
> Since the Packages and Sources files contain all the information
> wanna-build needs (except for the architectures for which a build should
> be attempted), and since fetching the control files is a _lot_ more work
> than to write a parser for Packages and Sources files which can just be
> piped into wanna-build, it isn't done.
>
> Also, such a thing would probably require quite some I/O, so I'm not
> entirely sure it's worth it. But if you could write some patch which
> does not ever break and which allows to read the control file, I'm sure
> it'll be welcome.
>
> (I'm not sure why it still listed "upload urgency" as a criterion there
> -- that's a bug in the documentation that I introduced, but it's never
> been true. I've just committed a fix)
>
>> It would then mean that the lists of packages-arch-specific would not
>> be needed, except in the case of a single version override in the
>> event that a package's control file accidentally listed an
>> architecture on which it is not supported, or failed to list an
>> architecture on which it is supported. 
>
> The latter wouldn't work anyway -- if it isn't supported,
> dpkg-buildpackage refuses to build the package.

Two things:

- control files are part of the source. w-b would have to download and
unpack every source package to get that file.

- control files can be auto generated during build (e.g. glibc) and
might not even list the packages and architectures


If you want to get rid of the P-a-s file then I suggest you work on
fixing the Architecture field in the Sources file to truely reflect
the architectures the source should be build for. What you have to
worry about is the case of architecture specific sources that also
have architecture independent packages. In those cases the
Architecture field lists "any" instead of e.g. "i386 amd64 all".

If you fix that and allow sources to override the Architecture field
(for autogenerated control files like glibc) then the Sources.gz file
would have all the right information in the normal case. This would
cut down the P-a-s list seriously.

MfG
Goswin


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

Re: greylisting on debian.org?

[Martin Wuertele]

* Lionel Elie Mamane <[EMAIL PROTECTED]> [2006-07-17 22:32]:

> On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
> 
> > So far and unless I forget someone, I haven't seen much other people
> > being strongly opposed to greylisting on Debian hosts,
> 
> Here is one: I am strongly opposed to greylisting (on mail sent to me
> or that I send), for the reason that it delays legitimate mail.
 
Greylisting is among the minor causes for mail delays in my experience.
Most delays when it comes to debian.org mails are caused by the load on
the servers from what I see.
With other companies mails the main delays are caused by their ISPs
smarthosts as they always have queue times of up to 30 minutes while
greylisting only delays once.

yours Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System
 lol, mein feuermelder ist dausicher
 im batteriefach unter der batterie steht
 "WARNUNG: BATTERIE ENTFERNT"


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

Measuring "should I greylist?" false positive rate [was: greylisting on debian.org?]

[Lionel Elie Mamane]

On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote:
> Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :


> the discussion (...) was about enabling greylisting on *certain*
> *specificaly* *suspicious* hosts. a suspicious
> host is:
>  * either listed on some RBL's (rbl listing "dynamic" blocks are a good
>start usually)
>  * either having no reverse DNS set
>  * either having curious EHLO lines (that one may catch too much good
>mail sadly, so it's to handle with care).
>  * ...

> I apply greylisting on the two first criteriums on a quite used mail
> server (around 300.k mails per week, which is not very big, but
> should be representative enough).

> there is less than 50 mails a week over those that *may* be
> legitimate mails that are actually slowed down.

On second thought, I'm very interested in how you measured this false
positive rate. Do all the recipients of the 300k mails per week check
for every mail if it was greylisted (that means you would put a header
or something like that saying "this mail was greylisted"?), and they
_always_ check on _every_ legitimate mail and _always_ report false
positives to you? Probably not. So, are these 50 mails a week all the
mail that undergoes greylisting but *still* goes through (i.e. gets
retried, roughly)? Something else?

-- 
Lionel


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

Re: greylisting on debian.org?

[Pierre Habouzit]

Le mar 18 juillet 2006 09:34, Lionel Elie Mamane a écrit :
> This will still include legitimate mail.

something like 50 over 300k is less than 0.016%.

which is also really less than the usual number of false positives of 
your bayesian mail filter. see end of mail.

> > and if you never actually realized, there *IS* such a slowdown on
> > debian mail lists, it's called crossassassin, it kills master on a
> > regular basis, and is *REALLY* less effective than greylisting.
>
> I don't remember the "master cannot cope under mail load, we need
> desperate measures" point being brought up before. I may have missed
> it.

these days master has a high load on a regular basis:
   load average: 239.68, 299.68, 326.84

from IRC a couple of days ago,


What I experience as a debian developer is that:

 * 80% of the overall spam that eventually comes into my inbox went
   through my debian.org account, that renders the read of such a
   mailbox really hard, and I'm pretty sure that I miss more than 0.016%
   of legitimate mail in my readings.

 * my @debian.org address has considerable slowdowns due to our MXs
   beeing overloaded from time to time. 80% of the time, it's because of
   crossassassin becoming mad, or some spam attack.


Just take some factual numbers: I receive sth like 300 mails a day (top, 
I think the mean value is more around 150). that makes 109.500 mails a 
year. I know for a fact that my bayesian filter makes sth like 4 to 5 
errors per year. And yes I know how to train one. So my bayesian mail 
filter has at least a 0.05% false positive rate, and I'm really 
convinced in fact it's more like 0.1% (maybe even more).

SA is used extensively on debian hosts, I'm also quite sure it also has 
worse rates than a 0.1%. So you are claiming that greylisting is a 
really bad method ? come on !

currently, I receive so many spams from debian, that I just CANT sort 
them. it's sth like 90spams a *day* sometimes. How do you find the time 
to look at the good mails in there ? I can't. So by not delaying 0.016% 
of the legitimate mails, you make a lot of people *LOOSE* for real way 
more than that.

please, your point is only made of impressions, now you have numbers.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpG5ojNkr7dX.pgp
Description: PGP signature

Re: greylisting on debian.org?

[Josselin Mouette]

Le mardi 18 juillet 2006 à 09:47 +0200, Lionel Elie Mamane a écrit :
> That is the crux of the disagreement. You guys think that as long as
> "most" of the legitimate mail is not delayed, the price is worth it. I
> don't think so.

If too much spam gets through, *all* legitimate mail gets delayed. It
gets delayed by the additional filters it has to get through thereafter,
and it gets delayed by having to dig it out of a mailbox full of spam.

> >   * Exim sender/callout fails with a fatal error.
> 
> "Fatal" means not temporary?

It means either the domain doesn't exist, or the server explicitly
replied the user doesn't exist.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: greylisting on debian.org?

[Martin Wuertele]

* Stephen Gran <[EMAIL PROTECTED]> [2006-07-17 18:43]:

> It's not uncommon for big sites to have pools of high throughput
> machines that don't have qrunners, and larger pools of machines that do.
> The first group gets a message, and tries to deliver immediately, and
> any temporary failure gets the messages shunted to the secondary pool.
> Once in the secondary pool, it can be bounced from machine to machine
> to load balance queue size and so on.
> 
> That being said, the original query about this was a strawman argument
> designed specifically to find a problem, and I would say fairly
> confidently we don't need to worry about this.  I have analyzed the logs
> on mail servers I have access to, and I cannot find any site which passes
> a message between more than a half dozen or at most a dozen IP addresses
> before delivery.  This is two or three orders of magnitude less than
> the kind of thing Thomas and others are concerned about.  By the time
> sites big enough to use pools that big exist (which I actually doubt -
> scalability might just be too hard to manage to be worth it), greylisting
> will be another dead tool in the arms race with spammers.
> 
> So far, all the arguments against the idea have just been assertions and
> strawmen.  Unless someone can present a serious argument, can we
> consider this thread done?
 
I've been using greylisting with postgrey and whitelists for some time
now (more than a year to be precise) and I still do get mail from gmail,
yahoo and msn accounts. And if one is so concerned about them one could
contact their postmasters asking for a list of IPs for whitelisting.

After all we are talking about developers @debian.org email addresses
not abouts lists.debian.org.

yours Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System
 * Myon wirft noch ein paar 'f' zum Verteilein in den Channel
-!- florolf is now known as fflorolff

Re: greylisting on debian.org?

[Lionel Elie Mamane]

On Tue, Jul 18, 2006 at 12:47:49AM +0200, Josselin Mouette wrote:
> Le lundi 17 juillet 2006 à 22:29 +0200, Lionel Elie Mamane a écrit :
>> On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
>>> Quoting Wolfgang Lonien ([EMAIL PROTECTED]):

 Do we use greylisting on the @debian.org domain and especially on
 @lists.debian.org?

>>> So, up to now, we've found Thomas Bushnell who seems really hardly
>>> voting against greylisting on Debian hosts, (...).

>>> So far and unless I forget someone, I haven't seen much other
>>> people being strongly opposed to greylisting on Debian hosts,

>> Here is one: I am strongly opposed to greylisting (on mail sent to
>> me or that I send), for the reason that it delays legitimate mail.

> I have refused greylisting for a long time for that exact reason.
> However the setup Pierre Habouzit describes does not delay most of
> legitimate mail.

That is the crux of the disagreement. You guys think that as long as
"most" of the legitimate mail is not delayed, the price is worth it. I
don't think so.

> Frankly, the remaining delays are sporadic and one can live with
> them.

Knowing that most legitimate mail doesn't get delayed doesn't make me
feel better when mail I sit waiting for gets delayed. Obviously, for
most mail I don't care as I don't sit waiting for it, I batch-treat it
a fez times per day or per week. So a half-hour delay on it, I don't
even see it. For *most* mail.

> I'm applying greylisting if one of these conditions is met:
>   * the incoming IP is listed in a DUL;

Bingo! You hit a hot button of mine.

>   * Exim sender/callout fails with a fatal error.

"Fatal" means not temporary?

-- 
Lionel


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

Re: greylisting on debian.org?

[Lionel Elie Mamane]

On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote:
> Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :

>> Here is one: I am strongly opposed to greylisting (on mail sent to
>> me or that I send), for the reason that it delays legitimate mail.

> which shows that you didn't read the discussion

Wrong. Disagreeing with you is not the same as not reading your
arguments. Sorry that you were not convincing.

> that was about enabling greylisting on *certain* *specificaly*
> *suspicious* hosts.

I know.

> a suspicious host is:
>  * either listed on some RBL's (rbl listing "dynamic" blocks are a good
>start usually)
>  * either having no reverse DNS set
>  * either having curious EHLO lines (that one may catch too much good
>mail sadly, so it's to handle with care).
>  * ...

This will still include legitimate mail.

> I apply greylisting on the two first criteriums on a quite used mail 
> server (around 300.k mails per week, which is not very big, but should 
> be representative enough).

> there is less than 50 mails a week over those that *may* be
> legitimate mails that are actually slowed down.

Bingo: Legitimate mail slowed down. You think the price is worth it,
which is a valid opinion. I happen not to think so.

Usually when mail I send gets greylisted, it is because the software
thinks I am "suspicious".

> so *please* do me a favour, read the thread you are answering to,

I did.

> because you really really answer miles away from the debate.

No, I'm not. I'm expressing an opinion after reading all of the
debate, from the points of it I remember.

> and if you never actually realized, there *IS* such a slowdown on
> debian mail lists, it's called crossassassin, it kills master on a
> regular basis, and is *REALLY* less effective than greylisting.

I don't remember the "master cannot cope under mail load, we need
desperate measures" point being brought up before. I may have missed
it.


Best Regards,

-- 
Lionel


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

Processed: Blocking my transition

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> block 322762 by 378646
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 
320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 
322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 
322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 
322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 
322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 
322837 322838 322839 352893 352894 353569 355341 359358 359359 359361 359362 
359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 359374 
359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 359385 
359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 359396 
359399 359400 359401 359403 359405 359406 359407 359408 359409 359410 359411 
359412 359413 359414 359417 359418 359419 359420 359421 359422 359423 359424 
359425 359426 359427 359428 359429 359430 359431 359432 359433 359434 359435 
359436 359437 359439 359440 359441 359442 359443 359444 359445 359446 359447 
359448 359449 359450 359451 359452 359453 359454 359455 359456 359457 359458 
359459 359460 359461 359462 359463 359464 359465 359466 359467 359468 359469 
359470 359471 359472 359473 359474 359475 359476 359477 359478 359479 359480 
359481 359482 359483 359484 359485 359486 359487 359488 359489 359490 359491 
359492 359493 359494 359495 359496 359497 359498 359499 359500 359501 359502 
359503 359504 359505 359506 359507 359508 359509 359510 359511 359512 359513 
359514 359515 359516 359517 359518 359519 359520 359521 359522 359523 359524 
359526 359527 359528 359529 359530 359531 359532 359533 359534 359535 359536 
359537 359538 359539 359540 359541 359542 359543 359544 359545 359546 359547 
359548 359549 359550 359551 359552 359553 359554 359555 359556 359557 359558 
359559 359560 359561 359562 359563 359564 359566 359567 359568 359569 359570 
359571 359572 359573 359574 359575 359576 359577 359578 359579 359580 359581 
359582 359583 359584 359585 359586 359587 359588 359589 359590 359591 359592 
359593 359594 359595 359596 359597 359598 359599 359600 359601 359602 359603 
359604 359605 359606 359607 359608 359609 359610 359611 359612
Blocking bugs of 322762 added: 378646

> block 322762 by 378648
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 
320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 
322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 
322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 
322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 
322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 
322837 322838 322839 352893 352894 353569 355341 359358 359359 359361 359362 
359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 359374 
359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 359385 
359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 359396 
359399 359400 359401 359403 359405 359406 359407 359408 359409 359410 359411 
359412 359413 359414 359417 359418 359419 359420 359421 359422 359423 359424 
359425 359426 359427 359428 359429 359430 359431 359432 359433 359434 359435 
359436 359437 359439 359440 359441 359442 359443 359444 359445 359446 359447 
359448 359449 359450 359451 359452 359453 359454 359455 359456 359457 359458 
359459 359460 359461 359462 359463 359464 359465 359466 359467 359468 359469 
359470 359471 359472 359473 359474 359475 359476 359477 359478 359479 359480 
359481 359482 359483 359484 359485 359486 359487 359488 359489 359490 359491 
359492 359493 359494 359495 359496 359497 359498 359499 359500 359501 359502 
359503 359504 359505 359506 359507 359508 359509 359510 359511 359512 359513 
359514 359515 359516 359517 359518 359519 359520 359521 359522 359523 359524 
359526 359527 359528 359529 359530 359531 359532 359533 359534 359535 359536 
359537 359538 359539 359540 359541 359542 359543 359544 359545 359546 359547 
359548 359549 359550 359551 359552 359553 359554 359555 359556 359557 359558 
359559 359560 359561 359562 359563 359564 359566 359567 359568 359569 359570 
359571 359572 359573 359574 359575 359576 359577 359578 359579 359580 359581 
359582 359583 359584 359585 359586 359587 359588 359589 359590 359591 359592 
359593 359594 359595 359596 359597 359598 359599 359600 359601 359602 359603 
359604 359605 359606 359607 359608 359609 359610 359611 359612 378646
Blocking bugs of 322762 added: 378648

> block 322762 by 378649
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 
320084 320103 321926 322749 322769 32