The HUAWEI E1750 is sold under different names, some people report it as E220 or E1752. You should check in /proc/bus/usb/devices what is the vendor and product id of your 3G modem. You should see the following values:
vendor=0x12d1 product=0x1446

This howto should apply to all 3G USB modems with the same vendor and product id and any AP running OpenWRT Kamikaze 8.09.2.
Here is how I got the whole thing running:

1. Install the required kernel modules and utilities:


# opkg update
# opkg install kmod-usb-acm kmod-usb-core kmod-usb-ohci kmod-usb-serial comgt \
kmod-usb-serial-option kmod-usb-storage kmod-usb-uhci kmod-usb2 usb-modeswitch


2. Create or edit the file /etc/modules.d/60-usb-serial so that it only contains the following line:

usbserial vendor=0x12d1 product=0x1446

3. Create or edit the file/etc/usb_modeswitch.conf so that it looks as follows:

DefaultVendor= 0x12d1
DefaultProduct=0x1446
TargetVendor= 0x12d1
TargetProductList="1001,1406,140c,14ac"
CheckSuccess=20
MessageEndpoint=0×01
MessageContent="55534243123456780000000000000011060000000000000000000000000000"


4. Add the following section to /etc/config/network:

WARNING!!! Depending on the model of your 3G modem you may need to replace ttyUSB0 with ttyUSB1, ttyUSB2, etc. Check the output of “dmesg” to know which is the correct port. If you are unsure, find out by trial-and-error.

config 'interface' 'ppp0'
option 'ifname' 'ppp0'
option 'proto' '3g'
option 'device' '/dev/ttyUSB0'
option 'apn' 'YOURAPNHERE'
option 'pincode' 'YOURPINCODEHERE'

Replace YOURAPNHERE with the name of your APN (e.g. “tre.it” for H3G Italy) and YOURPINCODEHERE with the PIN code of your SIM.

WARNING!!! If you have disabled PIN code verification for your SIM, you can omit the pincode option but you’ll need to workaround a bug in /lib/network/3g.sh. Open /lib/network/3g.sh in your editor and comment out the following lines:

# PINCODE="$pincode" gcom -d "$device" -s /etc/gcom/setpin.gcom || {
# echo "$cfg(3g): Failed to set the PIN code."
# set_3g_led 0 0 0
# return 1
# }


5. Reboot your OpenWRT device.

6. Manually run the following commands and after a minute verify that your 3G connection is working:

usb_modeswitch
ifup ppp0


7. Add the following lines to the top of /etc/rc.local:

sleep 3
/usr/sbin/usb_modeswitch
sleep 3
/sbin/ifup ppp0

8. Log on the web interface of your OpenWRT device and click on Administration/Networks/Interfaces/ppp0 and add it to the WAN zone.

You may need to adjust the DNS settings manually.

Credits: Peter Andersson

I wanted something easy to automate that. Here is a simple Automator written in AppleScript which will take care of that:

on GetPart(s, p, d)
set theList to every text item of s
return (item p of theList)
end GetPart
on run {input, parameters}

end run

Of course I wanted to also enable video automatically when answering calls from specific contacts. Fortunately Skype Extender does just that!

• LAN: 192.168.0.1 connected to eth0
• ADSL1: $IP1 connected to eth1
• ADSL2: $IP2 connected to eth2

$IP1 and $IP2 are my public IP addresses.
Their respective default gateways are $GW1 and $GW2.

I use IP source routing to accept incoming connections from $IP1 and $IP2.
This is the easy part: there is a lot of documentation (see LARTC website for the details) on how to do this, I’ll just sum it up here for completeness.


ip route add default via $GW1 table adsl1
ip rule add from $IP1 table adsl1
ip route add default via $GW2 table adsl2
ip rule add from $IP2 table adsl2
ip route add default via $GW1

echo 200 adsl1 >>/etc/iproute2/rt_tables
echo 201 adsl2 >>/etc/iproute2/rt_tables

If somebody connects to $IP1 on port 22, LinuxFW receives packets on eth1 and outgoing packets are sent through eth1, thanks to the iproute2 rules mentioned above.
Similarly, if somebody connects to $IP2 on port 22, packets enter from eth2 and exit from eth2.

So far so good. Now comes the hard part:

I added a new Linux box behind the old one, let’s call it LinuxMail. The new box has IP address 192.168.0.2 and is running Postfix. It’s connected to the same LAN switch that LinuxFW has on “eth0″.
Obviously I could install a smtp proxy on LinuxFW and redirect all emails from LinuxFW to LinuxMail, but this poses some tread-offs, i.e.:

• LinuxMail won’t be able to see the IP addresses of incoming connections directly
• LinuxMail won’t be able to do connection throttling
• LinuxMail won’t be able to reject messages for non-existant accounts

All these problems can be solved to some degree by introducing more logic on the smtp proxy of course, but let’s assume that we don’t want to do that, either because LinuxFW doesn’t have enough resources or because we want to keep things simple.
There are three solutions to this problem.

iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 25 -j DNAT --to 192.168.0.2:25
iptables -t nat -I PREROUTING -i eth2 -p tcp --dport 25 -j DNAT --to 192.168.0.2:25
iptables -t nat -A PREROUTING -i eth1 -m conntrack --ctstate DNAT --ctorigdst $IP1 -j MARK --set-mark 0x6
iptables -t nat -A PREROUTING -i eth2 -m conntrack --ctstate DNAT --ctorigdst $IP2 -j MARK --set-mark 0x7

All incoming packets with destination port 25 coming from either eth1 or eth2 will be redirected to 192.168.0.2 and marked respectively with “0×6″ and “0×7″. These iproute2 rules will take care of routing the reply packets to the appropriate interface:

ip rule add fwmark 6 table adsl1
ip rule add fwmark 7 table adsl2

Here is a simple way to open port 25 on both $IP1 and $IP2 and redirect incoming connections to LinuxMail using CONNMARK:

iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 25 -j DNAT --to 192.168.0.2:25
iptables -t nat -I PREROUTING -i eth2 -p tcp --dport 25 -j DNAT --to 192.168.0.2:25
iptables -t mangle -A PREROUTING -i eth1 -m state --state NEW,RELATED,ESTABLISHED -d $IP1 -p tcp --dport 25 -j CONNMARK --set-mark 6
iptables -t mangle -A PREROUTING -i eth0 -m connmark --mark 0x6 -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i eth2 -m state --state NEW,RELATED,ESTABLISHED -d $IP2 -p tcp --dport 25 -j CONNMARK --set-mark 7
iptables -t mangle -A PREROUTING -i eth0 -m connmark --mark 0x7 -j CONNMARK --restore-mark

Of course you will still need the usual:

ip rule add fwmark 6 table adsl1
ip rule add fwmark 7 table adsl2

Another DIY solution is to assign a second private IP address to LinuxMail. In this scenario LinuxMail has the following IP addresses:

192.168.0.2

192.168.0.3

and LinuxFW redirects incoming connections from $IP1 to 192.168.0.2 and from $IP2 to 192.168.0.3:

iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 25 -j DNAT  --to 192.168.0.2:25
iptables -t nat -I PREROUTING -i eth2 -p tcp --dport 25 -j DNAT  --to 192.168.0.3:25
iptables -t mangle -I PREROUTING -i  eth0 -s 192.168.0.2 -p tcp -j MARK --set-mark 0x6
iptables -t mangle -I PREROUTING -i eth0 -s 192.168.0.3 -p tcp -j MARK --set-mark 0x7

Of course you will still need the usual:

ip rule add fwmark 6 table adsl1
ip rule add fwmark 7 table adsl2

Credits:

LARTC: http://lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE
Pascal Hambourg: http://www.gossamer-threads.com/lists/iptables/user/68743#68743
Rodrigo Campos: http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg16307.html

IOError: [Errno 22] Invalid argument


Traceback (most recent call last):
File "/usr/bin/duplicity", line 463, in ?
with_tempdir(main)
File "/usr/bin/duplicity", line 458, in with_tempdir
fn()
File "/usr/bin/duplicity", line 444, in main
full_backup(col_stats)
File "/usr/bin/duplicity", line 155, in full_backup
bytes_written = write_multivol("full", tarblock_iter, globals.backend)
File "/usr/bin/duplicity", line 87, in write_multivol
globals.gpg_profile,globals.volsize)
File "/usr/lib64/python2.4/site-packages/duplicity/gpg.py", line 213, in GPGWriteFile
data = block_iter.next(bytes_to_go).data
File "/usr/lib64/python2.4/site-packages/duplicity/diffdir.py", line 407, in next
result = self.process(self.input_iter.next(), size)
File "/usr/lib64/python2.4/site-packages/duplicity/diffdir.py", line 487, in process
data, last_block = self.get_data_block(fp, size - 512)
File "/usr/lib64/python2.4/site-packages/duplicity/diffdir.py", line 508, in get_data_block
buf = fp.read(read_size)
File "/usr/lib64/python2.4/site-packages/duplicity/diffdir.py", line 338, in read
buf = self.infile.read(length)
IOError: [Errno 22] Invalid argument


The problem can be easily fixed by changing line no. 507 from:

read_size = min(64*1024, max_size)

to:

read_size = min(64*1024, max(max_size, 512))

The problem also occurs if you forget to pass “–exclude /selinux” to duplicity.

More info about the bug.

Vi voglio raccontare la mia esperienza con la burocrazia italiana giorno per giorno.

Giorno 1

Seguendo i consigli del sito web dell’ACI, vado al PRA di La Spezia dove trovo una signora molto stizzita che mi redarguisce sul fatto che tutta la documentazione che ho non serve a niente e che tutto quello che serve non ce l’ho. Aggiunge che l’auto va collaudata prima di fare qualunque pratica, quindi mi invita ad andare alla motorizzazione civile.

Vado alla motorizzazione civile, trovo un signore molto gentile che mi spiega che non serve nessun collaudo, che dispongo di tutta la documentazione necessaria. Mi consegna alcuni moduli da compilare e mi dà tutte le indicazioni del caso. Quando gli riferisco quanto dettomi dalla signora del PRA comincia a preoccuparsi. Mi spiega che la motorizzazione dovrà inviare il modulo NP2B, la fattura d’acquisto e il libretto dell’auto redatto secondo la legislazione italiana al PRA, in modo che il PRA possa rilasciare il CdP (Certificato di proprietà del veicolo). Tuttavia non è sicuro che al PRA tale documentazione sia sufficiente e pertanto mi invita a tornare al PRA per avere una conferma.
Nel frattempo, l’ufficio del PRA ha chiuso. Se ne riparla domani.

Giorno 2

Vado al PRA, dopo una coda immensa circondato da cittadini infuriati con Equitalia per delle multe pazze, arriva il mio turno. Spiego che ieri sono stato rimbalzato dal PRA alla motorizzazione e dalla motorizzazione al PRA e chiedo se la documentazione indicatami dalla motorizzazione sia sufficiente al PRA per rilasciare il CdP.
Vengo messo in attesa in un angolino in quanto la persona che segue questo tipo di pratiche è impegnata a giocare a Solitario nel retro dell’ufficio.

Durante l’attesa noto con meraviglia che il terminale per rilasciare feedback sulla prestazione ricevuta dallo sportello voluto dal ministro Brunetta è spento e che lì accanto campeggia un bel foglio con stampati i feedback ricevuti durante il mese precedente: un totale di 18 feedback, 100% positivi. Un po’ sospetto.

Dopo più di 30 minuti e quando ormai è l’ora di chiusura dell’ufficio, il giocatore incallito con aria scocciata si degna di considerarmi. Il suo collega gentilmente gli spiega la situazione e quello guarda con fare scocciato i fogli che gli porgo. Mi dice subito che il contratto di acquisto senza firma del venditore autenticata dal notaio non serve a niente. Gli spiego che non avevo a disposizione un notaio in Germania e per tutta risposta borbottando tra sè e sè sparisce.
Torna dopo cinque minuti e mi dice che va tutto bene (?) a parte il fatto che manca il numero di partita IVA del venditore (chiamata UST-id in Germania) e la traduzione giurata in italiano del contratto di acquisto.
Chiedo se posso usufruire del servizio di un traduttore qualunque oppure se devo rivolgermi a un traduttore ufficiale e di nuovo con fare molto scocciato mi risponde che devo andare al tribunale di La Spezia e cercare un traduttore lì.

Si è fatto tardi e il tribunale ha già chiuso al pubblico, ma decido di fare comunque un tentativo. Dopo aver vagato per una decina di minuti tra i corridoi infiniti del tribunale, finisco di fronte alla porta dell’ufficio URP sul quale campeggia un cartello enorme con su scritto in stampatello: “QUI NON SI EFFETTUANO TRADUZIONI”.
Chiedo spiegazioni ad alcuni dei pochi impiegati rimasti durante la pausa pranzo e la risposta che ottengo è la seguente: “Sei già il secondo che viene spedito qua oggi dal PRA per avere una traduzione, noi non facciamo traduzioni! Non so perchè diano queste indicazioni sbagliate. Devi trovare un traduttore e poi il traduttore deve venire in tribunale a giurare che la traduzione sia fedele. Il nostro ruolo si limita a quello”. Esattamente l’opposto di quanto riferitomi dal PRA.
Ringrazio per la gentile spiegazione e comincio a fare un giro di telefonate e alcune ricerche su Internet per trovare un libero professionista che offra il servizio di traduzione giurata/asseverata.

Prendo contatti con alcuni di loro e mi faccio fare alcuni preventivi.

Anche oggi si è fatto tardi. Trascorro il resto della giornata a cercare l’UST-id del venditore su Internet dato che al telefono non risponde. Con l’aiuto di un mio amico tedesco riesco a trovarlo.

Giorno 3

Trovo una traduttrice disposta a farmi la traduzione giurata con la massima urgenza. Le invio copia del contratto d’acquisto via e-mail. Ci accordiamo per 120 € iva inclusa e ci diamo appuntamento per Martedì mattina (oggi è Sabato) per la consegna dei documenti già corredati di traduzione giurata autenticata in Tribunale.

Giorno 4

Approfitto del weekend per compilare i moduli TT2119 e NP2B.

Nel modulo TT2119 inserisco i miei dati personali e i dati del veicolo, lasciando vuoto il campo codice veicolo. Copio il numero di omologazione dal Certificato di conformità (COC) alla voce “mit dem unter der EG-Genehmigungs Nr”.

Nel modulo NP2B compilo solo i riquadri A, B, M, R, S e all’interno del riquadro P inserisco solamente data, forma e prezzo, come indicatomi al PRA.

Giorno 5 e 6

Riposo

Giorno 7

Martedì mattina vado a ritirare la traduzione giurata del contratto d’acquisto, dopodichè mi reco all’ufficio della Motorizzazione con:

• traduzione giurata del contratto di acquisto
• modulo NP2B debitamente compilato
• modulo TT2119 debitamente compilato
• 2 fotocopie della mia carta d’identità
• Dichiarazione sostitutiva della certificazione di residenza (questo perchè la mia carta d’identità riporta un indirizzo di residenza non aggiornato)
• 2 fotocopie del mio codice fiscale
• Certificato di conformità (COC)
• ZULASSUNGSBESCHEINIGUNG TEIL I e II
• ricevute dei quattro versamenti CCP effettuati: imposta di bollo 29,24 €, IPT 514,16 €, acquisto targhe 39,71 €, diritti 9 €

Riporto all’impiegato quanto dettomi dal PRA e quello rassicurato prende il mio fascicolo, si segna il mio numero di cellulare e mi dice che verrò richiamato tra circa una settimana. Se non dovessi ricevere alcuna chiamata, dovrò farmi vivo io.

Giorno 13

Sono trascorsi sei giorni. Alle 8:30am in punto mi arriva una telefonata dalla Motorizzazione per comunicarmi che il libretto provvisorio e le targhe sono pronte. Corro alla motorizzazione e dopo una breve attesa ritiro il tutto.
L’impiegato mi spiega che il libretto provvisorio è valido per massimo 60 giorni e che quello definitivo sarà pronto tra circa 15 giorni. Una volta ottenuto il libretto definitivo dovrò recarmi al PRA con il nuovo libretto, il modulo NP2B e la traduzione giurata del contratto di vendita in modo che possano prepararmi il certificato di proprietà.
Mi riconsegna il modulo NP2B e il contratto con la traduzione cosiccome io l’avevo consegnato a lui una settimana fa e ci salutiamo. Ma non doveva pensarci la motorizzazione a spedirlo al PRA?

Tornato a casa mi accingo a montare le targhe e subito mi accorgo di un piccolo problema: le targhe anteriori in Italia sono più piccole di quelle posteriori, in Germania invece sono identiche alle posteriori!
Provo a montarle ugualmente in modo posticcio. Chissà se posso montare un portatarga più piccolo senza dover forare la carrozzeria.

Stando a quanto riferitomi alla Motorizzazione mi manca solo una cosa per poter circolare: l’assicurazione.
Faccio un paio di preventivi su www.assicurazione.it e poi ne acquisto una di slancio (quixa). Pago con carta di credito e dopo pochi minuti ho nella mia email il tagliandito da stampare, ritagliare e apporre sul parabrezza della mia auto. L’assicurazione sarà valida dalle ore 24:00 di domani, questo vuol dire che devo aspettare ancora 36h prima di poter guidare la mia nuova auto. Che efficienza :) Non mi sembra vero.

Giorno 15

È il periodo di ferragosto e sono tutti in ferie. Dopo numerose telefonate trovo finalmente un carrozziere in possesso di un portatarghe anteriore. Me la cavo con 10€ .

Giorno 35

È giunto il momento di andare a ritirare il libretto definitivo. Torno alla motorizzazione civile, presento il libretto provvisorio e mi viene consegnato quello definitivo.
Corro al PRA per presentare il modello NP2B. Attendo per l’ennesima volta l’esaurirsi dell’interminabile coda ed ecco presentarsi l’ennesimo problema.
L’impiegata si meraviglia che alla motorizzazione mi abbiano fatto il libretto senza che io abbia compilato il riquadro T e mi dice che devo assolutamente compilarlo. Spiego che l’impiegato del PRA con il quale avevo parlato poco più di due settimane fa mi aveva specificatamente indicato di lasciarlo vuoto e ottengo di tutta risposta una scrollata di spalle.
L’impiegata esamina il resto della documentazione e mi fa presente che manca la copia conforme del libretto di circolazione tedesco.
Faccio notare che quando la motorizzazione mi aveva chiesto di andare a chiedere al PRA di quale documentazione avessero bisogno, non mi era stato detto che tale documento fosse necessario. Altra scrollata di spalle.
Si è fatto tardi, ormai la motorizzazione è chiusa. Riproverò l’indomani.

Giorno 36

Vado di prima mattina alla motorizzazione civile. Riporto quanto dettomi dal PRA ovvero: il riquadro T va compilato e manca la copia conforme del libretto di circolazione tedesco.
Con aria tra lo scocciato e il compassionevole, l’impiegato della motorizzazione riempie nervosamente il riquadro T e in pochi minuti mi prepara la copia conforme del libretto di circolazione tedesco.
Mi reco al PRA e consegno tutta la documentazione. Vengo spedito per la prima volta in un ufficio interno e qui sorge un nuovo problema: il sistema non riconosce il numero di omologazione dell’auto, nonostante si tratti di una autovettura tedesca normalissima, identica a quella commercializzata in Italia. L’impiegata apre un ticket di supporto con il gestore del sistema e incredibilmente dopo appena 10 minuti il numero di omologazione viene riconosciuto. A questo punto vengo rispedito allo sportello del PRA al quale mi ero recato inizialmente e dopo varie stampe e firme vengo rispedito nuovamente all’ufficio interno dove dopo una breve attesa mi viene finalmente consegnato il Certificato di Proprietà (CdP) !

Che impresa :)

Bibliografia:
http://www.aci.it/sezione-istituzionale/per-circolare/guida-pratiche-auto/importare-un-veicolo.html
http://sosonline.aduc.it/scheda/acquistare+veicolo+all+estero_14732.php
http://forums.ebay.it/thread.jspa?threadID=500004342
http://www.consinfo.eu/help/libretto-circolazione-norme-euro

Here is what I had to do to make the USB modem work with Fonera 2.0N:

• for some crazy reason, my 3G modem refuses to work on Fonera 2.0N if there are some SMS stored on it. Plug the 3G modem into your PC and remove any SMS you may have received. YMMV.
• upgrade your Fonera 2.0N to the latest 2.3.6.0 firmware, choosing the “developer” image. You need the developer version to ssh into your Fonera 2.0N.
• ssh into your Fonera 2.0N router.
• edit /etc/config/umtsd:

config 'umtsd' 'umtsd'
 option '_country' '_custom'
 option 'apn' 'replacewithyourapn'
config 'umtsdstate' 'umtsdstate'
config 'umtsdevice' 'option12D11465'
 option 'vendor' 'Huawei'
 option 'device' 'K3765'
 option 'data' '/dev/ttyUSB0'

 option 'cmd' '/dev/ttyUSB0'

• plug the HUAWEI K3765 into the Fonera 2.0N router
• wait a few seconds and then run:

  echo "0x12d1 0x1465" >/sys/bus/usb-serial/drivers/option1/new_id

Visit http://fonera/luci/fon_devices/fon_umts and check the status of your 3G modem.

If it still doesn’t work, you may have to follow the instructions provided by stex1967:

Create the file /etc/usb-modeswitch.conf with the following content:

DefaultVendor= 0x12d1
DefaultProduct= 0x1520
TargetVendor= 0x12d1
TargetProduct=0x1465
MessageContent="55534243123456780000000000000011060000000000000000000000000000"


Also create the file /etc/rc.d/k3765:


#!/bin/sh /etc/rc.common
START=90
usb_modeswitch
sec=2
sleep $sec
echo "0x12d1 0x1465" >/sys/bus/usb-serial/drivers/option1/new_id


Finally run:


chmod 755 /etc/init.d/k3765
/etc/init.d/k3765 enable


and reboot. Thumbs up!

An updated list of supported 3G USB modems is available at http://wiki.fon.com/wiki/3G_compatibility

There is no need to flash a new firmware on it, just uninstall the Vodafone Mobile Connect software and replace it with the standard one from HUAWEI: you will be able to configure the software to use any APN you like.

You’ll still experience a small glitch though, at least under MacOSX: everytime you plug the modem into the USB port, you will see a popup asking you to install Vodafone Mobile Connect.

There is a simple solution to this problem:

• find out the UUID of your USB stick: diskutil info /Volumes/Vodafone\ Mobile\ Broadband/ | grep UUID
• create a new entry for this disk in /etc/fstab with the noauto flag turned on:
  • open /etc/fstab in your favourite editor (create it if it doesn’t exist yet): sudo vi /etc/fstab
  • add a line like the following to /etc/fstab:
    UUID=A46AA80A-97B9-3B47-91A4-8128A9458A31 none hfs rw,noauto 0 0

Replace the UUID with your own UUID.

Thumbs up! Now unplug your USB stick and plug it again: no annoying popup this time!

Contents

1. Long story short
2. Short story long
   1. The problem with filtering spam
   2. Premises
   3. The big picture
   4. Howto
      1. Postfix
      2. Dovecot
      3. Amavisd-new
   5. Purging old spam messages
   6. Conclusions
      1. Bibliography

This is a short summary for those who don’t need a pedantic step by step guide. If you want to know all the details, you should skip to the next section.

My objective is to deliver all spam messages to a dedicated IMAP folder called “spam”. This way my users can easily fetch messages which get erroneously identified as spam. Here is how I did it.

I configured Amavisd-new to deliver spam messages to a specific address extension (e.g. user+spam@domain.tld) using the $addr_extension_spam directive. Here I had my first problem: Amavisd-new ignores this directive for all domains which are not considered local. Therefore you have to tell Amavisd-new which domains are local or the whole thing WON’T WORK.

You have two options:

• statically define the list of local domains using @local_domains_acl
• if your account information is stored in MySQL database, tell Amavisd-new to fetch the list of local domains using a SQL query, like the following: $sql_select_policy = ‘SELECT “Y” as local FROM domain WHERE CONCAT(“@”,domain) IN (%k)’;

Next step is to configure the LDA (Local Delivery Agent) to deliver all messages with a specific address extension to a specific subfolder of the respective mailbox. This can be achieved by changing the LDA used by Postfix from Postfix itself to something which allows for rule filtering like procmail, maildrop or Dovecot.

If your mailboxes are also “system accounts”, you should stick to procmail or maildrop, which are fairly easy to setup. For example, with procmail you would use:

mailbox_command = procmail -a “$EXTENSION”

and then setup a .procmailrc which delivers mails for messages matching ARG ?? ^^spam^^ to a specific subfolder.

If you have a virtual users setup this gets tricky. The directive which defines the LDA for virtual accounts in main.cf is virtual_transport.

In a virtual users setup which relies on a MySQL backend, the easiest LDA to configure is Dovecot. We have to create a new “transport” inside master.cf like this:

dovecot      unix    -    n    n    -    -    pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop} -n -m ${extension}

And then reference it inside main.cf using the aforementioned virtual_transport directive (virtual_transport = dovecot).

Finally you must enable the sieve plugin in the lda section of dovecot.conf:

sieve_global_path = /var/lib/sieve/default.sieve
mail_plugins = cmusieve

and create the default.sieve script with the following content:

if envelope :detail "to" "spam"{
 fileinto "spam";
}

That’s all folks!

Here is an exhaustive description of this setup, with many useful hints to solve common problems.

Filtering spam is a endless battle. Spam filters are prone to false positives and SpamAssassin is no exception.

That’s why we usually configure our mail servers to quarantine spam messages, instead of rejecting/deleting them.

Here comes what I usually refer to as “the quarantine problem”.

Unfortunately most content filters tend to put all quarantined messages in a single directory which can only be accessed by the sysadmin. Then sysadmins get hammered by questions like this all the time: “I didn’t receive the e-mail from XYZ, can you check if it’s been quarantined by the spam filter?”

Users are angry because they have to wait to receive their “very-important” email, sysadmins are angry because they have to waste their time on a monkey activity. Nobody likes the “quarantine spam messages in a single directory” strategy.

Many solutions have been proposed to allow users to retrieve spam messages from the quarantine directory by themselves: the most successful was Maia Mailguard (http://www.maiamailguard.com/maia/wiki), which is now replaced by MailZu (http://sourceforge.net/projects/mailzu/).

Unfortunately all these solutions are quite clumsy to setup, they do not scale very well and they can be a pain to maintain.

Content filters also allow to only tag messages as spam, and deliver them to the user’s mailbox together with regular messages, but users don’t like this solution for two reasons:

• they have to download spam messages anyway (which can be expensive when roaming)
• they have to setup filters on their MUAs to store spam messages in a separate folder (which can be difficult to do on mobiles)

There is a simple solution to “the quarantine problem” which exploits the power of IMAP to have different folders in a single mailbox.

Here is the strategy we are going to adopt in this article:

• the first time a user accesses his mailbox via IMAP, a new folder called “INBOX.spam” is created.
• whenever a message is tagged as spam, it’s delivered to the address: user+spam@domain.tld instead of user@domain.tld
• if the subfolder INBOX.spam exists, the messages is stored under INBOX.spam instead of INBOX. If the subfolder doesn’t exist, the message is delivered to INBOX.
• messages in the INBOX.spam folder older than 60 days are automatically deleted.

If the user wants to check whether his very-important email was marked as spam, he can just open the Spam folder and try to find it. Normally he won’t need to download spam messages.

If he is using only POP3 to access his email, this “quarantine” system won’t be activated and he’ll have to rely on his MUA’s filters to store the spam in a separate folder.

Alternatively, the sysadmin can provide him with a webmail which uses the IMAP protocol.

In this howto we assume to be running the following software:

• MTA: Postfix with virtual users served off a MySQL database
• LDA: Dovecot delivery agent with sieve plugin
• POP3/IMAP: Dovecot
• Content filter: Amavisd-new
• Spam filter: SpamAssassin

Configuring Postfix for virtual users stored in a MySQL database is out of the scope of this howto. There is plenty literature available on Postfix Website (http://www.postfix.org/docs.html) and official documentation (http://www.postfix.org/MYSQL_README.html).

The integration of Amavisd-new into Postfix is trivial as well and there are already plenty of howtos available.

Finally we assume Dovecot is already configured to authenticate users using the MySQL database. Many howtos already describe how to implement this and it’s also described in the official documentation of Dovecot (http://wiki.dovecot.org/AuthDatabase/SQL).

We shall assume that you have a working setup with virtual domains stored on MySQL database.

Here is how the whole thing is going to work:

1. an email comes in, via SMTP
2. Postfix check if the mailbox exists and passes it to Amavisd-new
3. Amavisd-new checks if the email is spam. Then it checks if the recipient of the email is a local domain or not. If both conditions are true, then the message recipient address (user@domain.tld) is replaced with user+spam@domain.tld. In all other cases (e.g. if domain.tld is not a local domain) the recipient address is left untouched.
4. Amavisd-new passes the email back to Postfix
5. Postfix passes the email to the LDA. As reported in the “Premises” paragraph, in our case Dovecot acts also as a LDA, not only as POP3/IMAP server!
6. Dovecot uses the default sieve rules to decide where to store the message. If the recipient of the message contains a “spam” extention (like in the case of user+spam@domain.tld) and the INBOX.spam subfolder exists, then the message is delivered to user@domain.tld under then INBOX.spam subfolder. In all other cases (that is if the recipient is user@domain.tld or INBOX.spam doesn’t exist) the message is delivered to INBOX.

You will then need to change the following lines in /etc/postfix/main.cf:

mailbox_command = /usr/lib/dovecot/deliver
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
recipient_delimiter = +

and add the following line to /etc/postfix/master.cf:

dovecot      unix    -    n    n    -    -    pipe
 flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop} -n -m ${extension}

This is needed to make Postfix use Dovecot as the LDA. We need to switch to Dovecot as LDA because it has support for sieve rules. Using these rules we can decide in which folder to store a message based on a certain condition.

We have to tell Dovecot to automatically create the subfolder “Spam” on the first time the user accesses the mailbox via IMAP. For this we need to enable the autocreate plugin:

protocol imap {
 mail_plugins = quota imap_quota autocreate
}

plugin {
 autocreate = spam
 autosubscribe = spam
}

Next step is to enable the cmusieve plugin and configure Dovecot to apply a special rule to all messages processed by the delivery agent (LDA):

protocol lda {
 sieve_global_path = /var/lib/sieve/default.sieve
postmaster_address = <postmaster-address>
 auth_socket_path = /var/run/dovecot/auth-master
 mail_plugins = quota cmusieve
 sendmail_path = /usr/sbin/sendmail
}

In our case the filtering rule is stored inside /var/lib/sieve/default.sieve:

require ["fileinto", "envelope", "subaddress"];
if envelope :detail "to" "spam"{
 fileinto "spam";
}

Be aware that the file /var/lib/sieve/default.sieve is compiled by Dovecot the first time it’s used. Dovecot must store the binary version of this file (/var/lib/sieve/default.sievec) in the same dir as the script so it requires write access to the directory /var/lib/sieve/.

Dovecot delivery agent is called by Postfix and Postfix uses the uid/gid specified in /etc/postfix/main.cf to run it. In my case this is uid 2000 / gid 2000. Check your main.cf for the correct values, look for the lines:

virtual_uid_maps = static:<UID>
virtual_gid_maps = static:<GID>

Then make sure that /var/lib/sieve/ is owned by the same uid/gid specified above. If everything is ok, when the first email comes in, Dovecot will create a new file called /var/lib/sieve/default.sievec.

You can check the syntax of the file default.sieve on this nice online sieve compiler: http://libsieve-php.exit0.net/.

Depending on the distro you are using, your Amavisd-new config file can come as a single config. file called amavisd.conf or multiple small config files which are loaded sequentially.

In my case I’m using Debian Lenny and I store all my customized Amavisd-new settings inside /etc/amavis/conf.d/50-user .

Here is what must be modified in the standard Amavisd-new configuration:

$sa_tag_level_deflt  = 5.0;  # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 7.31; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 10.31; #10.31; # triggers spam evasive actions
$sa_dsn_cutoff_level = 15;  # spam level beyond which a DSN is not sent
$sa_spam_report_header = 1;
@addr_extension_spam_maps       = ('spam');
$replace_existing_extension = 1;        # (default is false)
$recipient_delimiter = '+';
@lookup_sql_dsn =
 ( ['DBI:mysql:database=yourpostfixdb;host=127.0.0.1;port=3306', 'yourpostfixuser', 'yourpass'] );
$sql_select_policy = 'SELECT "Y" as local FROM domain WHERE CONCAT("@",domain) IN (%k)';
$localpart_is_case_sensitive = 0;        # (default is false)
$final_spam_destiny       = D_PASS;

Note for SysCP users: if you are running SysCP the correct query is SELECT “Y” as local FROM panel_domains WHERE CONCAT(“@”,domain) IN (%k).

The $sa_* config items are pretty much self explanatory: you can tune their values to your likening. If SpamAssassin assigns a score higher than sa_tag2_level_deflt to the message, it will be delivered to the user’s INBOX.spam subfolder.

The @addr_extension_spam_maps directive (together with $replace_existing_extension and recipient_delimiter) tells Amavisd-new to rewrite the recipient address of spam messages from user@domain.tld to user+spam@domain.tld .

The @lookup_sql_dsn directive tells Amavisd-new how to connect to the MySQL database used by Postfix to lookup the local domains, mailboxes, and aliases.

The $sql_select_policy directive contains a MySQL query which fetches the list of local domains from the MySQL database used by Postfix. Depending on your Postfix setup you may need to change the query so that it returns “Y” if the domain (%k) is listed inside the “domain” table.

CAVEAT: THIS IS CRITICAL TO MAKE THE SETUP WORK!!! If Amavisd-new doesn’t know that the domain is a local one, IT WON’T CHANGE THE RECIPIENT ADDRESS TO user+spam@domain.tld . The email will always be delivered to user@domain.tld and stored inside INBOX instead of INBOX.Spam.

Amavisd-new only modifies the original message if both the following conditions are met:

• the domain is known to be a local domain
• the spam score is higher sa_tag2_level_deflt
  

The $localpart_is_case_sensitive directive, when set to false, tells Amavisd-new to treat domain names as case insensitive.

Finally, $final_spam_destiny  tells Amavisd-new to deliver spam messages instead of simply quarantine/reject them.

The INBOX.spam subfolders will tend to grow with time. We want to setup a cronjob which purges messages older than 60 days. Assuming that our virtual mailboxes are stored under /var/mail/virtual, we may use add to crontab something like this:

0 0 * * * find /var/mail/virtual/ -name .spam -type d -exec find {} -mindepth 1 -type f -ctime +60 -delete \;

Thumbs up! We are done :)
Please send me your comments if something is not clear or not working as expected!

• http://www.ijs.si/software/amavisd/README.lookups.txt
• http://wiki.dovecot.org/LDA/Sieve#Validate_your_script
• http://wiki.dovecot.org/LDA/Postfix

Quoto a titolo d’esempio un articolo comparso su SicurAuto:

ISOFIX Universal: questa scritta si riferisce alla compatibilità del seggiolino con qualsiasi automobile (universal)

La frase porta a credere che se il seggiolino è marchiato come “ISOFIX universal” allora è compatibile con qualunque automobile dotata di agganci ISOFIX. Niente di più falso!

Anzi, è proprio l’opposto. In generale i seggiolini ISOFIX semi-universal sono compatibili con più modelli di auto rispetto agli ISOFIX universal!

Se il seggiolino è marchiato come “ISOFIX universale” significa che richiede un terzo punto di aggancio sul retro del sedile, detto top tether. Per installare correttamente questo tipo di seggiolini occorre quindi utilizzare:

2 punti di aggancio sulla base del sedile, fissati direttamente sugli appositi ganci che spuntano dalla scocca dell’auto.

Un terzo punto d’aggancio, comunemente chiamato top-tether e solitamente posizionato sul retro del sedile o vicino al poggiatesta, come nelle presenti foto:

top tether for ISOFIX universal

Qui cominciano i problemi: le prime auto con attacchi ISOFIX introdotte in Italia (fino al 2005-2006) non dispongono di questo terzo attacco top tether e quindi non sono adatte all’utilizzo con seggiolini ISOFIX universale!

Al contrario i seggiolini ISOFIX semi-universali sono utilizzabili su questo tipo di autovetture in quanto dispongono di una speciale gamba-piedistallo che si fissa sotto al sedile e supplisce all’assenza dell’attacco top-tether.

Un seggiolino ISOFIX universale o semi-universale montato utilizzando solo i due ancoraggi alla base, ovvero senza top tether e senza gamba-piedistallo aggiuntiva, è in generale persino meno sicuro di un seggiolino tradizionale sprovvisto di attacchi ISOFIX in quanto in caso di incidente può essere soggetto a ribaltamento!

I due punti di ancoraggio alla base del sedile non sono sufficienti, da soli, a garantire la stabilità del seggiolino.

Non fidatevi quindi di chi cerca di vendervi un seggiolino ISOFIX dicendovi che il terzo attacco è opzionale o inutile! Sta mettendo a serio rischio la sicurezza del vostro bambino.

In this case, using du is not practical. Here is a simple awk one-liner that will sum the size of all files under /path that are older than 90 days:

find /path/ -type f -mtime +90 -printf "%s\n"|awk '{sum+=$0}END{print sum}'

Enjoy!