# l2md **Repository Path**: mirrors_kernel_googlesource/l2md ## Basic Information - **Project Name**: l2md - **Description**: No description available - **Primary Language**: Unknown - **License**: GPL-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2021-03-19 - **Last Updated**: 2025-12-14 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README l2md - lore2maildir ------------------- Quick and dirty hack to import lore.kernel.org list archives via git, to export them in maildir format or through a pipe, and to keep them periodically synced. It can then be used in whichever mail client that supports maildir format, for example, mutt. Alternatively, it can also pipe new mails to external MDAs like procmail and friends which then deliver it to your favorite mail client eventually. Essentially, it avoids the need to subscribe to any of the lore lists via mail since all messages are now imported through git transport. Together with a smtp client like msmtp (which you may need anyway for git-send-email), it allows to interact on the mailing lists the usual way. All pretty basic and hacky at this point, patches very welcome. Please send them to Daniel Borkmann . Build ----- Links to -lgit2 which is shipped by pretty much all major distros. Fedora: libgit2-devel Ubuntu: libgit2-dev MacOS: brew install libgit2 To build, just type: $ make [...] After setting up ~/.config/l2md/config (see below), run as: $ ./l2md To install, just type: # make install The l2md.service file contains an example systemd service deployment for letting it run in the background ... $ service l2md status Redirecting to /bin/systemctl status l2md.service ● l2md.service - lore2maildir Loaded: loaded (/usr/lib/systemd/system/l2md.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2019-09-19 12:07:17 CEST; 55s ago Main PID: 31467 (l2md) Tasks: 1 (limit: 4915) Memory: 257.9M CGroup: /system.slice/l2md.service └─31467 /usr/bin/l2md The muttrc file contains an example mutt config for importing the generated maildir directories. The procmailrc file contains an example procmail config for getting started, there are plenty of howtos online for setting up filtering rules. For l2md, the repository here ships with two example configs, that is, l2mdconfig.maildir and l2mdconfig.procmail. As the name says, the former is for exporting new mails in maildir format directly, and the latter is one example where l2md pipes new mails via stdin to an external MDA like procmail. Copy the one of your choice either into ~/.config/l2md/config or ~/.l2mdconfig to get started. Troubleshooting --------------- l2md has only a single command-line parameter, which is --verbose to allow significantly more visibility on what it is currently doing: $ ./l2md --verbose By default without the --verbose it will only dump the number of new mails and commit sha's it processed to the journal and nothing else. In case l2md is deployed through the unit file, l2md's logs can be gathered the usual way: $ journalctl -fu l2md Howto 1: maildir ---------------- The l2mdconfig.maildir is an example l2md config which needs to be placed under ~/.config/l2md/config. The muttrc is an example config to get started for reading the maildir content. $ cat ~/.config/l2md/config [general] base = ~/.local/share/l2md/ maildir = ~/.local/share/l2md/maildir/common period = 30 # bpf@vger.kernel.org list [repo bpf] url = https://lore.kernel.org/bpf/0 maildir = ~/.local/share/l2md/maildir/bpf # netdev@vger.kernel.org list [repo netdev] url = https://lore.kernel.org/netdev/1 url = https://lore.kernel.org/netdev/0 initial_import = 1000 The general section contains a sync period in seconds where l2md refetches all the git repos and looks for new messages to export into the configured maildirs. The maildir under general is a path to a shared maildir where l2md exports new mails into. This can also be specified on a per repository basis. Specifying the maildir under general is optional. It will default to ~/.config/l2md/maildir or /maildir if the base deviates from the default one. Specifying base is optional as well. This is the working dir of l2md where it places its git repos and other meta data for record keeping. The default is at ~/.local/share/l2md/. To not break configs based on the previous default base: Iff the base directory is not explicitly specified and ~/.l2md/ exists, it will be used instead. The repo sections with subsequent name define a repository (duh!) with one or more git urls to lore and optional maildir export path as mentioned. If initial_import is set to >0, then it will only import first x mails upon initial repository creation instead of the entire archive. Howto 2: procmail ----------------- The l2mdconfig.procmail is an example l2md config which needs to be placed under ~/.config/l2md/config . The procmailrc is an example config to get started with a basic config for procmail. The provided muttrc can also be used here in order to get started for reading the maildir content preprocessed via procmail (the folder needs to point to procmail's MAILDIR of course). Other MDAs should work as well, but not tested at this point. $ cat ~/.config/l2md/config [general] base = ~/.local/share/l2md/ pipe = /usr/bin/procmail period = 30 [repo bpf] url = https://lore.kernel.org/bpf/0 initial_import = 1000 See Howto 1 for basics. Instead of maildir, the general section here has a setting which is set to pipe. It is pointing to the /usr/bin/procmail MDA in the example, and generally executed as the same user as l2md. Similar as with maildir, pipe can optionally be specified on a per repository basis. Howto 3: Running via systemd unit files per repo ------------------------------------------------ If you have configured l2md and have your ~/.config/l2md/config and there are more than a few repos defined, the running time of l2md can be a while, especially if you are adding a new repo and you want more of the mail than just 500 or 1,000 mails. What you can do is is run l2md per repo. This will set all other repos in the config to disabled, except for the one you provide on the command line. If you are adding a repo after your first run, do it this way: [repo mailing-list] url = https://lore.kernel.org/mailing-list/0 repo_disabled = 1 and then run $ /path/to/l2md -r mailing-list to import just that mailing list while the rest of l2md keeps syncing the other mailing lists you have defined. Once your initial import of the new list is complete, you can remove the repo_disabled from the stanza and let everything run as a whole. Howto 4: Running all lists via individual systemd unitfiles, on timer --------------------------------------------------------------------- If you have a _lot_ of lists, you can run them all in parallel. Create a .service file per repo, and a .timer file per repo like so: --> l2md-rcu.service <-- [Unit] Description=l2md fetch rcu mailing list After=network-online.target [Service] Type=oneshot User= WorkingDirectory=/home// ExecStart=/path/to/l2md -r rcu Restart=on-failure RestartPreventExitStatus=255 [Install] WantedBy=multi-user.target --> end l2md-rcu.service <-- --> l2md-rcu.timer <-- [Unit] Description=l2md-rcu timer [Timer] OnCalendar=*:00/10 [Install] WantedBy=l2md-rcu.service --> end l2md-rcu.timer <-- Place the files in /etc/systemd/system/ and then run: $ sudo systemctl enable l2md-rcu.service $ sudo systemctl enable l2md-rcu.timer $ sudo systemctl start l2md-rcu.timer Systemd will then run the timer (example above runs every ten minutes) and when it reaches 0, it will trigger the service to run. Then it starts the timer again. You want the service to be "oneshot" so that it runs and exits after one run and then let the timer run the service. In the [General] section of your l2md configuration file, set oneshot = 1 and this will work just fine. Howto 5: Using fdm for mail delivery ------------------------------------ You can leverage the ability of l2md to pipe the mails from the repos and then let a (local) mail server handle delivery into a (local) IMAP server. Because l2md does not pass arguments to the pipe, you need to create a script that runs fdm and call the script with [General] pipe = /path/to/fdm-script in l2md's config. fdm's config is quite simple: --> /home//.fdm.conf <-- $path = "%h/Maildir" $cfgdir = "%h/.fdm.d" $com_sed = "sed" $com_awk = "awk" $com_perl = "perl" set maximum-size 100M set lock-file "${cfgdir}/fdm.lock" set unmatched-mail keep set purge-after none set file-umask 077 set file-group user set timeout 900 include "${cfgdir}/accounts.conf" # can be run with 50/40 set queue-high 5 set queue-low 1 account "stdin" disabled stdin action "deliver-mail" smtp server "mail-server.fqhn" to "user@domain.tld" action "deliver-lists" smtp server "mail-server.fqhn" to "user2@domain.tld" match "^List-Id.*rcu.vger.kernel.org" in headers action "deliver-lists" match all action "deliver-mail" --> end /home//.fdm.conf <-- --> /home//.fdm.d/accounts.conf <-- # account "name" server pop3 "pop3.server.name" user "username" pass "pwd" account "example" imaps server "imap.gmail.com" user "user@domain.name" pass "garbled.string" folders { "INBOX" "[Gmail]/All mail" "[Gmail]/Sent" } --> end /home//.fdm.d/accounts.conf <-- --> /path/to/fdm-script <-- #!/bin/bash exec /usr/bin/fdm -m -a stdin fetch --> end /path/to/fdm-script <-- The example above is if you are using fdm as your fetchmail replacement already, this is the way to run it as a pipe for l2md without it interfering with the regular running of fetching your mail for other accounts you have defined. There is also an exaple in .fdm.conf on matching a list on List-Id header and delivering it to a different user via actions. If you want all mail to go to the same user, only the "match all" line is necessary. While this seems like overkill - it will inject list-mail into the SMTP server and it will have the SMTP server rules for delivery applied, including spam and A/V scanning, and then the list-mail are subject to any Sieve ruleset you have. If you are tracking over 80 lists, this may come in handy if you decide to 'upgrade' a list to being subscribed directly.