Spam detection software, running on the system "itmustbe.luv.asn.au", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  James Harper writes: > Just a curiousity... I'm nc-ing a disk
   image from a laptop, like: > gzip </dev/sda | nc target 4242 > and on the
   target computer: > nc -l -p 4242 | gunzip | dd bs=4k conv=sparse 
of=laptop-xp.img
   > and on the target computer I am also impatiently doing: > du -sk 
--apparent-size
   laptop-xp.img && du -sk laptop-xp.img > and the output is a bit strange.
  > [boring numbers...] > What's with that? The filesystem is btrfs but I don't
   know that that's anything to do with it. [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.1 FH_HELO_EQ_D_D_D_D     Helo is d-d-d-d
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail 
provider
                            (trentbuck[at]gmail.com)
 0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
 1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS
 3.2 HELO_DYNAMIC_IPADDR    Relay HELO'd using suspicious hostname (IP addr
                            1)
 0.0 T_TO_NO_BRKTS_FREEMAIL T_TO_NO_BRKTS_FREEMAIL
 0.0 TO_NO_BRKTS_NORDNS     To: misformatted and no rDNS


--- Begin Message ---
James Harper <[email protected]>
writes:

> Just a curiousity... I'm nc-ing a disk image from a laptop, like:
> gzip </dev/sda | nc target 4242
> and on the target computer:
> nc -l -p 4242 | gunzip | dd bs=4k conv=sparse of=laptop-xp.img
> and on the target computer I am also impatiently doing:
> du -sk --apparent-size laptop-xp.img && du -sk laptop-xp.img
> and the output is a bit strange.
> [boring numbers...]
> What's with that? The filesystem is btrfs but I don't know that that's 
> anything to do with it.

Try HUPping the dd instead (or use gddrescue) to find out how much IT
thinks is written.  btrfs is probably just being weird in what it tells
df/du -- I see that a lot.


--- End Message ---
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main

Reply via email to