For an easy way to lookup a domain’s SMTP TLS Reporting Policy try my nice MTA-STS Policy Viewer.
After writing the first notes on SMTP TLS Reporting I thought it would be nice to see all setting on one page, without using multiple tools and lookups for DNS and HTTPS data. The first iteration was a shell script, and the second iteration was a Python function. With some more fiddling I set it up as a Google Cloud Function, with a simple web frontend.
The SMTP standard is just as ubiquitous as it is ossified and hard to change. Thus all newer RFCs follow similar patterns of a) adding optional extensions and b) providing feedback loops to detect usage, problems, and abuse of these extensions.
One more recent extension tries to enforce TLS transport between mailservers. This sounds very simple (and would be very simple if one could change the SMTP standard to require TLS), but is not trivial when compatibility is necessary and all TLS policies are “opt-in”.
I have always had a problem with the configuration of different email addresses in different git repositories. The git configuration is split into a global (~/.gitconfig) and a local/repository part (project_dir/.git/config). This works only for simple setups with one default configuration and 1-2 exceptions with per-repo overrides.
But it does not work for me, I have multiple different repositories checked out and I always forget to configure the right email address after the git clone. And it is not only “normal/private” vs. “work” address but I also have multiple addresses for different customers and open source projects. It’s a mess.
Today I finally learned about a working solution for this with git-config conditional includes. These were introduced in 2017 with git 2.13 and I found them via StackOverflow.
One personal goal this winter is to do more programming in beautiful languages.
At this moment I am quite excited about Python 3, Perl 6, and Go. Read the rest of this entry »
A nice surprise last week: textproc/libcrm114 became my first official FreeBSD port. :-)
Every now and then the Snort mailing lists get “homework questions” like how to learn about the program’s architecture. IMHO the most helpful books for a more detailed insight are:
As the name says CUnit is an xUnit implementation for the C programming language.
In comparison to dynamic programming languages the test organization requires much more manual glue code. Because C has no introspection one has to register every test case manually. Likewise there is no support for utilities like mock object generation or annotations.
On the other hand unit tests can be very useful in C, for example when implementing data structures. Test cases may isolate null pointer dereferencing and one can use valgrind on them to detect memory leaks at the lowest level.
Aus einer fixen Idee heraus habe ich mir ein Perlskript geschrieben um PDFs zu signieren. Und wie sich das für einen 750-Seiten-ISO-Standard gehört bleiben im Datenformat so einige Angaben interpretationsbedürftig. %-)
Read the rest of this entry »
