Re: rbl's status?
Bernd Eckenfels wrote: In article <[EMAIL PROTECTED]> you wrote: This sort of thing is why I would rather use any RBL within SpamAssassin, rather than at SMTP delivery time. Even if one of these services goes completely belly up and blacklists the world, I don't automatically lose mail from it. Please dont do this. You MUST reject mails (by spam scanners, malware scanners or blacklists) on the SMTP level, otherwise you become a pretty big annoyance to the internet (if you bounce) or will siletnly lose mails (if you drop them). Bouncing or silently dropping potential spam are both obnoxious net behavior, but neither has anyhing to do with whether or not one does their spam classification before accepting mail at the SMTP level. Rejecting false positives can be pretty annoying, too! I find rejecting potential spam at the SMTP level to be riskier than I'd prefer, but this is a judgment call that sysadmins need to make based on the needs of their users. Neither choice forces poor netiquette. Matthew
Re: rbl's status?
Bernd Eckenfels wrote: In article <[EMAIL PROTECTED]> you wrote: This sort of thing is why I would rather use any RBL within SpamAssassin, rather than at SMTP delivery time. Even if one of these services goes completely belly up and blacklists the world, I don't automatically lose mail from it. Please dont do this. You MUST reject mails (by spam scanners, malware scanners or blacklists) on the SMTP level, otherwise you become a pretty big annoyance to the internet (if you bounce) or will siletnly lose mails (if you drop them). Bouncing or silently dropping potential spam are both obnoxious net behavior, but neither has anyhing to do with whether or not one does their spam classification before accepting mail at the SMTP level. Rejecting false positives can be pretty annoying, too! I find rejecting potential spam at the SMTP level to be riskier than I'd prefer, but this is a judgment call that sysadmins need to make based on the needs of their users. Neither choice forces poor netiquette. Matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Procmail recipe for Nitwit unsubscribers who can't read DU sigs.
Don't pipe to /dev/null just yet -- I've had five false positives since
implementing it this morning!
I can provide procmail log entries (although not the actual emails -- I
/dev/null-ed prematurely) if you'd like. I'm going to leave the filter
in place, but pipe them to a folder instead so that I can debug.
Matthew Whitworth
s. keeling wrote:
FYI, procmail users: This appears to work fairly well so far; fwiw:
#
# inept mailing list (un)su[b]?scribe attempts, and "vacation" dorks.
#
:0 HB
* 1^0 ()(I will be out of the office|I will respond to your message when I
return\.)
* 1^0 ^Subject:.*(un)?su(b)?(s)?cribe
* 1^0 $ ^^${SPCNL}*(un)?su(b)?scribe
* -1^0 ^Subject:.*Re:
{
LOG="(Un)?subscriber - "
:0
/dev/null
}
Re: Procmail recipe for Nitwit unsubscribers who can't read DU sigs.
Don't pipe to /dev/null just yet -- I've had five false positives since
implementing it this morning!
I can provide procmail log entries (although not the actual emails -- I
/dev/null-ed prematurely) if you'd like. I'm going to leave the filter
in place, but pipe them to a folder instead so that I can debug.
Matthew Whitworth
s. keeling wrote:
FYI, procmail users: This appears to work fairly well so far; fwiw:
#
# inept mailing list (un)su[b]?scribe attempts, and "vacation" dorks.
#
:0 HB
* 1^0 ()(I will be out of the office|I will respond to your message when I return\.)
* 1^0 ^Subject:.*(un)?su(b)?(s)?cribe
* 1^0 $ ^^${SPCNL}*(un)?su(b)?scribe
* -1^0 ^Subject:.*Re:
{
LOG="(Un)?subscriber - "
:0
/dev/null
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
time zone whackiness with snort/postgresql...
I just set up a Debian snort sensor logging to a postgresql database (on the same host) and noticed that the alerts in the database have timestamps seven hours earlier than their timestamps in the snort alert file. The seven hours is interesting because that's my current offset from GMT -- only in the opposite direction! Here are two views of the same sets of alerts: # grep ":51:" /var/log/snort/alert 08/07-06:51:07.353985 64.52.50.201:1511 -> xx.xx.xx.xx:80 08/07-06:51:07.454513 64.52.50.201:1511 -> xx.xx.xx.xx:80 08/07-17:51:46.835660 204.60.156.2:3401 -> xx.xx.xx.xx:80 08/07-17:51:50.357658 204.60.156.2:3413 -> xx.xx.xx.xx:80 08/07-17:51:53.848363 204.60.156.2:3429 -> xx.xx.xx.xx:80 08/07-17:51:54.383995 204.60.156.2:3433 -> xx.xx.xx.xx:80 08/07-17:51:54.988612 204.60.156.2:3436 -> xx.xx.xx.xx:80 08/07-17:51:56.545477 204.60.156.2:3439 -> xx.xx.xx.xx:80 08/07-17:51:57.016801 204.60.156.2:3441 -> xx.xx.xx.xx:80 08/07-17:51:57.529523 204.60.156.2:3443 -> xx.xx.xx.xx:80 $ psql snortdb -c "select * from event;" | grep ":51:" 1 | 36 |11 | 2003-08-06 23:51:07-07 1 | 37 | 5 | 2003-08-06 23:51:07-07 1 | 53 |16 | 2003-08-07 10:51:46-07 1 | 54 |16 | 2003-08-07 10:51:50-07 1 | 55 |16 | 2003-08-07 10:51:53-07 1 | 56 |16 | 2003-08-07 10:51:54-07 1 | 57 |16 | 2003-08-07 10:51:54-07 1 | 58 |16 | 2003-08-07 10:51:56-07 1 | 59 |16 | 2003-08-07 10:51:57-07 1 | 60 |16 | 2003-08-07 10:51:57-07 Interestingly, postgresql knows what the real system time is: $ date && psql snortdb -c "select now();" Thu Aug 7 22:57:41 PDT 2003 now --- 2003-08-07 22:57:41.457929-07 (1 row) The hardware clock is set to GMT and the OS is set to use the PST8PDT time zone. I'm using the snort-pgsql 2.0.0 and postgresql 7.3.2 packages currently in the "testing" branch. Anyone ever seen anything like this? Thanks in advance, Matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
time zone whackiness with snort/postgresql...
I just set up a Debian snort sensor logging to a postgresql database (on the same host) and noticed that the alerts in the database have timestamps seven hours earlier than their timestamps in the snort alert file. The seven hours is interesting because that's my current offset from GMT -- only in the opposite direction! Here are two views of the same sets of alerts: # grep ":51:" /var/log/snort/alert 08/07-06:51:07.353985 64.52.50.201:1511 -> xx.xx.xx.xx:80 08/07-06:51:07.454513 64.52.50.201:1511 -> xx.xx.xx.xx:80 08/07-17:51:46.835660 204.60.156.2:3401 -> xx.xx.xx.xx:80 08/07-17:51:50.357658 204.60.156.2:3413 -> xx.xx.xx.xx:80 08/07-17:51:53.848363 204.60.156.2:3429 -> xx.xx.xx.xx:80 08/07-17:51:54.383995 204.60.156.2:3433 -> xx.xx.xx.xx:80 08/07-17:51:54.988612 204.60.156.2:3436 -> xx.xx.xx.xx:80 08/07-17:51:56.545477 204.60.156.2:3439 -> xx.xx.xx.xx:80 08/07-17:51:57.016801 204.60.156.2:3441 -> xx.xx.xx.xx:80 08/07-17:51:57.529523 204.60.156.2:3443 -> xx.xx.xx.xx:80 $ psql snortdb -c "select * from event;" | grep ":51:" 1 | 36 |11 | 2003-08-06 23:51:07-07 1 | 37 | 5 | 2003-08-06 23:51:07-07 1 | 53 |16 | 2003-08-07 10:51:46-07 1 | 54 |16 | 2003-08-07 10:51:50-07 1 | 55 |16 | 2003-08-07 10:51:53-07 1 | 56 |16 | 2003-08-07 10:51:54-07 1 | 57 |16 | 2003-08-07 10:51:54-07 1 | 58 |16 | 2003-08-07 10:51:56-07 1 | 59 |16 | 2003-08-07 10:51:57-07 1 | 60 |16 | 2003-08-07 10:51:57-07 Interestingly, postgresql knows what the real system time is: $ date && psql snortdb -c "select now();" Thu Aug 7 22:57:41 PDT 2003 now --- 2003-08-07 22:57:41.457929-07 (1 row) The hardware clock is set to GMT and the OS is set to use the PST8PDT time zone. I'm using the snort-pgsql 2.0.0 and postgresql 7.3.2 packages currently in the "testing" branch. Anyone ever seen anything like this? Thanks in advance, Matthew
Re: activating an unconfigured interface using /etc/network/interfaces...?
Complained, but worked: dumb:~# ifup eth1 SIOCSIFNETMASK: Cannot assign requested address dumb:~# ifconfig eth1 Link encap:Ethernet HWaddr 00:03:47:08:A5:44 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:133345 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:76747137 (73.1 MiB) TX bytes:0 (0.0 b) Interrupt:10 Base address:0x8000 ... Thanks tons! Matthew Keegan Quinn wrote: Hello Matthew, On Wed, Jul 23, 2003 at 10:34:32PM -0700, Matthew Whitworth wrote: I have a dual-homed host spanning two networks and I would like to leave one of its interfaces unconfigured so that I can use libpcap applications on that network unobserved. I can do this using the command string "ifconfig eth1 0.0.0.0 up", but I was wondering if there was a way to do this using the /etc/network/interfaces file and the ifup/ifdown commands. If there is, I can't seem to get the syntax. I use the following syntax, to bring up a MiniPCI wireless network interface with no address, so it can be added to a bridge. Different purpose but same idea, I think. auto wlan0 iface wlan0 inet static address 0.0.0.0 netmask 255.255.255.254 Nothing actually gets added to the routing table, AFAICT, but it's necessary to specify a netmask to stop ifupdown from complaining. HTH, - Keegan
Re: activating an unconfigured interface using /etc/network/interfaces...?
Complained, but worked: dumb:~# ifup eth1 SIOCSIFNETMASK: Cannot assign requested address dumb:~# ifconfig eth1 Link encap:Ethernet HWaddr 00:03:47:08:A5:44 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:133345 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:76747137 (73.1 MiB) TX bytes:0 (0.0 b) Interrupt:10 Base address:0x8000 ... Thanks tons! Matthew Keegan Quinn wrote: Hello Matthew, On Wed, Jul 23, 2003 at 10:34:32PM -0700, Matthew Whitworth wrote: I have a dual-homed host spanning two networks and I would like to leave one of its interfaces unconfigured so that I can use libpcap applications on that network unobserved. I can do this using the command string "ifconfig eth1 0.0.0.0 up", but I was wondering if there was a way to do this using the /etc/network/interfaces file and the ifup/ifdown commands. If there is, I can't seem to get the syntax. I use the following syntax, to bring up a MiniPCI wireless network interface with no address, so it can be added to a bridge. Different purpose but same idea, I think. auto wlan0 iface wlan0 inet static address 0.0.0.0 netmask 255.255.255.254 Nothing actually gets added to the routing table, AFAICT, but it's necessary to specify a netmask to stop ifupdown from complaining. HTH, - Keegan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
activating an unconfigured interface using /etc/network/interfaces...?
I have a dual-homed host spanning two networks and I would like to leave one of its interfaces unconfigured so that I can use libpcap applications on that network unobserved. I can do this using the command string "ifconfig eth1 0.0.0.0 up", but I was wondering if there was a way to do this using the /etc/network/interfaces file and the ifup/ifdown commands. If there is, I can't seem to get the syntax. Thanks, Matthew
activating an unconfigured interface using /etc/network/interfaces...?
I have a dual-homed host spanning two networks and I would like to leave one of its interfaces unconfigured so that I can use libpcap applications on that network unobserved. I can do this using the command string "ifconfig eth1 0.0.0.0 up", but I was wondering if there was a way to do this using the /etc/network/interfaces file and the ifup/ifdown commands. If there is, I can't seem to get the syntax. Thanks, Matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
