Patch di qmail

22 maggio 2022 Roberto Puzzanghera 18 commenti

• Scarica l'ultima versione della patch combinata per netqmail-1.06 v. 2022.05.22 (MD5).
• Changelog
• Readme

Changelog

• May 22, 2022
  "qmail-smtpd pid, qp log" patch (http://iain.cx/qmail/patches.html#smtpd_pidqp) removed, as its log informations are already contained in the qlogreceived line. (diff)
  -improved a couple of read_failed error messages
• Feb 26, 2022
  -added REJECTNULLSENDERS environment variable (diff)
• Feb 10, 2022
  -fixed a TLS Renegotiation DoS vulnerability. Disabled all renegotiation in TLSv1.2 and earlier (only openssl-1.1). (diff here)
• Jan 17, 2022
  -now qmail-smtpd logs rejects when client tries to auth when auth is not allowed, or it's not allowed without TLS (a closed connection with no log at all appeared before).
  -added qmail-spp.o to the TARGET file so that it will be purged with "make clean".
  diff here
• Dec 19, 2021
  -qmail-spp patch added

Indicizzare le e-mail con Solr FTS Engine

21 aprile 2022 Roberto Puzzanghera 0 commenti

Solr è un server di indicizzazione basato su Apache Lucene. Dovecot communica con esso attraverso delle query HTTP/XML. Il server di indicizzazione consente di fare ricerche di testo in modo veloce nelle mail, compreso il corpo dei messaggi.

• Scarica l'ultima versione: v. 8.11.1
• Documentazione di Solr FTS Engine per Dovecot

Installazione

Solr è un servlet java che richiede jdk v. 8 o successivo. E' necessario accertarsi che l'eseguibile java sia nel path:

PATH=$PATH:/usr/lib64/java/bin/

Scaricare i binari di Solr e installare

cd /usr/local/src
wget https://www.apache.org/dyn/closer.lua/lucene/solr/8.11.1/solr-8.11.1.tgz?action=download -O solr-8.11.1.tgz

Estrarre l'installer dall'archivio e lanciarlo. L'installer funzioznaerà per la maggior parte delle distribuzioni Linux basate esu systemd.

tar xzf solr-8.11.1.tgz solr-8.11.1/bin/install_solr_service.sh --strip-components=2
sudo bash ./install_solr_service.sh solr-8.11.1.tgz

Il server verrà avviato da systemd all'avvio della macchina.

LXC scripts for unprivileged containers

12 aprile 2022 Roberto Puzzanghera 0 commenti

Handling LXC unprivileged containers as root is not possible with the default LXC programs, because they must be called by the user who owns them and sometime is also necessary to specify the container's configuration file. For example, running lxc-ls as root shows all the unprivileged containers as stopped even when they are running, while lxc-start aborts the containers' startup sequence due to id mapping issues.

Since I prefer to run/stop/create/destroy/etc. my containers just typing my commands as root, not after the usual su - owner each time, I wrote my own wrapper scripts collection for the main LXC commands, just to simplify my tasks. In addition, all the unprivileged containers will be created in the same directory, say /usr/local/lxc, and not in the owner's home directory.

I use them both for privileged (owned by root itself) and unprivileged containers. In the latter case the owner of the container is determined dinamically.

These scripts allow an administrator to use LXC running his applications in separate containers, each one (or group of them) runned by a different user and id map.

I wrote them for my Slackware linux distro, but I think that they remain valid for any other Linux flavor.

If you are a Slackware user and you are looking for unprivileged containers documentation, you should take a look to Chris Willings' guide, which was my starting point on this topic. Also the Stéphane Graber's article is a suitable reading at the beginning.

• Browse my LXC scripts

Bloccare gli HELO/EHLO con falso DNS

26 febbraio 2022 Roberto Puzzanghera 0 commenti

La Sezione 3.5 del documento RFC-821 afferma che

The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.

The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

Non ammettere i client con un record DNS bacato nel proprio HELO/EHLO può essere sensato non solo perché suggerito dalla RFC di cui sopra, ma anche una cosa conveniente per l'amministratore, che non dovrà perdere il suo tempo ad aggiungere continuamente record alla whitelist per colpa dei client regolari che non hanno settato bene il proprio record DNS.

Ma d'altra parte, è un dato di fatto che praticamente tutti gli spammers utilizzino nel loro HELO domini che non appartengono loro -spesso addirittura uno dei nostri stessi domini (cosa ovviamente intollerabile)-, oppure delle stringhe random o domini che non sono riconducibili ad alcun IP.

Per esempio, consideriamo le seguenti righe del mio log (ne ho sempre moltissime):

2022-02-01 10:19:53.142643500 helo-dns-check: HELO [yq3H9cDKgS] from [109.237.103.41] doesn't solve
2022-02-01 09:53:05.772497500 helo-dns-check: HELO [sagredo.eu] is a local domain but IP [183.240.55.119] is not a RELAYCLIENT

Penso che, a prescindere da cosa dica l'RFC sopra menzionato, non si commetta un peccato mortale se si respingono almeno i client che riportano gli errori di cui sopra.

Spiegherò quindi qui sotto come settare un filtro che respinga i seguenti problemi a livello DNS:

1. HELO/EHLO che non possono essere risolti, come stringhe random o domini senza alcun A record.
2. falsi HELO/EHLO contenenti addirittura uno dei nostri domini, riconoscibili dal fatto che il record DNS non corrisponde a uno dei nostri IP mentre la variabile RELAYCLIENT non è stata definita;
3. client il cui A record non corrisponde al dominio presente nel HELO/EHLO. Ciò è palesemente contro la RFC-821, pertanto la mia configurazione non rifiuterà queste connessioni, che però saranno loggate.

• Prec.
• 1
• 2
• 3
• 4
• 5
• Succ.