Spamassassin végre ténylegvégleg?

Magam is nehezen hiszem, de úgy tűnik, hogy végre végleg, hákolás nélkül megoldódik a spamassassin para. Nem tudom, hogy kerülte el a figyelmemet a következő két kapcsoló:

-u username, –username=username

Run as the named user. If this option is not set, the default behaviour is to setuid() to the user running „spamc”, if „spamd” is running as root. Note: „–username=root” is not a valid option. If specified, „spamd” will exit with a fatal error on startup.

-g groupname, –groupname=groupname

Run as the named group if –username is being used. If this option is not set when –username is used then the primary group for the user given to –username is used.

Fellelési helye: „man spamd”. Néha nem árt doksit olvasgatni.

Update: Azért a dolog nem ilyen egyszerű, a –username=… beállítással nyakadba kapod azt a problémát, hogy a spamd által forkolt child process nem tud írni az adott user home-jába (hiszen nem setuid fut, hanem egy tökmás user nevében), ezért ha a spamd a –create-prefs kapcsolóval indul, akkor emailenként 3 hibát biztos dob. Megoldás: –create-prefs kiszedése a /etc/default/spamassassin-ból. (És persze pl. –username=amavis beleírása.)

Update 2: Még egy dolgot kell kiszedni, ez pedig az AutoWhitelist. Az ok ugyanaz: mivel amavis-ként fut a spamassassin, nem tudja írni/olvasni az user mail home-jában található személyes autowhitelisteket. A /etc/spamassassin/v310.pre file-ban ezt kommenteztem ki:

loadplugin Mail::SpamAssassin::Plugin::AWL

Webcal fiasco.

Rövid próbálkozás a Webcalendar fejlesztői verziójával, ami már oda-vissza ical syncet meg mindent tud. (Ne gyere a Google Calendarral, szarok rá.) Almost there, but not yet there. Az 1.1.2-es verzió még nem az igazi.

RBL fine tune: Sorbs off the list.

A Sorbs bekattant. Az egyik legrégebben konfigban levő blacklist ez nálam (blacklist előzmények itt és itt), eddig sose volt vele semmi baj, de pár napja eldob egy csomó gmail.com és hotmail.com IP-ről jövő emailt. Röviden: mennie kell, a konfigból kiszedtem, amíg meg nem gondolják magukat, az okozott kellemetlenségért elnézést kérek.

Hogy ne maradjon ennyiben a dolog, írtam nekik (akkor még csak egy random gmail.com IP-vel kapcsolatban), hátha csak félreértésről van szó: tény, hogy sok smap jön gmail.com-ról, és még több a hotmail.com-ról, elképzelhető tehát, hogy csak rövid időre véletlenül belekerül 1-1 IP a RBL-be. A válaszuk eloszlatta ezeket a kételyeket:

...
The reason it is listed is that we have received spam from many other Gmail
users.

The listing will go away once  Gmail indicate that they are doing
something to stop the spamming. Terminating the spammers when complaints
come in would be a great start, (there is no reason  for anybody to
be propagating West African advance fee fraud, stock  pump and dump,
lottery fraud, or phishing spam in this day and age), but that alone
is not enough.

Gmail has received numerous complaints on the spam, most apparently
originating
in Nigeria, but Gmail does not prevent the spam. The way our system
works is that
we list spamming IP addresses when spam comes in. As a result, if Gmail
administration are not prepared to take such action, the best result
that can be hoped for is an endless game of whack-a-mole which is not a
productive use of the time of SORBS volunteers nor Gmail administration.

We are sorry for the inconvenience caused to legitimate Gmail users, but
we need to protect our own systems, (and the systems of anybody who
voluntarily chooses to use our data), from spam and operators who do not
take adequate steps to prevent the delivery thereof from their systems
to the outside world.

Egyenes beszéd, és nem tudom, mit tennék a Sorbs helyében hasonló helyzetben. A saját helyemben viszont sajnos ez azt jelenti, hogy mostantól határozatlan ideig eggyel kevesebb sor van az RBL konfigban.