Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote:
> Ben Hutchings  writes:
> > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > Daniel Pocock  writes:
> > > > However, at the time when I ran ntpdate, ntp was not running.  I had
> > > > brought up the network manually due to an interface renaming issue on
> > > > the first boot.  Maybe when somebody runs ntpdate in a scenario like
> > > > that the kernel is not sending the new date/time to the hardware
> > > > clock.
> > > Right, ntpdate for some reason doesn't set the flag to do this.
> > 
> > [...]
> > There is a very good reason, which is that without continuous
> > adjustment the system clock cannot be assumed more stable than the RTC.
> 
> If you've literally just synced the system clock to a remote NTP server,
> why could you not assume it was more accurate than the RTC?

For that instant, sure, and ntpdate could follow-up the one-shot system
clock synch with a one-short RTC synch.  But the kernel doesn't provide
a simple API for that, and it's easy enough to add "hwclock --systohc"
to a script right after "ntpdate ...".

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.



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

Bug#856339: ITP: kanboard-cli -- kanboard command line client

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?b?Q2hhbmdaaHVvIENoZW4gKOmZs+aYjOWArCk=?= 

* Package name: kanboard-cli
  Version : 0.0.2
  Upstream Author : Copyright (c) 2016 Frederic Guillot
* URL : https://github.com/kanboard/kanboard-cli
* License : Expat
  Programming Lang: Python
  Description : kanboard command line client

 kanboard-cli is a command line client for kanboard application.


-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Ben Hutchings  writes:
> On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
>>> Daniel Pocock  writes:

>>> However, at the time when I ran ntpdate, ntp was not running.  I had
>>> brought up the network manually due to an interface renaming issue on
>>> the first boot.  Maybe when somebody runs ntpdate in a scenario like
>>> that the kernel is not sending the new date/time to the hardware
>>> clock.

>> Right, ntpdate for some reason doesn't set the flag to do this.
> [...]

> There is a very good reason, which is that without continuous
> adjustment the system clock cannot be assumed more stable than the RTC.

If you've literally just synced the system clock to a remote NTP server,
why could you not assume it was more accurate than the RTC?

-- 
Russ Allbery (r...@debian.org)   

Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > Daniel Pocock  writes:
> 
> > However, at the time when I ran ntpdate, ntp was not running.  I had
> > brought up the network manually due to an interface renaming issue on
> > the first boot.  Maybe when somebody runs ntpdate in a scenario like
> > that the kernel is not sending the new date/time to the hardware clock.
> 
> Right, ntpdate for some reason doesn't set the flag to do this.
[...]

There is a very good reason, which is that without continuous
adjustment the system clock cannot be assumed more stable than the RTC.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.



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

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Ben Hutchings  writes:
> On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:

>> The much simpler systemd-timesyncd doesn't set the hardware clock for
>> reasons that one may or may not agree with (I honestly haven't
>> researched it in any depth),

> It looks like it does iff the RTC is set to UTC:

> /*
>  * An unset STA_UNSYNC will enable the kernel's 11-minute mode,
>  * which syncs the system time periodically to the RTC.
>  *
>  * In case the RTC runs in local time, never touch the RTC,
>  * we have no way to properly handle daylight saving changes and
>  * mobile devices moving between time zones.
>  */
> if (m->rtc_local_time)
> tmx.status |= STA_UNSYNC;

Oh!  Okay, then yes, it shouldn't matter whether it persists at shutdown
or not, since it will be setting it periodically anyway.

>> but you can just run ntpd instead if you care.

> But ntpd is also known to have a large amount of code written without
> as much regard for security as one would hope.  It seems like an
> unnecessary risk for most systems.

Indeed, I've personally switched to systemd-timesyncd on my systems, which
works fine for me.  (I think there are other lightweight clients if people
want something different.)

-- 
Russ Allbery (r...@debian.org)   

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Daniel Pocock  writes:

> However, at the time when I ran ntpdate, ntp was not running.  I had
> brought up the network manually due to an interface renaming issue on
> the first boot.  Maybe when somebody runs ntpdate in a scenario like
> that the kernel is not sending the new date/time to the hardware clock.

Right, ntpdate for some reason doesn't set the flag to do this.

> I had simply assumed that it would be persisted at shutdown but maybe
> ntpdate could be patched to do whatever ntpd does to encourage the
> kernel to persist it.

sysvinit I believe used to always persist the clock to the hardware clock
during shutdown.  systemd doesn't do that, for reasons that I've not
thought about in any depth.  So that's a change, which is understandably
surprising.

If you get in the habit of using ntpd instead of ntpdate to do the
one-time clock syncs, that might fix the problem (alas, I forget the set
of command line flags that do the same thing as ntpdate).

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs

[Adam Borowski]

On Mon, Feb 27, 2017 at 03:18:04PM +, Jeremy Stanley wrote:
> It's not packaged for Debian yet nor do I see any RFP/ITP, but I've
> been happily using https://github.com/tehmaze/diagram for a few
> years (installable from PyPI via pip so probably easy enough to
> package). Its default mode uses 8-dot Braille patterns for axis
> graphs.

Alas, that tool works on terminals only.  It uses ncurses and its output
can't be trivially converted to text, at least programmatically (you can run
it in a terminal then copy&paste the result).  But even if you do that, you
lose parts that are implemented as attributes (like, a horizontal line is
done via underlining).

And even if you use a graph mode that doesn't need attributes, it does mix
character ranges -- especially bad is using U+20 (ie, real ASCII space) as
on a typical non-terminal setup it has only a width of ~2/3 of U+28XX
glyphs, making everything totally misaligned.

Even on actual terminals, it works only if lowered dots are rendered as
blank.  This goes contrary to what Unicode requires.  Most fonts do so as on
a low-DPI display the text tends to end up in an unreadable jumble of pixels
(see FreeMono before stretch), but with some fancy logic it _is_ possible to
do so in a way closer to what the standard requires.  Please see what Fedora
implements in their default terminals -- when using U+2800 like braillegraph
does you get a white graph in a dark gray rectangle, with tehmaze's diagram
the graph is surrounded by ugly blocks.

Likewise the embedded labels: they're too likely to cause misalignment or
even word wrapping.  A mail or a commit message is going to be seen by too
many diverse clients you can't control.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Re: systemd, ntp, kernel and hwclock

[Daniel Pocock]

On 27/02/17 20:18, Russ Allbery wrote:
> Daniel Pocock  writes:
> 
>> I've observed a system that had a wildly incorrect hardware clock (when
>> it was first unboxed), I ran ntpdate to sync the kernel clock but after
>> a shutdown and startup again it had a wacky time again.
> 
>> I came across the discussion about how the hardware clock is no longer
>> set at shutdown[1]
> 
>> The system has ntpd running
> 
>> Looking at the output of
>>adjtimex --print | grep status
> 
>> the bit corresponding to 64 / STA_UNSYNC is 0
> 
>> There is a time and date page on the wiki[2] and in the manual[3],
>> neither of them appears to have up to date information about the way it
>> works with systemd or how to troubleshoot issues like this.
> 
> My understanding from reading a bit about this just now is that the short
> version is "install ntpd if you want this to happen."
> 
> My impression is that ntpdate has been obsolete for years and upstream has
> been slowly trying to kill it.  ntpd is the upstream-supported daemon, and
> it periodically asks the kernel to set the hardware clock.  (And it
> supports various command-line options to make it act like ntpdate if you
> really want.)
> 
> The much simpler systemd-timesyncd doesn't set the hardware clock for
> reasons that one may or may not agree with (I honestly haven't researched
> it in any depth), but you can just run ntpd instead if you care.
> 
> Alternately, if you really want to use a clock setting mechanism that
> doesn't ask the kernel to sync the hardware clock but you still want to
> set the hardware clock, you can add your own shutdown init script / unit
> to run hwclock --systohc (or even a cron job if you want).
> 


ntpd is definitely running now, it is a default configuration and it was
already on the box a long time before I observed the issue today.

However, at the time when I ran ntpdate, ntp was not running.  I had
brought up the network manually due to an interface renaming issue on
the first boot.  Maybe when somebody runs ntpdate in a scenario like
that the kernel is not sending the new date/time to the hardware clock.
I had simply assumed that it would be persisted at shutdown but maybe
ntpdate could be patched to do whatever ntpd does to encourage the
kernel to persist it.

Regards,

Daniel

Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
> > Daniel Pocock  writes:
> 
> > I've observed a system that had a wildly incorrect hardware clock (when
> > it was first unboxed), I ran ntpdate to sync the kernel clock but after
> > a shutdown and startup again it had a wacky time again.
> > I came across the discussion about how the hardware clock is no longer
> > set at shutdown[1]
> > The system has ntpd running
> > Looking at the output of
> >    adjtimex --print | grep status
> > the bit corresponding to 64 / STA_UNSYNC is 0
> > There is a time and date page on the wiki[2] and in the manual[3],
> > neither of them appears to have up to date information about the way it
> > works with systemd or how to troubleshoot issues like this.
> 
> My understanding from reading a bit about this just now is that the short
> version is "install ntpd if you want this to happen."
> 
> My impression is that ntpdate has been obsolete for years and upstream has
> been slowly trying to kill it.  ntpd is the upstream-supported daemon, and
> it periodically asks the kernel to set the hardware clock.

The kernel actually does the periodic setting automatically, so long as
the NTP server reports that it's synchronised (by clearing STA_UNSYNC
in timex::status).

(The kernel will only set one RTC device, which is specified in the
build config.  On systems that have multiple RTCs and only one of them
works (e.g. the one in the SoC doesn't have battery power but the one
in the PMIC does) this may not work properly.  It may be fixable by
disabling the broken RTC in the device tree.)

> (And it
> supports various command-line options to make it act like ntpdate if you
> really want.)
>
> The much simpler systemd-timesyncd doesn't set the hardware clock for
> reasons that one may or may not agree with (I honestly haven't researched
> it in any depth),

It looks like it does iff the RTC is set to UTC:

/*
 * An unset STA_UNSYNC will enable the kernel's 11-minute mode,
 * which syncs the system time periodically to the RTC.
 *
 * In case the RTC runs in local time, never touch the RTC,
 * we have no way to properly handle daylight saving changes and
 * mobile devices moving between time zones.
 */
if (m->rtc_local_time)
tmx.status |= STA_UNSYNC;

> but you can just run ntpd instead if you care.

But ntpd is also known to have a large amount of code written without
as much regard for security as one would hope.  It seems like an
unnecessary risk for most systems.

Ben.

> Alternately, if you really want to use a clock setting mechanism that
> doesn't ask the kernel to sync the hardware clock but you still want to
> set the hardware clock, you can add your own shutdown init script / unit
> to run hwclock --systohc (or even a cron job if you want).
> 
-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Daniel Pocock  writes:

> I've observed a system that had a wildly incorrect hardware clock (when
> it was first unboxed), I ran ntpdate to sync the kernel clock but after
> a shutdown and startup again it had a wacky time again.

> I came across the discussion about how the hardware clock is no longer
> set at shutdown[1]

> The system has ntpd running

> Looking at the output of
>adjtimex --print | grep status

> the bit corresponding to 64 / STA_UNSYNC is 0

> There is a time and date page on the wiki[2] and in the manual[3],
> neither of them appears to have up to date information about the way it
> works with systemd or how to troubleshoot issues like this.

My understanding from reading a bit about this just now is that the short
version is "install ntpd if you want this to happen."

My impression is that ntpdate has been obsolete for years and upstream has
been slowly trying to kill it.  ntpd is the upstream-supported daemon, and
it periodically asks the kernel to set the hardware clock.  (And it
supports various command-line options to make it act like ntpdate if you
really want.)

The much simpler systemd-timesyncd doesn't set the hardware clock for
reasons that one may or may not agree with (I honestly haven't researched
it in any depth), but you can just run ntpd instead if you care.

Alternately, if you really want to use a clock setting mechanism that
doesn't ask the kernel to sync the hardware clock but you still want to
set the hardware clock, you can add your own shutdown init script / unit
to run hwclock --systohc (or even a cron job if you want).

-- 
Russ Allbery (r...@debian.org)   

Bug#856318: ITP: imm -- Execute arbitrary actions for each unread element of RSS/Atom feeds

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?F=C3=A9lix_Sipma?= 

* Package name: imm
  Version : 1.1.0.0
  Upstream Author : k0ral 
* URL : https://github.com/k0ral/imm
* License : Public domain
  Programming Lang: Haskell
  Description : Execute arbitrary actions for each unread element of 
RSS/Atom feeds

imm is a tool to execute arbitrary actions for each new element from RSS/Atom 
feeds (e.g. sending a mail, or writing a file).

imm is written and configured in Haskell.

I'll need a sponsor for (at least) the first upload.


signature.asc
Description: PGP signature

Re: systemd, ntp, kernel and hwclock

[Santiago Vila]

On Mon, Feb 27, 2017 at 05:59:53PM +0100, Daniel Pocock wrote:

> Can anybody make any suggestions or add anything to the wiki?

My old Mac Mini had a crazy clock and ntp was not enough to sanitize it.
I fixed it by using adjtimex in addition to ntp.

As an example, my clock was off by 2890 parts per million, so I used
this in /etc/default/adjtimex:

TICK=10028
FREQ=5898240
# 28 * 100 + 5898240 / 65536 = 2890 ppm

This used to work very well, but OTOH I had my computer always on, so
I'm not sure it the cases are similar.

Thanks.

Re: sane chromium default flags - include --enable-remote-extensions

[Ian Jackson]

Andrey Rahmatullin writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> [Ian Jackson:]
> > Can we not make the updates work for non-Debian-packaged extensions,
> > while disabling them for Debian-packaged ones ?
> > 
> > If we did that then there would no need to disable people's
> > extensions.
> 
> I guess the real question is "why updating extensions was disabled
> in the first place". If chromium phones home only when non-packaged
> extensions are actually installed then it doesn't happen until the
> user installs them.

But is that actually true ?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841401#89

I don't know what `background networking' is, precisely, in this
context, but it doesn't sound like something nice.

It still seems likely to me that the problem here is a code problem,
and that people who find the current behaviour unpleasant should try
to figure out how to make the code DTRT, rather than fighting over a
bad choice between different bad default configurations.

> I'm sure there are people who would forbid the
> users from doing that but...

This is a separate question.  Ideally, as I say, Chromium would not
access external repositori(es) for extensions unless they either
contain only Free Softare, or the user has enabled Debian control
(and, presumably, installed some chromium-nonfreeapp-store package, or
something).

But certainly it should not phone home for extensions unless the user
explicitly asks to review or search for available extensions, or has
non-Debian-packages extensions installed.

Ian.

systemd, ntp, kernel and hwclock

[Daniel Pocock]

Hi all,

I've observed a system that had a wildly incorrect hardware clock (when
it was first unboxed), I ran ntpdate to sync the kernel clock but after
a shutdown and startup again it had a wacky time again.

I came across the discussion about how the hardware clock is no longer
set at shutdown[1]

The system has ntpd running

Looking at the output of
   adjtimex --print | grep status

the bit corresponding to 64 / STA_UNSYNC is 0

There is a time and date page on the wiki[2] and in the manual[3],
neither of them appears to have up to date information about the way it
works with systemd or how to troubleshoot issues like this.

Monitoring it with:

hwclock -r ; date

shows that the hardware clock is running slowly, losing maybe 1s per
hour.  I would have expected that if the kernel is syncing to the
hardware clock every 11 minutes then I wouldn't see such changes.

Can anybody make any suggestions or add anything to the wiki?

Regards,

Daniel

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755722
2. https://wiki.debian.org/DateTime
3.
https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html

Re: sane chromium default flags - include --enable-remote-extensions

[Andrey Rahmatullin]

On Mon, Feb 27, 2017 at 04:43:29PM +, Ian Jackson wrote:
> > > Do we know why this is ?  Is this an unintended side effect of some
> > > other change ?  Has someone done this deliberately and if so have they
> > > explained what they were trying to achieve ?
> > > 
> > > I can see that the behaviour you describe would be very annoying.
> >
> > When updating extensions is disabled, it is a "good" thing that you cannot
> > install them and use installed ones.
> > That's what the original bug was about.
> 
> I'm not sure I have parsed your reply correctly, so let me repeat back
> what I think you are saying:
> 
>   Since online updates to non-Debian-packaged extensions are disabled,
>   it is necessary to prevent installation or use of
>   non-Debian-packaged extensions at all: otherwise, users would be
>   running extensions without security updates.
Indeed.
#841401 is more or less this:
- my extensions cannot be updated
- that's to address some of the concern about unrequested network
  connections
- if you disable updating extensions then you should disable installing
  them too as the current situation is stupid
- done

> Well, the reasoning is sound, but this does not seem like a desirable
> situation.
That's true. That's why the usual reaction to #841401 outcome is "huh?".

> Can we not make the updates work for non-Debian-packaged extensions,
> while disabling them for Debian-packaged ones ?
> 
> If we did that then there would no need to disable people's
> extensions.
I guess the real question is "why updating extensions was disabled in the
first place". If chromium phones home only when non-packaged extensions
are actually installed then it doesn't happen until the user installs
them. I'm sure there are people who would forbid the users from doing that
but...


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: sane chromium default flags - include --enable-remote-extensions

[Ian Jackson]

Andrey Rahmatullin writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> On Mon, Feb 27, 2017 at 03:14:08PM +, Ian Jackson wrote:
> > Do we know why this is ?  Is this an unintended side effect of some
> > other change ?  Has someone done this deliberately and if so have they
> > explained what they were trying to achieve ?
> > 
> > I can see that the behaviour you describe would be very annoying.
>
> When updating extensions is disabled, it is a "good" thing that you cannot
> install them and use installed ones.
> That's what the original bug was about.

I'm not sure I have parsed your reply correctly, so let me repeat back
what I think you are saying:

  Since online updates to non-Debian-packaged extensions are disabled,
  it is necessary to prevent installation or use of
  non-Debian-packaged extensions at all: otherwise, users would be
  running extensions without security updates.

Well, the reasoning is sound, but this does not seem like a desirable
situation.

Can we not make the updates work for non-Debian-packaged extensions,
while disabling them for Debian-packaged ones ?

If we did that then there would no need to disable people's
extensions.

(Of course a user should not be invited to install extensions from an
upstream or third-party extension repository, unless that repository
contains only free software, or the user has enabled Debian contrib -
but I think that's a separate question.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: sane chromium default flags - include --enable-remote-extensions

[Andrey Rahmatullin]

On Mon, Feb 27, 2017 at 03:14:08PM +, Ian Jackson wrote:
> > It's not even about updating: the first version of chromium with this
> > build-time tweak simply disabled all already installed extensions for me
> > so they were not activated when I restarted chromium after that upgrade
> > session -- and hence were not shown in UI etc.
> > What's worse, it's futile to attemt to reinstall them: the settings tab
> > for the extensions works OK, the chromiums "extensions store" (whatever
> > its real name is, I dunno) works OK, just when you try to install an
> > extension, you get some mystical error message having nothing to do
> > with what Debian's build did, and with no hint at what to do next.
> 
> Do we know why this is ?  Is this an unintended side effect of some
> other change ?  Has someone done this deliberately and if so have they
> explained what they were trying to achieve ?
> 
> I can see that the behaviour you describe would be very annoying.
When updating extensions is disabled, it is a "good" thing that you cannot
install them and use installed ones.
That's what the original bug was about.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs

[Jeremy Stanley]

On 2017-02-25 18:24:33 +0100 (+0100), Adam Borowski wrote:
[...]
> It looks like no one made a histogram tool using high-resolution
> Braille yet, thus I'll add some features (like auto-scaling Y axis
> -- doing it manually is tedious, horizontal mode, etc) and package
> this part.
[...]

It's not packaged for Debian yet nor do I see any RFP/ITP, but I've
been happily using https://github.com/tehmaze/diagram for a few
years (installable from PyPI via pip so probably easy enough to
package). Its default mode uses 8-dot Braille patterns for axis
graphs.
-- 
Jeremy Stanley

Re: sane chromium default flags - include --enable-remote-extensions

[Ian Jackson]

Konstantin Khomoutov writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> It's not even about updating: the first version of chromium with this
> build-time tweak simply disabled all already installed extensions for me
> so they were not activated when I restarted chromium after that upgrade
> session -- and hence were not shown in UI etc.
> What's worse, it's futile to attemt to reinstall them: the settings tab
> for the extensions works OK, the chromiums "extensions store" (whatever
> its real name is, I dunno) works OK, just when you try to install an
> extension, you get some mystical error message having nothing to do
> with what Debian's build did, and with no hint at what to do next.

Do we know why this is ?  Is this an unintended side effect of some
other change ?  Has someone done this deliberately and if so have they
explained what they were trying to achieve ?

I can see that the behaviour you describe would be very annoying.

Ian.

Re: sane chromium default flags - include --enable-remote-extensions [and 1 more messages]

[Ian Jackson]

Michael Gilbert writes ("Re: sane chromium default flags - include 
--enable-remote-extensions [and 1 more messages]"):
> On Fri, Feb 24, 2017 at 10:05 AM, Ian Jackson wrote:
> > It seems likely to me that this is a bug, not some kind of
> > "ideological mistake".
> 
> You basically nailed it, especially since I don't care either way [0].
> 
> People are yelling must have safe defaults on one side.
> And people are yelling must have unsafe defaults on the other.

I looked at #856183 but I don't understand it.  What does `safe' or
`unsafe' mean ?  Are we still talking about whether to phone home for
extension updates ?

Ian.

Re: Bug#829076: general: Random freezes but the mouse can still move

[Philip Hands]

The Wanderer  writes:

> On 2017-02-26 at 09:01, Lars Wirzenius wrote:
>
>> * John Cuffs tells Lee to "shut the fuck up", and quotes a spam that
>>   isn't visible (anymore?) in the bug log.
>
> Just to note: this almost certainly wasn't actually addressing any of
> the thread participants, and also probably wasn't posted by John Cuffs.
>
> This is a standard form of spam that I've been seeing on mailing lists;
> my assessment of the form indicates that the "original" spam message was
> never actually sent, the spammer is instead sending a fake "reply" which
> quotes the spam message and has headers (etc.) as if it were a response
> by J. Random Netizen to a message already posted in some random
> thread.

I think you are mistaken.

Having seen both the noise on lists, and having on a couple of occasions
also received the same (pre-reply) directly to me, I would think that
what happens is that the spammer lifts the headers from a legitimate
list mail, and replaces its body with their drivel.

The (often rude) replies we see on the lists are almost certainly from
misguided folk who look at the headers and think that they have been
subscribed to one of our lists, and probably think that our lists are a
mechanism for sending spam -- not realising that the mail they got
actually never touched our servers, but simply copied the headers from
a genuine message.

I presume spammers are doing this because it is likely that a lot of
people have our list/bug mail as a significant contribution to the HAM
corpus in their statistical filters.

Sadly, I'm not sure there is much we can do to stop this, since it's all
happening on other people's systems, so the first we hear about it is
when someone becomes confused enough to reply angrily.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature