opensmtpd.org 158 KB
(service (@ (gnu services mail) opensmtpd-service-type) ((@ (gnu services mail) opensmtpd-configuration) (config-file …)))
tasks
PROJ I have decent data structures. now let's get some good code. [0/1]
why are good data structures important?
nckx's advice: use a simple 1-1 mapping
"...as I think Guix services ought to faithfully wrap the native syntax whenever possible (implement alternative simple APIs on top of that — fine)."
-nckx from irc on #guix
To follow nckx's advice, one might create the <opensmtpd-service> like this:
(service opensmtpd-service
(opensmtpd-configuration
(includes ...)
(tables ...)
(pkis ...)
(filters ...)
(listen-on ...)
(actions ...)
(matches ...)))
Defining the service this way, makes it VERY easy from a development point of view. But it makes it possible for users to create simple mistakes when defining the service.
For example, it is possible to define an nginx service that will successfully
reconfigure the system. BUT after reboot nginx refuses to start. Why? Who knows.
Guix won't tell you. Neither will the Shepherd. To fix this, the user has to go
digging into the nginx logs, and he might not know where to find those. If
possible, when the user specificies a <opensmtpd-configuration> that has
obvious errors, then the guix services should make reconfigure fail and print a
helpful error message.
BUT it would be better if the service uses better datastructures.
Keep reading to discover how I fool-proofed the opensmtpd service records.
I should follow nckx's advice, and Linus' advice: good programmers use good datastructures. If you have good datastructures, then your code will almost write itself.
It might make the service a little harder to develop, but end-users will find
the service easier to use. This would eliminate common errors like misspellings
and give appropriate error messages. Practically it would ensure each
== has a corresponding <opensmtpd-action>,
creating a table name and then misspelling the table name later, and defining
a table but never using it, etc.
Example configuration
I will strive to ensure that this example configuration always works.
(opensmtpd-configuration->mixed-text-file
(let ([interface "lo"]
[creds-table (opensmtpd-table
(name "creds")
(data
(list
(cons "joshua"
"$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86."))))]
[receive-action (opensmtpd-local-delivery
(name "receive")
(method (opensmtpd-maildir
(pathname "/home/%{rcpt.user}/Maildir")
(junk #t)))
(virtual (opensmtpd-table
(name "virt")
(data '(("josh" . "jbranso@dismail.de"))))))]
;; as of 7-24-22 this proc fieldname does not actually work, but is proper syntax.
[filter-dkimsign (opensmtpd-filter
(name "dkimsign")
(exec #t)
(proc (list (file-append opensmtpd-filter-dkimsign "/libexec/opensmtpd/filter-dkimsign")
" -d gnucode.me -s 2021-09-22 -c relaxed/relaxed -k "
"/etc/dkim/private.key "
"user nobody group nogroup")))]
[filter-invalid-fcrdns (opensmtpd-filter-phase
(name "invalid-fcrdns")
(phase "connect")
(options
(list (opensmtpd-option
(option "fcrdns")
(bool #f))))
(decision "reject")
(message "422 No valid fcrdns."))]
[filter-invalid-rdns (opensmtpd-filter-phase
(name "invalid-rdns")
(phase "connect")
(options
(list (opensmtpd-option
(option "rdns")
(bool #f))))
(decision "junk"))]
[smtp.gnucode.me (opensmtpd-pki
(domain "smtp.gnucode.me")
(cert "guix.scm")
(key "guix.scm"))])
(opensmtpd-configuration
(mta-max-deferred 50)
(queue
(opensmtpd-queue
(compression #t)))
(smtp
(opensmtpd-smtp
(max-message-size "10M")))
(srs
(opensmtpd-srs
(ttl-delay "5d")))
(interfaces
(list
(opensmtpd-interface
(interface interface)
(port 25)
(secure-connection "tls")
(filters (list filter-invalid-fcrdns
filter-invalid-rdns))
(pki smtp.gnucode.me))
;; this lets local users logged into the system via ssh send email
;; be sure to dkimsign them.
(opensmtpd-interface
(interface interface)
(port 465)
(secure-connection "smtps")
(pki smtp.gnucode.me)
(auth creds-table)
(filters (list filter-dkimsign)))
;; if you uncomment this next line, then you get issues.
;;(opensmtpd-socket
;; (filters (list filter-dkimsign)))
;; send out emails and be sure to dkimsign them.
(opensmtpd-interface
(interface interface)
(port 587)
(secure-connection "tls-require")
(pki smtp.gnucode.me)
(auth creds-table)
(filters (list filter-dkimsign)))))
(socket
(opensmtpd-socket
(filters (list filter-dkimsign))
(tag "socket")))
(matches (list
(opensmtpd-match
(action (opensmtpd-relay
(name "relay")))
(options (list (opensmtpd-option
(option "for any"))
(opensmtpd-option
(option "from any"))
(opensmtpd-option
(option "auth")))))
(opensmtpd-match
(action receive-action)
(options (list (opensmtpd-option
(option "from any"))
(opensmtpd-option
(option "for domain")
(data (opensmtpd-table
(name "domain-table")
(data (list "gnucode.me" "gnu-hurd.com"))))))))
(opensmtpd-match
(action receive-action)
(options (list (opensmtpd-option
(option "for local"))))))))))
example text configuration
You can test this text file via:
smtpd -nf smtpd.conf
filter "invalid-fcrdns" phase connect match !fcrdns reject "422 No valid fcrdns."
filter "dkimsign" proc-exec "/gnu/store/rklsc9b0p0bsjh10d5hi2mxiyx2p29pl-opensmtpd-filter-dkimsign-0.5/libexec/opensmtpd/filter-dkimsign -d gnucode.me -s 2021-09-22 -c relaxed/relaxed -k /etc/dkim/private.key user nobody group nogroup"
smtp max-message-size 10M
srs ttl 5d
queue compression
mta max-deferred 50
table creds { "joshua" = "$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86." }
table virt { "josh", "jbranso@dismail.de" }
table domain-table { "gnucode.me", "gnu-hurd.com" }
pki smtp.gnucode.me cert "guix.scm"
pki smtp.gnucode.me key "guix.scm"
listen on lo filter "invalid-fcrdns" tls port 25 pki smtp.gnucode.me
listen on lo filter "dkimsign" smtps port 465 pki smtp.gnucode.me auth <creds>
listen on lo filter "dkimsign" tls-require port 587 pki smtp.gnucode.me auth <creds>
listen on socket
action "relay" relay
action "receive" maildir "/home/%{rcpt.user}/Maildir" junk virtual <virt>
match for any from any auth action "relay"
match for domain <domain-table> from any action "receive"
match for local action "receive"
PROJ follow the style guide and style up my project [2/3]
https://mumble.net/~campbell/scheme/style.txt
:SchemeStyleGuide:
Riastradh's Lisp Style Rules -*- outline -*-
Copyright (C) 2007--2011 Taylor R. Campbell
CC BY-NC-SA 3.0
This work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 3.0 Unported License:
<http://creativecommons.org/licenses/by-nc-sa/3.0/>.
This is a guide to Lisp style, written by Taylor R. Campbell, to
describe the standard rules of Lisp style as well as a set of more
stringent rules for his own style. This guide should be useful for
Lisp in general, but there are [or will be in the final draft] parts
that are focussed on or specific to Scheme or Common Lisp.
This guide is written primarily as a collection of rules, with
rationale for each rule. (If a rule is missing rationale, please
inform the author!) Although a casual reader might go through and read
the rules without the rationale, perhaps reasoning that reading of the
rationale would require more time than is available, such a reader
would derive little value from this guide. In order to apply the rules
meaningfully, their spirit must be understood; the letter of the rules
serves only to hint at the spirit. The rationale is just as important
as the rules.
There are many references in this document to `Emacs', `GNU Emacs',
`Edwin', and so on. In this document, `Emacs' means any of a class of
editors related in design to a common ancestor, the EMACS editor macros
written for TECO on ITS on the PDP-10 in the middle of the nineteen
seventies. All such editors -- or `all Emacsen', since `Emacsen' is
the plural of `Emacs' -- have many traits in common, such as a very
consistent set of key bindings, extensibility in Lisp, and so on. `GNU
Emacs' means the member of the class of editors collectively known as
Emacsen that was written for the GNU Project in the middle of the
nineteen eighties, and which is today probably the most popular Emacs.
`Edwin' is MIT Scheme's Emacs, which is bundled as part of MIT Scheme,
and not available separately. There are other Emacsen as well, such as
Hemlock and Climacs, but as the author of this document has little
experience with Emacsen other than GNU Emacs and Edwin, there is little
mention of other Emacsen.
This guide is a work in progress. To be written:
- Indentation rules for various special operators.
- Philosophical rambling concerning naming.
- Rules for breaking lines.
- Many more examples.
- A more cohesive explanation of the author's principles for composing
programs, and their implications.
- Rules for writing portable code.
- Some thoughts concerning extensions to the lexical syntax.
- Rules for writing or avoiding macros.
- Some unfinished rationale.
- More on documentation.
- The `Dependencies' subsection of the `General Layout' section should
be put in a different section, the rest of which has yet to be
written, on organization of programs, module systems, and portable
code.
Feedback is welcome; address any feedback by email to the host
mumble.net's user `campbell', or by IRC to Riastradh in the #scheme
channel on Freenode (irc.freenode.net). Feedback includes reports of
typos, questions, requests for clarification, and responses to the
rationale, except in the case of round brackets versus square
brackets, the argument surrounding which is supremely uninteresting
and now not merely a dead horse but a rotting carcass buzzing with
flies and being picked apart by vultures.
As this document has grown, the line between standard Lisp rules and
the author's own style has been blurred. The author is considering
merging of the partition, but has not yet decided on this with
certainty. Opinions on the subject are welcome -- is the partition
still useful to keep the author's biases and idiosyncrasies out of the
standard rules, or has the partition with its arbitrary nature only
caused disorganization of the whole document?
Unfortunately, this document is entirely unscientific. It is at best a
superstition or philosophy, but one that the author of this document
has found to have improved his programs. Furthermore, the author is
somewhat skeptical of claims of scientific analyses of these matters:
analyzing human behaviour, especially confined to the set of excellent
programmers who often have strong opinions about their methods for
building programs, is a very tricky task.
,* Standard Rules
These are the standard rules for formatting Lisp code; they are
repeated here for completeness, although they are surely described
elsewhere. These are the rules implemented in Emacs Lisp modes, and
auxiliary utilities such as Paredit.
The rationale given here is merely the author's own speculation of the
origin of these rules, and should be taken as nothing more than it.
The reader shall, irrespective of the author's rationale, accept the
rules as sent by the reader's favourite deity, or Cthulhu if no such
deity strikes adequate fear into the heart of the reader.
,** Parentheses
,*** Terminology
This guide avoids the term /parenthesis/ except in the general use of
/parentheses/ or /parenthesized/, because the word's generally accepted
definition, outside of the programming language, is a statement whose
meaning is peripheral to the sentence in which it occurs, and *not* the
typographical symbols used to delimit such statements.
The balanced pair of typographical symbols that mark parentheses in
English text are /round brackets/, i.e. ( and ). There are several
other balanced pairs of typographical symbols, such as /square
brackets/ (commonly called simply `brackets' in programming circles),
i.e. [ and ]; /curly braces/ (sometimes called simply `braces'), i.e. {
and }; /angle brackets/ (sometimes `brokets' (for `broken brackets')),
i.e. < and >.
In any balanced pair of typographical symbols, the symbol that begins
the region delimited by the symbols is called the /opening bracket/ or
the /left bracket/, such as ( or [ or { or <. The symbol that ends
that region is called the /right bracket/ or the /closing bracket/,
such as > or } or ] or ).
,*** Spacing
If any text precedes an opening bracket or follows a closing bracket,
separate that text from that bracket with a space. Conversely, leave
no space after an opening bracket and before following text, or after
preceding text and before a closing bracket.
Unacceptable:
(foo(bar baz)quux)
(foo ( bar baz ) quux)
Acceptable:
(foo (bar baz) quux)
Rationale: This is the same spacing found in standard typography of
European text. It is more aesthetically pleasing.
,*** Line Separation
Absolutely do *not* place closing brackets on their own lines.
Unacceptable:
(define (factorial x)
(if (< x 2)
1
(* x (factorial (- x 1
)
)
)
)
)
Acceptable:
(define (factorial x)
(if (< x 2)
1
(* x (factorial (- x 1)))))
Rationale: The parentheses grow lonely if their closing brackets are
all kept separated and segregated.
,**** Exceptions to the Above Rule Concerning Line Separation
Do not heed this section unless you know what you are doing. Its title
does *not* make the unacceptable example above acceptable.
When commenting out fragments of expressions with line comments, it may
be necessary to break a line before a sequence of closing brackets:
(define (foo bar)
(list (frob bar)
(zork bar)
;; (zap bar)
))
This is acceptable, but there are other alternatives. In Common Lisp,
one can use the read-time optional syntax, `#+' or `#-', with a
feature optional that is guaranteed to be false or true -- `#+(OR)'
or `#-(AND)' --; for example,
(define (foo bar)
(list (frob bar)
(zork bar)
,#+(or) (zap bar))).
Read-time optionals are expression-oriented, not line-oriented, so
the closing brackets need not be placed on the following line. Some
Scheme implementations, and SRFI 62, also support expression comments
with `#;', which are operationally equivalent to the above read-time
optionals for Common Lisp:
(define (foo bar)
(list (frob bar)
(zork bar)
#;
(zap bar)))
The expression is placed on another line in order to avoid confusing
editors that do not recognize S-expression comments; see the section
titled `Comments' below for more details. However, the `#;' notation
is not standard -- it appears in neither the IEEE 1178 document nor in
the R5RS --, so line comments are preferable for portable Scheme code,
even if they require breaking a line before a sequence of closing
brackets.
Finally, it is acceptable to break a line immediately after an opening
bracket and immediately before a closing bracket for very long lists,
especially in files under version control. This eases the maintenance
of the lists and clarifies version diffs. Example:
(define colour-names ;Add more colour names to this list!
'(
blue
cerulean
green
magenta
purple
red
scarlet
turquoise
))
,*** Parenthetical Philosophy
The actual bracket characters are simply lexical tokens to which little
significance should be assigned. Lisp programmers do not examine the
brackets individually, or, Azathoth forbid, count brackets; instead
they view the higher-level structures expressed in the program,
especially as presented by the indentation. Lisp is not about writing
a sequence of serial instructions; it is about building complex
structures by summing parts. The composition of complex structures
from parts is the focus of Lisp programs, and it should be readily
apparent from the Lisp code. Placing brackets haphazardly about the
presentation is jarring to a Lisp programmer, who otherwise would not
even have seen them for the most part.
,** Indentation and Alignment
The operator of any form, i.e. the first subform following the opening
round bracket, determines the rules for indenting or aligning the
remaining forms. Many names in this position indicate special
alignment or indentation rules; these are special operators, macros, or
procedures that have certain parameter structures.
If the first subform is a non-special name, however, then if the second
subform is on the same line, align the starting column of all following
subforms with that of the second subform. If the second subform is on
the following line, align its starting column with that of the first
subform, and do the same for all remaining subforms.
In general, Emacs will indent Lisp code correctly. Run `C-M-q'
(indent-sexp) on any code to ensure that it is indented correctly, and
configure Emacs so that any non-standard forms are indented
appropriately.
Unacceptable:
(+ (sqrt -1)
(* x y)
(+ p q))
(+
(sqrt -1)
(* x y)
(+ p q))
Acceptable:
(+ (sqrt -1)
(* x y)
(+ p q))
(+
(sqrt -1)
(* x y)
(+ p q))
Rationale: The columnar alignment allows the reader to follow the
operands of any operation straightforwardly, simply by scanning
downward or upward to match a common column. Indentation dictates
structure; confusing indentation is a burden on the reader who wishes
to derive structure without matching parentheses manually.
,*** Non-Symbol Indentation and Alignment
The above rules are not exhaustive; some cases may arise with strange
data in operator positions.
,**** Lists
Unfortunately, style varies here from person to person and from editor
to editor. Here are some examples of possible ways to indent lists
whose operators are lists:
Questionable:
((car x) ;Requires hand indentation.
(cdr x)
foo)
((car x) (cdr x) ;GNU Emacs
foo)
Preferable:
((car x) ;Any Emacs
(cdr x)
foo)
((car x) (cdr x) ;Edwin
foo)
Rationale: The operands should be aligned, as if it were any other
procedure call with a name in the operator position; anything other
than this is confusing because it gives some operands greater visual
distinction, allowing others to hide from the viewer's sight. For
example, the questionable indentation
((car x) (cdr x)
foo)
can make it hard to see that FOO and (CDR X) are both operands here
at the same level. However, GNU Emacs will generate that indentation
by default. (Edwin will not.)
,**** Strings
If the form in question is meant to be simply a list of literal data,
all of the subforms should be aligned to the same column, irrespective
of the first subform.
Unacceptable:
("foo" "bar" "baz" "quux" "zot"
"mumble" "frotz" "gargle" "mumph")
Questionable, but acceptable:
(3 1 4 1 5 9 2 6 5 3 5 8 9 7 9 3 2 3 8 4 6 2 6 4
3 3 8 3 2 7 9 5 0 2 8 8 4 1 9 7 1 6 9 3 9 9 3)
Acceptable:
("foo" "bar" "baz" "quux" "zot"
"mumble" "frotz" "gargle" "mumph")
("foo"
"bar" "baz" "quux" "zot"
"mumble" "frotz" "gargle" "mumph")
Rationale: Seldom is the first subform distinguished for any reason,
if it is a literal; usually in this case it indicates pure data, not
code. Some editors and pretty-printers, however, will indent
unacceptably in the example given unless the second subform is on the
next line anyway, which is why the last way to write the fragment is
usually best.
,** Names
Naming is subtle and elusive. Bizarrely, it is simultaneously
insignificant, because an object is independent of and unaffected by
the many names by which we refer to it, and also of supreme
importance, because it is what programming -- and, indeed, almost
everything that we humans deal with -- is all about. A full
discussion of the concept of name lies far outside the scope of this
document, and could surely fill not even a book but a library.
Symbolic names are written with English words separated by hyphens.
Scheme and Common Lisp both fold the case of names in programs;
consequently, camel case is frowned upon, and not merely because it is
ugly. Underscores are unacceptable separators except for names that
were derived directly from a foreign language without translation.
Unacceptable:
XMLHttpRequest
foreach
append_map
Acceptable:
xml-http-request
for-each
append-map
,*** Funny Characters
There are several different conventions in different Lisps for the use
of non-alphanumeric characters in names.
,**** Scheme
,***** Question Marks: Predicates
Affix a question mark to the end of a name for a procedure whose
purpose is to ask a question of an object and to yield a boolean
answer. Such procedures are called `predicates'. Do not use a
question mark if the procedure may return any object other than a
boolean.
Examples: pair? procedure? proper-list?
Non-examples: member assoc any every
Pronounce the question mark as if it were the isolated letter `p'. For
example, to read the fragment (PAIR? OBJECT) aloud, say: `pair-pee
object.'
,***** Exclamation Marks: Destructive Operations
Affix an exclamation mark to the end of a name for a procedure (or
macro) whose primary purpose is to modify an object. Such procedures
are called `destructive'.
Examples: set-car! append!
Avoid using the exclamation mark willy nilly for just *any* procedure
whose operation involves any kind of mutation or side effect; instead,
use the exclamation mark to identify procedures that exist *solely* for
the purpose of destructive update (e.g., SET-CAR!), or to distinguish a
destructive, or potentially destructive (in the case of linear-update
operations such as APPEND!), variant of a procedure of which there also
exists a purely functional variant (e.g., APPEND).
Pronounce the exclamation mark as `bang'. For example, to read the
fragment (APPEND! LIST TAIL) aloud, say: `append-bang list tail.'
,***** Asterisks: Variants, Internal Routines, Mutable Globals
Affix an asterisk to the end of a name to make a variation on a theme
of the original name.
Example: let -> let*
Prefer a meaningful name over an asterisk; the asterisk does not
explain what variation on the theme the name means.
Affix an asterisk to the beginning of a name to make an internal
routine for that name. Again, prefer a meaningful name over an
asterisk.
Affix asterisks to the beginning and end of a globally mutable
variable. This allows the reader of the program to recognize very
easily that it is badly written!
,***** `WITH-' and `CALL-WITH-': Dynamic State and Cleanup
Prefix `WITH-' to any procedure that establishes dynamic state and
calls a nullary procedure, which should be the last (required)
argument. The dynamic state should be established for the extent of
the nullary procedure, and should be returned to its original state
after that procedure returns.
Examples: with-input-from-file with-output-to-file
Exception: Some systems provide a procedure (WITH-CONTINUATION
<continuation> <thunk>), which calls <thunk> in the given
continuation, using that continuation's dynamic state. If <thunk>
returns, it will return to <continuation>, not to the continuation of
the call to WITH-CONTINUATION. This is acceptable.
Prefix `CALL-WITH-' to any procedure that calls a procedure, which
should be its last argument, with some arguments, and is either somehow
dependent upon the dynamic state or continuation of the program, or
will perform some action to clean up data after the procedure argument
returns. Generally, `CALL-WITH-' procedures should return the values
that the procedure argument returns, after performing the cleaning
action.
Examples:
- CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE both accept a
pathname and a procedure as an argument, open that pathname (for
input or output, respectively), and call the procedure with one
argument, a port corresponding with the file named by the given
pathname. After the procedure returns, CALL-WITH-INPUT-FILE and
CALL-WITH-OUTPUT-FILE close the file that they opened, and return
whatever the procedure returned.
- CALL-WITH-CURRENT-CONTINUATION is dependent on the continuation
with which it was called, and passes as an argument an escape
procedure corresponding with that continuation.
- CALL-WITH-OUTPUT-STRING, a common but non-standard procedure
definable in terms of OPEN-OUTPUT-STRING and GET-OUTPUT-STRING from
SRFI 6 (Basic String Ports), calls its procedure argument with an
output port, and returns a string of all of the output written to
that port. Note that it does not return what the procedure
argument returns, which is an exception to the above rule.
Generally, the distinction between these two classes of procedures is
that `CALL-WITH-...' procedures should not establish fresh dynamic
state and instead pass explicit arguments to their procedure arguments,
whereas `WITH-...' should do the opposite and establish dynamic state
while passing zero arguments to their procedure arguments.
,** Comments
Write heading comments with at least four semicolons; see also the
section below titled `Outline Headings'.
Write top-level comments with three semicolons.
Write comments on a particular fragment of code before that fragment
and aligned with it, using two semicolons.
Write margin comments with one semicolon.
The only comments in which omission of a space between the semicolon
and the text is acceptable are margin comments.
Examples:
;;;; Frob Grovel
;;; This section of code has some important implications:
;;; 1. Foo.
;;; 2. Bar.
;;; 3. Baz.
(define (fnord zarquon)
;; If zob, then veeblefitz.
(quux zot
mumble ;Zibblefrotz.
frotz))
,* Riastradh's Non-Standard Rules
Three principles guide this style, roughly ordered according to
descending importance:
1. The purpose of a program is to describe an idea, and not the way
that the idea must be realized; the intent of the program's meaning,
rather than peripheral details that are irrelevant to its intent,
should be the focus of the program, *irrespective* of whether a
human or a machine is reading it. [It would be nice to express this
principle more concisely.]
2. The sum of the parts is easier to understand than the whole.
3. Aesthetics matters. No one enjoys reading an ugly program.
,** General Layout
This section contains rules that the author has found generally helpful
in keeping his programs clean and presentable, though they are not
especially philosophically interesting.
Contained in the rationale for some of the following rules are
references to historical limitations of terminals and printers, which
are now considered aging cruft of no further relevance to today's
computers. Such references are made only to explain specific measures
chosen for some of the rules, such as a limit of eighty columns per
line, or sixty-six lines per page. There is a real reason for each of
the rules, and this real reason is not intrinsically related to the
historical measures, which are mentioned only for the sake of
providing some arbitrary measure for the limit.
,*** File Length
If a file exceeds five hundred twelve lines, begin to consider
splitting it into multiple files. Do not write program files that
exceed one thousand twenty-four lines. Write a concise but
descriptive title at the top of each file, and include no content in
the file that is unrelated to its title.
Rationale: Files that are any larger should generally be factored
into smaller parts. (One thousand twenty-four is a nicer number than
one thousand.) Identifying the purpose of the file helps to break it
into parts if necessary and to ensure that nothing unrelated is
included accidentally.
,*** Top-Level Form Length
Do not write top-level forms that exceed twenty-one lines, except for
top-level forms that serve only the purpose of listing large sets of
data. If a procedure exceeds this length, split it apart and give
names to its parts. Avoid names formed simply by appending a number
to the original procedure's name; give meaningful names to the parts.
Rationale: Top-level forms, especially procedure definitions, that
exceed this length usually combine too many concepts under one name.
Readers of the code are likely to more easily understand the code if
it is composed of separately named parts. Simply appending a number
to the original procedure's name can help only the letter of the
rule, not the spirit, however, even if the procedure was taken from a
standard algorithm description. Using comments to mark the code with
its corresponding place in the algorithm's description is acceptable,
but the algorithm should be split up in meaningful fragments anyway.
Rationale for the number twenty-one: Twenty-one lines, at a maximum
of eighty columns per line, fits in a GNU Emacs instance running in a
24x80 terminal. Although the terminal may have twenty-four lines,
three of the lines are occupied by GNU Emacs: one for the menu bar
(which the author of this guide never uses, but which occupies a line
nevertheless in a vanilla GNU Emacs installation), one for the mode
line, and one for the minibuffer's window. The writer of some code
may not be limited to such a terminal, but the author of this style
guide often finds it helpful to have at least four such terminals or
Emacs windows open simultaneously, spread across a twelve-inch laptop
screen, to view multiple code fragments.
,*** Line Length
Do not write lines that exceed eighty columns, or if possible
seventy-two.
Rationale: Following multiple lines that span more columns is
difficult for humans, who must remember the line of focus and scan
right to left from the end of the previous line to the beginning of
the next line; the more columns there are, the harder this is to do.
Sticking to a fixed limit helps to improve readability.
Rationale for the numbers eighty and seventy-two: It is true that we
have very wide screens these days, and we are no longer limited to
eighty-column terminals; however, we ought to exploit our wide
screens not by writing long lines, but by viewing multiple fragments
of code in parallel, something that the author of this guide does
very often. Seventy-two columns leave room for several nested layers
of quotation in email messages before the code reaches eighty
columns. Also, a fixed column limit yields nicer printed output,
especially in conjunction with pagination; see the section
`Pagination' below.
,*** Blank Lines
Separate each adjacent top-level form with a single blank line (i.e.
two line breaks). If two blank lines seem more appropriate, break the
page instead. Do not place blank lines in the middle of a procedure
body, except to separate internal definitions; if there is a blank
line for any other reason, split the top-level form up into multiple
ones.
Rationale: More than one blank line is distracting and sloppy. If
the two concepts that are separated by multiple blank lines are
really so distinct that such a wide separator is warranted, then
they are probably better placed on separate pages anyway; see the
next section, `Pagination'.
,*** Pagination
Separate each file into pages of no more than sixty-six lines and no
fewer than forty lines with form feeds (ASCII #x0C, or ^L, written in
Emacs with `C-q C-l'), on either side of which is a single line break
(but not a blank line).
Rationale: Keeping distinct concepts laid out on separate pages
helps to keep them straight. This is helpful not only for the
writer of the code, but also for the reader. It also allows readers
of the code to print it onto paper without fiddling with printer
settings to permit pages of more than sixty-six lines (which is the
default number for many printers), and pagination also makes the
code easier to navigate in Emacs, with the `C-x [' and `C-x ]' keys
(`backward-page' and `forward-page', respectively). To avoid
excessively small increments of page-by-page navigation, and to
avoid wasting paper, each page should generally exceed forty lines.
`C-x l' in Emacs will report the number of lines in the page on which
the point lies; this is useful for finding where pagination is
necessary.
,*** Outline Headings
Use Emacs's Outline Mode to give titles to the pages, and if
appropriate a hierarchical structure. Set `outline-regexp' (or
`outline-pattern' in Edwin) to "\f\n;;;;+ ", so that each form feed
followed by an line break followed by at least four semicolons and a
space indicates an outline heading to Emacs. Use four semicolons for
the highest level of headings in the hierarchy, and one more for each
successively nested level of hierarchy.
Rationale: Not only does this clarify the organization of the code,
but readers of the code can then navigate the code's structure with
Outline Mode commands such as `C-c C-f', `C-c C-b', `C-c C-u', and
`C-c C-d' (forward, backward, up, down, respectively, headings).
,*** Dependencies
When writing a file or module, minimize its dependencies. If there are
too many dependencies, consider breaking the module up into several
parts, and writing another module that is the sum of the parts and that
depends only on the parts, not their dependencies.
Rationale: A fragment of a program with fewer dependencies is less
of a burden on the reader's cognition. The reader can more easily
understand the fragment in isolation; humans are very good at local
analyses, and terrible at global ones.
,** Naming
This section requires an elaborate philosophical discussion which the
author is too ill to have the energy to write at this moment.
Compose concise but meaningful names. Do not cheat by abbreviating
words or using contractions.
Rationale: Abbreviating words in names does not make them shorter;
it only makes them occupy less screen space. The reader still must
understand the whole long name. This does not mean, however, that
names should necessarily be long; they should be descriptive. Some
long names are more descriptive than some short names, but there are
also descriptive names that are not long and long names that are not
descriptive. Here is an example of a long name that is not
descriptive, from SchMUSE, a multi-user simulation environment
written in MIT Scheme:
frisk-descriptor-recursive-subexpr-descender-for-frisk-descr-env
Not only is it long (sixty-four characters) and completely
impenetrable, but halfway through its author decided to abbreviate
some words as well!
Do not write single-letter variable names. Give local variables
meaningful names composed from complete English words.
Rationale: It is tempting to reason that local variables are
invisible to other code, so it is OK to be messy with their names.
This is faulty reasoning: although the next person to come along and
use a library may not care about anything but the top-level
definitions that it exports, this is not the only audience of the
code. Someone will also want to read the code later on, and if it is
full of impenetrably terse variable names without meaning, that
someone will have a hard time reading the code.
Give names to intermediate values where their expressions do not
adequately describe them.
Rationale: An `expression' is a term that expresses some value.
Although a machine needs no higher meaning for this value, and
although it should be written to be sufficiently clear for a human to
understand what it means, the expression might mean something more
than just what it says where it is used. Consequently, it is helpful
for humans to see names given to expressions.
Example: A hash table HASH-TABLE maps foos to bars; (HASH-TABLE/GET
HASH-TABLE FOO #F) expresses the datum that HASH-TABLE maps FOO to,
but that expression gives the reader no hint of any information
concerning that datum. (LET ((BAR (HASH-TABLE/GET HASH-TABLE FOO
#F))) ...) gives a helpful name for the reader to understand the
code without having to find the definition of HASH-TABLE.
Index variables such as i and j, or variables such as A and D naming
the car and cdr of a pair, are acceptable only if they are completely
unambiguous in the scope. For example,
(do ((i 0 (+ i 1)))
((= i (vector-length vector)))
(frobnicate (vector-ref vector i)))
is acceptable because the scope of i is very clearly limited to a
single vector. However, if more vectors are involved, using more
index variables such as j and k will obscure the program further.
Avoid functional combinators, or, worse, the point-free (or
`point-less') style of code that is popular in the Haskell world. At
most, use function composition only where the composition of functions
is the crux of the idea being expressed, rather than simply a procedure
that happens to be a composition of two others.
Rationale: Tempting as it may be to recognize patterns that can be
structured as combinations of functional combinators -- say, `compose
this procedure with the projection of the second argument of that
other one', or (COMPOSE FOO (PROJECT 2 BAR)) --, the reader of the
code must subsequently examine the elaborate structure that has been
built up to obscure the underlying purpose. The previous fragment
could have been written (LAMBDA (A B) (FOO (BAR B))), which is in
fact shorter, and which tells the reader directly what argument is
being passed on to what, and what argument is being ignored, without
forcing the reader to search for the definitions of FOO and BAR or
the call site of the final composition. The explicit fragment
contains substantially more information when intermediate values are
named, which is very helpful for understanding it and especially for
modifying it later on.
The screen space that can be potentially saved by using functional
combinators is made up for by the cognitive effort on the part of the
reader. The reader should not be asked to search globally for usage
sites in order to understand a local fragment. Only if the structure
of the composition really is central to the point of the narrative
should it be written as such. For example, in a symbolic integrator
or differentiator, composition is an important concept, but in most
code the structure of the composition is completely irrelevant to the
real point of the code.
If a parameter is ignored, give it a meaningful name nevertheless and
say that it is ignored; do not simply call it `ignored'.
In Common Lisp, variables can be ignored with (DECLARE (IGNORE ...)).
Some Scheme systems have similar declarations, but the portable way to
ignore variables is just to write them in a command context, where
their values will be discarded, preferably with a comment indicating
this purpose:
(define (foo x y z)
x z ;ignore
(frobnitz y))
Rationale: As with using functional combinators to hide names,
avoiding meaningful names for ignored parameters only obscures the
purpose of the program. It is helpful for a reader to understand
what parameters a procedure is independent of, or if someone wishes
to change the procedure later on, it is helpful to know what other
parameters are available. If the ignored parameters were named
meaninglessly, then these people would be forced to search for call
sites of the procedure in order to get a rough idea of what
parameters might be passed here.
When naming top-level bindings, assume namespace partitions unless in a
context where they are certain to be absent. Do not write explicit
namespace prefixes, such as FOO:BAR for an operation BAR in a module
FOO, unless the names will be used in a context known not to have any
kind of namespace partitions.
Rationale: Explicit namespace prefixes are ugly, and lengthen names
without adding much semantic content. Common Lisp has its package
system to separate the namespaces of symbols; most Schemes have
mechanisms to do so as well, even if the RnRS do not specify any. It
is better to write clear names which can be disambiguated if
necessary, rather than to write names that assume some kind of
disambiguation to be necessary to begin with. Furthermore, explicit
namespace prefixes are inadequate to cover name clashes anyway:
someone else might choose the same namespace prefix. Relegating this
issue to a module system removes it from the content of the program,
where it is uninteresting.
,** Comments
Write comments only where the code is incapable of explaining itself.
Prefer self-explanatory code over explanatory comments. Avoid
`literate programming' like the plague.
Rationale: If the code is often incapable of explaining itself, then
perhaps it should be written in a more expressive language. This may
mean using a different programming language altogether, or, since we
are talking about Lisp, it may mean simply building a combinator
language or a macro language for the purpose. `Literate programming'
is the logical conclusion of languages incapable of explaining
themselves; it is a direct concession of the inexpressiveness of the
computer language implementing the program, to the extent that the
only way a human can understand the program is by having it rewritten
in a human language.
Do not write interface documentation in the comments for the
implementation of the interface. Explain the interface at the top of
the file if it is a single-file library, or put that documentation in
another file altogether. (See the `Documentation' section below if the
interface documentation comments grow too large for a file.)
Rationale: A reader who is interested only in the interface really
should not need to read through the implementation to pick out its
interface; by putting the interface documentation at the top, not
only is such a reader's task of identifying the interface made
easier, but the implementation code can be more liberally commented
without fear of distracting this reader. To a reader who is
interested in the implementation as well, the interface is still
useful in order to understand what concepts the implementation is
implementing.
Example: <http://mumble.net/~campbell/scheme/skip-list.scm>
In this example of a single-file library implementing the skip list
data structure, the first page explains the purpose and dependencies
of the file (which are useful for anyone who intends to use it, even
though dependencies are really implementation details), and the next
few pages explain the usage of skip lists as implemented in that
file. On the first page of implementation, `Skip List Structure',
there are some comments of interest only to a reader who wishes to
understand the implementation; the same goes for the rest of the
file, none of which must a reader read whose interest is only in the
usage of the library.
Avoid block comments (i.e. #| ... |#). Use S-expression comments (`#;'
in Scheme, with the expression to comment on the next line; `#+(OR)' or
`#-(AND)' in Common Lisp) to comment out whole expressions. Use blocks
of line comments for text.
Rationale: Editor support for block comments is weak, because it
requires keeping a detailed intermediate parse state of the whole
buffer, which most Emacsen do not do. At the very least, #|| ... ||#
is better, because most Emacsen will see vertical bars as symbol
delimiters, and lose trying to read a very, very long symbol, if they
try to parse #| ... |#, whereas they will just see two empty symbols
and otherwise innocuous text between them if they try to parse #||
... ||#. In any case, in Emacs, `M-x comment-region RET', or `M-;'
(comment-dwim), is trivial to type.
The only standard comments in Scheme are line comments. There are
SRFIs for block comments and S-expression comments, but support for
them varies from system to system. Expression comments are not hard
for editors to deal with because it is safe not to deal with them at
all; however, in Scheme S-expression comments, which are written by
prefixing an expression with `#;', the expression to be commented
should be placed on the next line. This is because editors that do
not deal with them at all may see the semicolon as the start of a
line comment, which will throw them off. Expression comments in
Common Lisp, however, are always safe.
In Common Lisp, the two read-time optionals that are guaranteed to
ignore any form following them are `#+(OR)' and `#-(AND)'. `#+NIL'
is sometimes used in their stead, but, while it may appear to be an
obviously false optional, it actually is not. The feature
expressions are read in the KEYWORD package, so NIL is read not as
CL:NIL, i.e. the boolean false value, but as :NIL, a keyword symbol
whose name happens to be `NIL'. Not only is it not read as the
boolean false value, but it has historically been used to indicate a
feature that might be enabled -- in JonL White's New Implementation
of Lisp! However, the New Implementation of Lisp is rather old these
days, and unlikely to matter much...until Alastair Bridgewater writes
Nyef's Implementation of Lisp.
,** Documentation
On-line references and documentation/manuals are both useful for
independent purposes, but there is a very fine distinction between
them. Do not generate documentation or manuals automatically from the
text of on-line references.
Rationale: /On-line references/ are quick blurbs associated with
objects in a running Lisp image, such as documentation strings in
Common Lisp or Emacs Lisp. These assume that the reader is familiar
with the gist of the surrounding context, but unclear on details;
on-line references specify the details of individual objects.
/Documentation/ and /manuals/ are fuller, organized, and cohesive
documents that explain the surrounding context to readers who are
unfamiliar with it. A reader should be able to pick a manual up and
begin reading it at some definite point, perusing it linearly to
acquire an understanding of the subject. Although manuals may be
dominated by reference sections, they should still have sections that
are linearly readable to acquaint the reader with context.
,** Round and Square Brackets
Some implementations of Scheme provide a non-standard extension of the
lexical syntax whereby balanced pairs of square brackets are
semantically indistinguishable from balanced pairs of round brackets.
Do not use this extension.
Rationale: Because this is a non-standard extension, it creates
inherently non-portable code, of a nature much worse than using a
name in the program which is not defined by the R5RS. The reason
that we have distinct typographical symbols in the first place is to
express different meaning. The only distinction between round
brackets and square brackets is in convention, but the precise nature
of the convention is not specified by proponents of square brackets,
who suggest that they be used for `clauses', or for forms that are
parts of enclosing forms. This would lead to such constructions as
(let [(x 5) (y 3)] ...)
or
(let ([x 5] [y 3]) ...)
or
(let [[x 5] [y 3]] ...),
the first two of which the author of this guide has seen both of, and
the last of which does nothing to help to distinguish the parentheses
anyway.
The reader of the code should not be forced to stumble over a
semantic identity because it is expressed by a syntactic distinction.
The reader's focus should not be directed toward the lexical tokens;
it should be directed toward the structure, but using square brackets
draws the reader's attention unnecessarily to the lexical tokens.
,* Attribution
:END:
DONE comments
;;;; Frob Grovel
;;; This section of code has some important implications:
;;; 1. Foo.
;;; 2. Bar.
;;; 3. Baz.
(define (fnord zarquon)
;; If zob, then veeblefitz.
(quux zot
mumble ;Zibblefrotz.
frotz))
DONE literal data
Strings
If the form in question is meant to be simply a list of literal data, all of the subforms should be aligned to the same column, irrespective of the first subform.
Unacceptable:
("foo" "bar" "baz" "quux" "zot" "mumble" "frotz" "gargle" "mumph")
Questionable, but acceptable:
(3 1 4 1 5 9 2 6 5 3 5 8 9 7 9 3 2 3 8 4 6 2 6 4 3 3 8 3 2 7 9 5 0 2 8 8 4 1 9 7 1 6 9 3 9 9 3)
Acceptable:
("foo" "bar" "baz" "quux" "zot" "mumble" "frotz" "gargle" "mumph")
TODO follow this syntax convention proc args
("foo" "bar" "baz" "quux" "zot" "mumble" "frotz" "gargle" "mumph")
:alignment: The operator of any form, i.e. the first subform following the opening round bracket, determines the rules for indenting or aligning the remaining forms. Many names in this position indicate special alignment or indentation rules; these are special operators, macros, or procedures that have certain parameter structures.
If the first subform is a non-special name, however, then if the second subform is on the same line, align the starting column of all following subforms with that of the second subform. If the second subform is on the following line, align its starting column with that of the first subform, and do the same for all remaining subforms.
In general, Emacs will indent Lisp code correctly. Run `C-M-q' (indent-sexp) on any code to ensure that it is indented correctly, and configure Emacs so that any non-standard forms are indented appropriately.
Unacceptable:
(+ (sqrt -1) (* x y) (+ p q))
(
(sqrt -1)
(* x y)
( p q))
Acceptable:
(+ (sqrt -1) (* x y) (+ p q))
(
(sqrt -1)
(* x y)
( p q))
Rationale: The columnar alignment allows the reader to follow the operands of any operation straightforwardly, simply by scanning downward or upward to match a common column. Indentation dictates structure; confusing indentation is a burden on the reader who wishes to derive structure without matching parentheses manually.
:END:
If you have a procedure, then it's first arguments should be on the same line.
(proc args
(proc (proc
args)
(proc args)
(proc (proc
args)
(proc (proc
(proc (proc
args))))))
+ (proc (proc
args)))
PROJ things to change based on review (and other stuff I think of) [8/31]
NO consider unexporting . Instead users would just use lists.
I am leaning towards the notion that this is just a bad idea. How would you support something like:
!src regex <"mytable">
configuration would look like this:
(opensmtpd-interface
(interface interface)
(port 465)
(secure-connection "smtps")
(pki smtp.gnucode.me)
(auth
'(("joshua" .
"$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86.")))
(filters (list filter-dkimsign)))
Instead of:
(opensmtpd-interface
(interface interface)
(port 465)
(secure-connection "smtps")
(pki smtp.gnucode.me)
(auth
(opensmtpd-table
(name "creds")
(data
(list
(cons "joshua"
"$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86.")))))
(filters (list filter-dkimsign)))
This would also make project some options require specific types of tables. check man 5 table and enforce those rules void
| pros | cons |
|---|---|
| simpler configuration | harder to program properly |
| easier to sanitize configuration | potentially lose out on filedb option |
| ^ or maybe if the list is long enough | |
| ^ I will just make it use filedb by | |
| ^ default... | |
NO remove opensmtpd-configuration-socket. Put both
and under fieldname opensmtpd-configuration-listen-on
I will have to fix the procedure: get-opensmtpd-filters.
It might actually be much easier to NOT do this, and instead keep putting into opensmtpd-configuration-socket.
Also can smtpd.conf specify mulitple ?
NO should I heavily modify ? to have an options fieldname?
Now I need to fix this.
probably not.
I don't see how this
(opensmtpd-interface
(options
(list
(opensmtpd-option
(option "family")
(data "inet4"))
(opensmtpd-option
(option "mask-src")
(data #t)))))
Than this
(opensmtpd-interface
(family "inet4")
(mask-src #t))
NO check that there are NO two s that share the same port.
Maybe that is ok. Because this is a valid configuration file:
This is perfectly valid, because one is listening on tls and the other is listening on an unencrypted channel.
filter "invalid-fcrdns" phase connect match !fcrdns reject "422 No valid fcrdns."
filter "dkimsign" proc-exec "/gnu/store/rklsc9b0p0bsjh10d5hi2mxiyx2p29pl-opensmtpd-filter-dkimsign-0.5/libexec/opensmtpd/filter-dkimsign -d gnucode.me -s 2021-09-22 -c relaxed/relaxed -k /etc/dkim/private.key user nobody group nogroup"
smtp max-message-size 10M
srs ttl 5d
queue compression
mta max-deferred 50
table creds { "joshua" = "$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86." }
table "virtual" { "josh" = "jbranso@dismail.de" }
table domain-table { "gnucode.me", "gnu-hurd.com" }
listen on lo filter "invalid-fcrdns" tls port 25
listen on lo port 25
listen on lo filter "dkimsign" smtps port 465
listen on lo filter "dkimsign" tls-require port 587
listen on socket
action "relay" relay
action "receive" maildir "/home/%{rcpt.user}/Maildir" junk virtual <"virtual">
match for any from any auth action "relay"
match for domain <domain-table> from any action "receive"
match for local action "receive"
DONE replace my use of hint-string with string-closest from (guix utils)
(use-module (guix utils))
(string-closest "that" (list "the" "hat" "jam" "auth"))
DONE I should modify (opensmtpd-option ) fieldname 'not' to 'bool'.
And make bool by default be #t.
That way (opensmtpd-option (option "auth")) still means to auth, but users don't have to do weird conversion in their head...
What does (opensmtpd-option (option "auth") (not #t)) mean? it means !auth.
Now (opensmtpd-option (option "auth") (bool #f)) means !auth
now (opensmtpd-option (option "auth")) AND (opensmtpd-option (option "auth") (bool #t))
DONE sent a patch to source hut
are identical.
https://git.sr.ht/~whereiseveryone/guixrus/commit/255875f7d8
We received your email, but were unable to deliver it because the mailing list you wrote to was not found. The correct posting addresses are:
~username/list-name@lists.sr.ht
~whereiseveryone/guixrus@lists.sr.ht
Or if your mail system has trouble sending to addresses with ~ or / in them, you can use:
u.username.list-name@lists.sr.ht
u.whereiseveryone.guixrus@lists.sr.ht
If your mail system does not support our normal posting addresses, we would appreciate it if you wrote to your mail admin to ask them to fix their system. Our posting addresses are valid per RFC-5322.
If you have any questions, please reply to this email to reach the mail admin. We apologise for the inconvenience.
Here are there latest patches.
DONE ensure that users cannot make senders #f and masquerade #t of <opensmtpd-interface>.
(opensmtpd-interface
(senders #f)
(masquerade #t))
TODO try to generate nckx's smptd.conf
:smtpdConf: MX = "mx.my.domain" RX = "submission.my.domain" TX = "my.domain"
bounce warn-interval 1d queue ttl 365d smtp max-message-size 1G
pki "*" cert "/etc/dehydrated/legacy/my.domain/fullchain.pem" pki "*" key "/etc/dehydrated/legacy/my.domain/privkey.pem"
table domains { $TX, "some.other.domain" } table auths file:/etc/guix/mail/passwd table virtuals file:/etc/guix/mail/virtuals table deadends file:/etc/guix/mail/deadends table spammers file:/etc/guix/mail/spammers table spamexes file:/etc/guix/mail/spamexes
filter out proc-exec \ "/run/current-system/profile/libexec/opensmtpd/filter-dkimsign\ -d my.domain -s 2018 -c relaxed/relaxed -k /etc/guix/mail/dkimproxy.key" \ user nobody group nogroup # must be able to read the -k(ey file)
V6 = "::" V4 = "0.0.0.0"
listen on $V6 smtps auth-optional hostname $RX mask-src tag out filter out listen on $V4 smtps auth-optional hostname $RX mask-src tag out filter out listen on $V6 port submission tls auth-optional hostname $RX mask-src tag out filter out listen on $V4 port submission tls auth-optional hostname $RX mask-src tag out filter out
filter "fcrdns" phase commit match ! fcrdns disconnect "441 Retry later" # lie table ddns { "\.access\..*\.", "\.dyn\.", "dsl\.", "usercontent" } filter "dyndns" phase commit match rdns regex disconnect "442 Retry later" filter in chain { "dyndns" }
listen on $V6 tls hostname $MX no-dsn filter in listen on $V4 tls hostname $MX no-dsn filter in
listen on $V6 port 26 hostname $MX no-dsn filter in
listen on 127.0.0.1 port 1026 hostname "DKIM-proxy" tag scanned
action send relay helo $TX match tag out from auth for any action send match tag out from local for any action send # e.g. Dovecot Sieve
action deliver lmtp "/var/run/dovecot/lmtp" rcpt-to virtual match tag scanned from local for any action deliver
match from mail-from reject match from mail-from regex reject match ! from local rcpt-to reject
action scan relay host smtp+notls://127.0.0.1:1025 helo $MX match from any for domain action scan :END:
TODO opensmtpd-relay-srs
>> +@item @code{srs} (default: @code{#f}) >> +If @code{#t}, then when relaying a mail resulting from a forward, >> use the Sender >> +Rewriting Scheme to rewrite sender address. >> + >> +@item @code{tls} (default: @code{#f}) boolean or string ``no- >> verify'' > Instead of a string, take 'no-verify as symbol perhaps?
TODO what does rewrite needs value mean? Should it be a number? this is for <opensmtpd-filter-phase>
from the documentation
TODO I can use guile-lib to time my functions in this program:
rewrite value the command parameter is rewritten with value
info '(guile-library)' 7 Debbugging time
TODO dkimvalidator says my SPF is failing: https://dkimvalidator.com/
This may help me to discover performance issues.
it mentions locke-lamora. anyway. I should try to fix that at some point.
PROJ should I give all opensmtpd records default values?
This could be why my email is failing to be delivered to source hut.
I feel like most users will be using opensmtpd in pretty obvious ways.
Probably for simple maildir set ups with dovecot serving the emails. Perhaps I should set apprpopriate default values. It may make using the service much easier.
TODO the default value for opensmtpd-match be
(opensmtpd-match
(options
(list
(opensmtpd-option
(option "for local"))))
(action (opensmtpd-local-delivery
(name "%local%")
(method "maildir"))))
TODO it would probably be a GREAT idea to convert my records into define-configuration.
(gnu services configuration)
define-configuration would cut down on a LOT of the code that I have already written, and it would help me generate documentation.
| pros | cons |
|---|---|
| smaller code base | generated documentation looks awful |
| less work to maintain documentation if the service changes | a lot of work to implement |
| more developers will understand the code | I might lose some great error reporting |
-
These three functions work really well in define-record-type*, but I may have to
work a little hard to get them to work in define-configuration:
- (sanitize-options-for-filter-phase-configuration,
- (sanitize-each-socket-and-interfaces-filters, and
- (sanitize-list-of-options-for-match-configuration
But I could still use those fantastic functions to spot errors. It might look like:
(define-configuration opensmtpd-match
(options
(list-of-opensmtpd-option '()))
"A list of @code{opensmtpd-option} records.")
And then in the activation function, I will look through the object, for records. For each record I will call sanitize-list-of-options-for-match-configuration.
TODO consider using latex fractions instead of org tables
TODO can I remove false? function and use not instead?
TODO simplify my sanitizing funcions (any (cut <> var))
I will use the other two functions in the same way.
(use-modules (ice-9 curried-definitions)
(srfi srfi-26))
(define (((expect-any predicates) record field) var)
(if (any (cut <> var) predicates)
var
(begin ;; the begin block could be made a little better.
(display "error")
(throw 'bad! var))))
;; here is how you use it.
(name opensmtpd-table-name ;; string
(default #f)
(sanitize (lambda (var)
(((expect-any (list string? number?)) "hello" "that") var))))
TODO change add-comma-or to this
(define (procedure->string) ...) (define (procedures->string list) (define strings (map procedure->string list)) (string-append (string-join (drop-right strings 1) ", ") (if (> (length list) 1) ", or") (last strings) ".\n"))
TODO does guix have sanitizers that are better than mine?
Possibly, but where are they? My sanitizers check for quite a few things!
TODO how can I write a test that checks for an that has no filters?
but I have not actually checked guix's sanitizers.
How do I make sure this doesn't happen again?
The problem was with the procedure get-opensmtpd-filters. BUT that procedure is NOT exported.
;; there are no filters
(let ([interface "lo"])
(opensmtpd-configuration
(interfaces
(list
;; send out emails and be sure to dkimsign them.
(opensmtpd-interface
(interface interface))))
(matches (list
(opensmtpd-match
(action (opensmtpd-relay
(name "relay")))
(options (list (opensmtpd-option
(option "for any"))
(opensmtpd-option
(option "from any"))
(opensmtpd-option
(option "auth")))))))))
$12 = #<<opensmtpd-configuration> package: #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7ae9f363a580> config-file: #f bounce: #f cas: #f interface: (#<<opensmtpd-interface> interface: "lo" family: #f auth: #f auth-optional: #f filters: #f hostname: #f hostnames: #f mask-src: #f disable-dsn: #f pki: #f port: #f proxy-v2: #f received-auth: #f secure-connection: #f tag: #f>) socket: #f includes: #f matches: (#<<opensmtpd-match> action: #<<opensmtpd-relay> name: "relay" backup: #f backup-mx: #f helo: #f helo-src: #f domain: #f host: #f pki: #f srs: #f tls: #f auth: #f mail-from: #f src: #f> options: (#<<opensmtpd-option> option: "for any" not: #f regex: #f data: #f> #<<opensmtpd-option> option: "from any" not: #f regex: #f data: #f> #<<opensmtpd-option> option: "auth" not: #f regex: #f data: #f>)>) mda-wrappers: #f mta-max-deferred: 100 queue: #f smtp: #f srs: #f setgid-commands?: #t>
scheme@(gnu services mail) [13]> (opensmtpd-configuration->mixed-text-file $12)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(gnu services mail) [14]> ,bt
In gnu/services/mail.scm:
3733:65 2 (opensmtpd-configuration->mixed-text-file #<<opensmtpd-configuration> package: #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7ae9f3…>)
3599:8 1 (get-opensmtpd-filters #<<opensmtpd-configuration> package: #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7ae9f363a580> config-file…>)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
scheme@(gnu services mail) [16]> (get-opensmtpd-filters $12)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
TODO make sure that the example configuration in guix.texi actually works
TODO make list-of-procedures->string not do the below
Be sure to include a opensmtpd-table and opensmtpd-option.
Using a table, map and string-join might be wiser. If this is the only place add-comma-or is used, you can replace it by (string-append (string-join (butlast strings) ",") ", or " (last strings)) where you only need to define butlast. (define (add-comma-or2 %list) (string-append (string-join (butlast %list) ",") ", or " (last %list)))
TODO tell f3n1x when I set up the opensmtpd channel. So he can try it
TODO make the tests NOT display output
TODO test Example configuration in a vm
TODO should I remove throw-error and throw-error-duplicate-option? and variable->string?
(define (butlast %list) (if (= 2 (length %list)) (string-append (car %list)) (string-append (car %list) (string-append (butlast (cdr %list))))))
TODO I currently do NOT support tables like: user1 otheruser1,otheruser2. I should add support for that. [1/4]
Most of the guix source code doesn't define simple functions like this, and that makes their source code really simple and easy to follow.
Is this valid syntax? YES!
table "virtual" { "josh" = "jbranso@dismial.de,joshua@dismail.de,root@gnu.org" \ "james" = "james@gnu.org,james@dismail.de"}
It is valid, however, does this let "josh" send email as "jbranso@dismail.de" & "joshua@dismail.de" & "root@gnu.org" ?
- users can define
nested-list tableslike this:
#+BEGIN_SRC scheme (opensmtpd-table (name "table") (data '(("joshua" "joshua@dismail.de" "joshua@gnu-hurd.com") ("root" "root@gnu.org")))) #+END_SRC
OR gets auto translated into an /etc/aliases file.
DONE create a tables-data-is-a-multi-list? procedure
TODO modify opensmtpd-table->string to support multi-list tables.
TODO modify guix.texi to include a nested-list opensmtpd-table.
TODO The question I need to post somewhere or discover for myself:
is this the same?
smtpd.conf:
table "senders" { "user1" = "user1@dismial.de,user1@gnu-hurd.com,user1@gnu.org" \ "james" = "james@gnu.org,james@dismail.de"}
/etc/aliases
user1 user1@dismail.de,user1@gnu-hurd.com,user1@gnu.org james james@gnu.org,james@dismail.de
TODO fix my documentation. There are line breaks after the bullet points and there should NOT be.
PROJ some options require specific types of tables. check man 5 table and enforce those rules [2/7]
PROJ virtual tables require a mapping [0/2]
- OR users could use vectors, but that seems silly. and I don't know how to do it This is wrong:
table "virtual" { "josh" , "jbranso@dismail.de" }
action "receive" maildir "/home/%{rcpt.user}/Maildir" junk virtual <"virtual">
TODO The virtual table, needs an alist or key value pair mapping like this:
table "virtual" { "josh" = "jbranso@dismail.de" }
(opensmtpd-local-delivery
(name "receive")
(method (opensmtpd-maildir
(pathname "/home/%{rcpt.user}/Maildir")))
(virtual (opensmtpd-table
(name "virt")
(data (list "jbranso@dismail.de")))))
Aliasing tables Aliasing tables are mappings that associate a recipient to one or many destinations. They can be used in two contexts: primary domain aliases and virtual domain mapping.
action name method alias
In a primary domain context, the key is the user part of the recipient address, whilst the value is one or many recipients as described in aliases(5):
user1 otheruser user2 otheruser1,otheruser2 user3 otheruser@example.com
In a virtual domain context, the key is either a user part, a full email address or a catch all, following selection rules described in smtpd.conf(5), and the value is one or many recipients as described in aliases(5):
user1 otheruser user2@example.org otheruser1,otheruser2 @example.org otheruser@example.com @ catchall@example.com
The following directive shares the same table format, but with a different meaning. Here, the user is al‐ lowed to send mail from the listed addresses:
TODO so does the alias table
TODO domain tables are lists and NOT mappings
listen on interface auth [...] senders
match for domain
In that context, the list of domains will be matched against the recipient domain or against the HELO name advertised by the sending host, respectively. For ‘static’, ‘file’ and dbopen(3) backends, a wildcard may be used so the domain table may contain:
example.org *.example.org
TODO credential tables must be quoted
Credentials tables Credentials tables are mappings of credentials. They can be used in two contexts:
listen on interface tls [...] auth
In a listener context, the credentials are a mapping of username and encrypted passwords:
user1 $2b$10$hIJ4QfMcp.90nJwKqGbKM.MybArjHOTpEtoTV.DgLYAiThuoYmTSe user2 $2b$10$bwSmUOBGcZGamIfRuXGTvuTo3VLbPG9k5yeKNMBtULBhksV5KdGsK
The passwords are to be encrypted using the smtpctl(8) encrypt subcommand.
In a relay context, the credentials are a mapping of labels and username:password pairs:
label1 user:password
The label must be unique and is used as a selector for the proper credentials when multiple credentials are valid for a single destination. The password is not encrypted as it must be provided to the remote host.
DONE netaddr are lists and NOT mappings
Netaddr tables Netaddr tables are lists of IPv4 and IPv6 network addresses. They can only be used in the following con‐ text:
match from src
When used as a "from source", the address of a client is compared to the list of addresses in the table until a match is found.
A netaddr table can contain exact addresses or netmasks, and looks as follow:
192.168.1.1 ::1 ipv6:::1 192.168.1.0/24
DONE source tables are lists and NOT mappings
Source tables Source tables are lists of IPv4 and IPv6 addresses. They can only be used in the following context:
action name relay src
Successive queries to the source table will return the elements one by one.
A source table looks as follow:
192.168.1.2 192.168.1.3 ::1 ::2 ipv6:::3 ipv6:::4
TODO user info tables are mappings and NOT lists
Userinfo tables User info tables are used in rule context to specify an alternate user base, mapping virtual users to lo‐ cal system users by UID, GID and home directory.
action name method userbase
A userinfo table looks as follows:
joe 1000:100:/home/virtual/joe jack 1000:100:/home/virtual/jack
In this example, both joe and jack are virtual users mapped to the local system user with UID 1000 and GID 100, but different home directories. These directories may contain a forward(5) file. This can be used in conjunction with an alias table that maps an email address or the domain part to the desired virtual username. For example:
joe@example.org joe jack@example.com jack
TODO mailaddr tables are lists and NOT mappings
Mailaddr tables Mailaddr tables are lists of email addresses. They can be used in the following contexts:
match mail-from
A mailaddr entry is used to match an email address against a username, a domain or a full email address. A "*" wildcard may be used in part of the domain name.
A mailaddr table looks as follow:
PROJ sanitize the interface better
TODO is it possible to define hostname & hostnames?
user @domain user@domain user@*.domain
(opensmtpd-configuration
(interface
(list
(opensmtpd-interface
(hostname "gnu.org")
(hostnames (opensmtpd-table
(name "hostnames")
(data '(("gnu.org" . "yahoo.com")))))))))
PROJ awesome thing to eventually do
TODO make it easy to configure dkimsigning for users
TODO made code that converts "for any" into (opensmtpd-table (option "for any"))
aka auto set up and create the public signing key.
That way users can specify an option list like:
TODO make it easy to configure bogofilter or rspamd
TODO use the (guix diagnostics) module to use proper error messages if the service is
TODO add a test for the pkis to test to see if it is a valid cert.
(list "for any" "from any") and it will get auto converted into the proper tables. configured incorrectly.
basically you would generate a simple ->mixed-text-file, then call smptd -fc on that file. to see if it gives you a "cannot load cert" error.
TODO use match-record for the shepherd activation. instead of using the list.
PROJ things to NOT do
TODO check to make sure you have no filters with the same name, but different procs.
Bug 59390 should give me some examples.
I might just NOT implement this, and let the smtpd daemon catch this error.
Here is a test bit for it.
;; the filters have the same name, BUT different 'proc'. ;; the fix is to have them have different commands. (define (bad-opensmtpd-configuration1) (create-bad-record (let ([interface "lo"] [filter-dkimsign1 (opensmtpd-filter (name "dkimsign") (exec #t) (proc (list (file-append opensmtpd-filter-dkimsign "/libexec/opensmtpd/filter-dkimsign") " -d gnucode.me -s 2021-09-22 -c relaxed/relaxed -k " "/etc/dkim/private.key " "user nobody group nogroup")))] [filter-dkimsign2 (opensmtpd-filter (name "dkimsign") (exec #t) (proc (list (file-append opensmtpd-filter-dkimsign "/libexec/opensmtpd/filter-dkimsign") " -d gnu-hurd.com -s 1991-01-02 -c relaxed/relaxed -k " "/etc/dkim/private2030203203.key " "user nobody group nogroup")))]) (opensmtpd-configuration (interface (list (opensmtpd-socket (filters (list filter-dkimsign1))) ;; send out emails and be sure to dkimsign them. (opensmtpd-interface (interface interface) (filters (list filter-dkimsign2))))) (matches (list (opensmtpd-match (action (opensmtpd-relay (name "relay"))) (options (list (opensmtpd-option (option "for any")) (opensmtpd-option (option "from any")) (opensmtpd-option (option "auth")))))))))))
TODO check for duplicate items.
If the user accidentally creates an with a list of filters that has the same filter twice, perhaps I should just let the smtpd daemon catch the error.
Another example is this one:
;; the matches have two actions with the same name, ;; but are different actions. (define (bad-configuration1) (create-bad-record (opensmtpd-configuration (matches (list (opensmtpd-match (action (opensmtpd-local-delivery (name "my-local-delivery") (ttl "50m")))) (opensmtpd-match (action (opensmtpd-local-delivery (name "my-local-delivery") (ttl "50h")))))))))
NO sanitize fieldname 'matches' so that no two unique actions have the same name
I definitely should sanitize 'matches' a bit more. For example, you could have two different actions, one for local delivery and one for remote, with the same name. I should make sure that all different actions have unique names.
Here is an example of two actions that have the same name, but different ttl values:
This should yeild an error.
(opensmtpd-configuration
(matches
(list (opensmtpd-match
(options
(list
(opensmtpd-option
(option "for local"))))
(action
(opensmtpd-local-delivery
(name "my-local-delivery")
(ttl "50m"))))
(opensmtpd-match
(options
(list (opensmtpd-option
(option "for any"))))
(action
(opensmtpd-local-delivery
(name "my-local-delivery")
(ttl "50h")))))))
Here is an example of two actions with the same name that are ok. eg: two different matches share the same action.
(opensmtpd-configuration
(matches
(list (opensmtpd-match
(options
(list
(opensmtpd-option
(option "for local"))))
(action
(opensmtpd-local-delivery
(name "my-local-delivery"))))
(opensmtpd-match
(options
(list (opensmtpd-option
(option "for any"))))
(action
(opensmtpd-local-delivery
(name "my-local-delivery")))))))
TODO OpenSMTPD Service documentation
THIS DOCUMENTATION IS OUT OF DATE:
Please look at this updated documentation.
OpenSMTPD is an easy-to-use mail transfer agent (MTA). Its configuration file is
throughly documented in man 5 smtpd.conf. OpenSMTPD listens for incoming
mail and matches the mail to actions. The following records represent those
stages:
| listens | <opensmtpd-interface |
<opensmtpd-socket> |
|
| matches | <opensmtpd-match> |
| actions | <opensmtpd-local-delivery> |
<opensmtpd-relay> |
Additionally, each <opensmtpd-interface> and
~~ may use a list of
~~, and/or
~~ records to filter email/spam. Also
numerous records' fieldnames use <opensmtpd-table> to hold lists
or key value pairs of data.
Finally, both <opensmtpd-match> and
~~ use <opensmtpd-option> to configure various options.
A simple example configuration is below:
(let ((smtp.gnu.org (opensmtpd-pki
(domain "smtp.gnu.org")
(cert "file.cert")
(key "file.key"))))
(service opensmtpd-service-type
(opensmtpd-configuration
(interface (list
(opensmtpd-interface
(pki smtp.gnu.org))
(opensmtpd-interface
(pki smtp.gnu.org)
(secure-connection "smtps"))))
(matches (list
(opensmtpd-match
(action
(opensmtpd-local-delivery
(name "local-delivery"))))
(opensmtpd-match
(action
(opensmtpd-relay
(name "relay")))))))))
- Scheme Variable: opensmtpd-service-type
Service type for the OpenSMTPD (https://www.opensmtpd.org) email server. The
value for this service type is a <opensmtpd-configuration> record.
- Data Type: opensmtpd-configuration
Data type representing the configuration of OpenSMTPD.
package(default:opensmtpd)
The OpenSMTPD package to use.
config-file(default:#f)
File-like object of the OpenSMTPD configuration file to use. By default it
listens on the loopback network interface, and allows for mail from users
and daemons on the local machine, as well as permitting email to remote
servers. Run man smtpd.conf for more information.
bounce(default:(list "4h"))
bounce is a list of strings (max length 4), which send warning messages
to the envelope sender when temporary delivery failures cause a message to
remain in the queue for longer than string delay. Each string _delay_
parameter consists of a string beginning with a positive decimal integer
and a unit 's', 'm', 'h', or 'd'. At most four delay parameters can be
specified.
interface(default:(list (opensmtpd-interface)))
interface is a list of <opensmtpd-interface> records.
This list details what interfaces and ports OpenSMTPD listens on as well as
other information.
socket(default:(opensmtpd-socket-configuration))
Listens for incoming connections on the Unix domain socket.
includes(default:#f)
# TODO includes should support a list of string filenames or gexps.
includes is a list of string filenames. Each filename's contents is
additional configuration that is inserted into the top of the configuration
file.
matchesdefault:
#+BEGIN_SRC scheme (list (opensmtpd-match (action (opensmtpd-local-delivery (name "local") (method "mbox"))) (for (opensmtpd-option (option "for local")))) (opensmtpd-match (action (opensmtpd-relay (name "outbound"))) (from (opensmtpd-option (option "from local"))) (for (opensmtpd-option (option "for any"))))) #+END_SRC
matches is a list of <opensmtpd-match> records, which
matches incoming mail and sends it to a correspending action. The
match records are evaluated sequentially, with the first match winning. If
an incoming mail does not match any match records, then it is rejected.
# TODO when the code supports mda-wrappers, add in this documentation.
# - mda-wrappers
mta-max-deferred(default:100)
When delivery to a given host is suspended due to temporary failures, cache at most number envelopes for that host such that they can be delivered as soon as another delivery succeeds to that host. The default is 100.
queue(default:#f)
queue expects an <opensmtpd-queue> record. With it, one may
compress and encrypt queue-ed emails as well as set the default expiration
time for temporarily undeliverable messages.
smtp(default:#f)
smtp expects an <opensmtpd-smtp> record, which lets one
specifiy how large email may be along with other settings.
srs(default:#f)
srs expects an <opensmtpd-srs> record, which lets one set
up SRS, the Sender Rewritting Scheme.
- Data Type: opensmtpd-interface
Data type representing the configuration of an
<opensmtpd-interface>. Listen on the fieldname interface for
incoming connections, using the same syntax as for ifconfig(8). The interface
parameter may also be an string interface group, an string IP address, or a
string domain name. Listening can optionally be restricted to a specific
address fieldname family, which can be either "inet4" or "inet6".
interface(default: "lo")
The string interface to listen for incoming connections. These interface can
usually be found by the command ip link.
family(default:#f)
The string IP family to use. Valid strings are "inet4" or "inet6".
auth(default:#f)
Support SMTPAUTH: clients may only start SMTP transactions after successful
authentication. If auth is #t, then users are authenticated against
their own normal login credentials. Alternatively auth may be an
<opensmtpd-table> whose users are authenticated against
their passwords.
auth-optional(default:#f)
Support SMTPAUTH optionally: clients need not authenticate, but may do so.
This allows the <opensmtpd-interface> to both accept
incoming mail from untrusted senders and permit outgoing mail from
authenticated users (using <opensmtpd-match> fieldname
auth). It can be used in situations where it is not possible to listen on
a separate port (usually the submission port, 587) for users to
authenticate.
filters(default:#f)
A list of one or many <opensmtpd-filter> or
<opensmtpd-filter-phase> records. The filters are applied
sequentially. These records listen and filter on connections handled by this
listener.
hostname(default:#f)
Use string "hostname" in the greeting banner instead of the default server name.
hostnames(default:#f)
Override the server name for specific addresses. Use a
<opensmtpd-table> containing a mapping of string IP
addresses to hostnames. If the address on which the connection arrives
appears in the mapping, the associated hostname is used.
mask-src(default:#f)
If #t, then omit the from part when prepending “Received” headers.
disable-dsn(default:#f)
When #t, then disable the DSN (Delivery Status Notification) extension.
pki(default:#f)
For secure connections, use an ~~ to prove a mail server's identity.
port(default:#f)
Listen on the integer port instead of the default port of 25.
proxy-v2(default:#f)
If #t, then support the PROXYv2 protocol, rewriting appropriately source
address received from proxy.
received-auth(default:#f)
If #t, then in “Received” headers, report whether the session was
authenticated and by which local user.
senders(default:#f)
Look up the authenticated user in the supplied
<opensmtpd-table> to find the email addresses that user is
allowed to submit mail as.
secure-connection(default:#f)
This is a string of one of these options:
|----------------------+---------------------------------------------| | "smtps" | Support SMTPS, by default on port 465. | | | | | "tls" | Support STARTTLS, by default on port 25. | | | | | "tls-require-verify" | Like tls, but force clients to establish | | | a secure connection before being allowed to | | | start an SMTP transaction. With the verify | | | option, clients must also provide a valid | | | certificate to establish an SMTP session. | |----------------------+---------------------------------------------|
tag(default:#f)
Clients connecting to the listener are tagged with the given string tag.
- Data Type: opensmtpd-socket
Data type representing the configuration of an
<opensmtpd-socket>. Listen for incoming SMTP
connections on the Unix domain socket /var/run/smtpd.sock. This is done by
default, even if the directive is absent.
filters(default:#f)
A list of one or many <opensmtpd-filter> or
<opensmtpd-filter-phase> records. These filter incoming
connections handled by this listener.
mask-src(default:#f)
If #t, then omit the from part when prepending “Received” headers.
tag(default:#f)
Clients connecting to the listener are tagged with the given string tag.
- Data Type: opensmtpd-match
This data type represents the configuration of an
<opensmtpd-match> record.
If at least one mail envelope matches the options of one match record, receive
the incoming message, put a copy into each matching envelope, and atomically
save the envelopes to the mail spool for later processing by the respective
<opensmtpd-action-configuration> found in fieldname action.
action(default:#f)
If mail matches this match configuration, then do this action. Valid values
include <opensmtpd-local-delivery> or
<opensmtpd-relay>.
options(default:#f)<opensmtpd-option>
The fieldname 'option' is a list of unique
~~ records.
- "for any" #+BEGIN_SRC scheme (opensmtpd-option (option "for any")) #+END_SRC
- "for rcpt" domain | #+BEGIN_SRC scheme (opensmtpd-option (option "for rcpt") (data "domain")) #+END_SRC
for anyfor localfor domain _domain_ | <domain>for rcpt-to _recipient_ | <recipient>from anyfrom authfrom auth _user_ | <user>from localfrom mail-from _sender_ | <sender>from rdnsfrom rdns _hostname_ | <hostname>from socketfrom src _address_ | <address>authauth _username_ | <username>helo _helo-name_ | <helo-name>mail-from _sender_ | <sender>rcpt-to _recipient_ | <recipient>tag tag
Matches transactions tagged with the given _tag_.
tls
Specify that transaction should take place in a TLS channel.
- Data Type: opensmtpd-local-delivery
name(default:#f)method(default:"mbox")"mbox""expand-only""forward-only"<opensmtpd-lmtp-configuration><opensmtpd-maildir><opensmtpd-mda>alias(default:#f)ttl(default:#f)user(default:#f)userbase(default:#f)virtual(default:#f)- Data Type: opensmtpd-relay
name(default:#f)backup(default:#f)backup-mx(default:#f)helo(default:#f)helo-src(default:#f)domain(default:#f)host(default:#f)pki(default:#f)srs(default:#f)tls(default:#f) boolean or string "no-verify"auth(default:#f)<opensmtpd-table>mail-from(default:#f) stringsrc(default:#f) string |<opensmtpd-table>- Data Type: opensmtpd-filter @c The code does NOT actually support these things yet.
name(default:#f)proc(default:#f)proc-exec(default:#f)- Data Type: opensmtpd-filter-phase
name(default:#f)phase-name(default:#f)options(default#f)decisionmessage(default#f)value(default:#f)- Data Type: opensmtpd-option
conditition(default#f)data(default#f)<opensmtpd-table>regex(default:#f) booleannot(default:#f) boolean- Data Type: opensmtpd-table
name(default#f)data(default:#f)- Data Type: opensmtpd-pki
domain(default#f)cert(default:#f)key(default:#f)dhe(default:"none")- Data Type: opensmtpd-maildir
pathname(default:"~/Maildir")junk(default:#f)- Data Type: opensmtpd-mda # Do we need a dataypte for mda configuration? # this could just be a gexp in the fieldname opensmtpd-configuration-mda
namecommand- Data Type: opensmtpd-queue
compression(default#f)encryption(default#f)ttl-delay(default#f)- Data Type: opensmtpd-smtp
ciphers(default:#f)limit-max-mails(default:100)limit-max-rcpt(default:1000)max-message-size(default:35M)sub-addr-delim character(default:+)- Data Type: opensmtpd-srs
key(default:#f)backup-key(default:#f)ttl-delay(default:"4d")- Format Specifiers
- It is entirely possible, that it would be better for users to manually generate their own passwords. And NOT allow the service to generate those passwords for them. If that is your opinion, don't hesitate to let me know. :)
- State "TODO" from [2021-11-02 Tue 04:08] :END:
- could be a filter that is defined but never used, which won't be possible once [[id:89603b3f-7580-4531-8aee-2c115c97adfe][remove opensmtpd-configuration-filters]] is done.
- (listen-on (interface "doesNotExist"))
- (smtp-configuration (smtp-max-message-size "10G")) Are you sure you want emails that large?
- (pki (domain "name") (key "notAKeyfile.txt") (cert "notACertFile.txt")
- (ca (file "NotACaFile.txt"))
Each <opensmtpd-option> record's fieldname 'option' has
some mutually exclusive options: there can be only one "for" and only one
"from" option.
|--------------------------------+--------------------------------| | for | from | |--------------------------------+--------------------------------| | only use one of the following: | only use one of the following: | |--------------------------------+--------------------------------| | "for any" | "from any" | | "for local" | "from auth" | | "for domain" | "from local" | | "for rcpt-to" | "from mail-from" | | | "from socket" | | | "from src" | |--------------------------------+--------------------------------|
Additionally, some options require additional data via their fieldname
data. The following list will explain the below syntax.
OR #+BEGIN_SRC scheme (opensmtpd-option (option "for rcpt") (data (list "gnu.org" "fsf.org"))) #+END_SRC
The following matching options are supported and can all be negated (via not #t). The options that support a table (anything surrounded with '<' and '>' eg:
Specify that session may address any destination.
Specify that session may address any local domain. This is the default, and may be omitted.
Specify that session may address the string or list table domain.
Specify that session may address the string or list table recipient.
Specify that session may originate from any source.
Specify that session may originate from any authenticated user, no matter the source IP address.
Specify that session may originate from authenticated user or user list user, no matter the source IP address.
Specify that session may only originate from a local IP address, or from the local enqueuer. This is the default, and may be omitted.
Specify that session may originate from sender or table sender, no matter the source IP address.
Specify that session may only originate from an IP address that resolves to a reverse DNS.
Specify that session may only originate from an IP address that resolves to a reverse DNS matching string or list string hostname.
Specify that session may only originate from the local enqueuer.
Specify that session may only originate from string or list table address which can be a specific address or a subnet expressed in CIDR-notation.
Matches transactions which have been authenticated.
Matches transactions which have been authenticated for user or user list username.
Specify that session's HELO / EHLO should match the string or list table helo-name.
Specify that transactions's MAIL FROM should match the string or list table sender.
Specify that transaction's RCPT TO should match the string or list table recipient.
Here is a simple example that rejects email from the domains =gnu.org= or =dismail.de=: ,#+BEGIN_SRC scheme (opensmtpd-option (not #t) (regex #f) (option "for domain") (data (opensmtpd-table (name "domain-table") (data (list "gnu.org" "dismail.de"))))) #+END_SRC
This data type represents the configuration of an
<opensmtpd-local-delivery> record.
name is the string name of the relay action.
The email delivery option. Valid options are:
Deliver the message to the user's mbox with mail.local(8).
Only accept the message if a delivery method was specified in an aliases or _.forward file_.
Only accept the message if the recipient results in a remote address after the processing of aliases or forward file.
Deliver the message to an LMTP server at
<opensmtpd-lmtp-configuration>~'s fieldname ~destination. The location
may be expressed as string host:port or as a UNIX socket. Optionally,
<opensmtpd-lmtp-configuration>~'s fieldname ~rcpt-to might be specified
to use the recipient email address (after expansion) instead of the local
user in the LMTP session as RCPT TO.
Deliver the message to the maildir in
<opensmtpd-maildir>~'s fieldname ~pathname if specified,
or by default to ~/Maildir.
The pathname may contain format specifiers that are expanded before use (see the below section about Format Specifiers).
If <opensmtpd-maildir>~'s record fieldname ~junk is #t,
then message will be moved to the ‘Junk’ folder if it contains a positive
‘X-Spam’ header. This folder will be created under fieldname pathname if
it does not yet exist.
Delegate the delivery to the <opensmtpd-mda>~'s fieldname
~command (type string) that receives the message on its standard input.
The command may contain format specifiers that are expanded before use
(see Format Specifiers).
Use the mapping table for aliases expansion. alias is an
<opensmtpd-table>.
ttl is a string specify how long a message may remain in the queue. It's
format is n{s|m|h|d}. eg: "4m" is four minutes.
user is the string username for performing the delivery, to be looked up
with getpwnam(3).
This is used for virtual hosting where a single username is in charge of handling delivery for all virtual users.
This option is not usable with the mbox delivery method.
userbase is an <opensmtpd-table> record for mapping user
lookups instead of the getpwnam(3) function.
The fieldnames user and userbase are mutually exclusive.
virtual is an <opensmtpd-table> record is used for virtual
expansion.
# TODO man 5 smtpd.conf says "The aliasing table format is described in
# table(5)." What is virtual expansion? I do NOT know how to use ~virtual~
# properly. What sort of do I need? does the
# below work?
# (opensmtpd-table (name "virtual") (data '(("joshua" . "jbranso@dismail.de"))))
# TODO fix this wrapper documentation. Should it accept an
# ? If so, then I need to write an
# - wrapper (default: )
# TODO double check that these options are all correct
This data type represents the configuration of an
<opensmtpd-relay> record.
name is the string name of the relay action.
When #t, operate as a backup mail exchanger delivering messages to any
mail exchanger with higher priority.
Operate as a backup mail exchanger delivering messages to any mail exchanger with higher priority than mail exchanger identified as string name.
Advertise string heloname as the hostname to other mail exchangers during the HELO phase.
Use the mapping <openmstpd-table-configuration> to look up a hostname
matching the source address, to advertise during the HELO phase.
Do not perform MX lookups but look up destination domain in an
<opensmtpd-table> and use matching relay url as relay host.
Do not perform MX lookups but relay messages to the relay host described by
the string relay-url. The format for relay-url is
[proto://[label@]]host[:port]. The following protocols are available:
|------------+----------------------------------------------------------------| | smtp | Normal SMTP session with opportunistic STARTTLS (the default). | | smtp+tls | Normal SMTP session with mandatory STARTTLS. | | smtp+notls | Plain text SMTP session without TLS. | | lmtp | LMTP session. port is required. | | smtps | SMTP session with forced TLS on connection, default port is | | | 465. | |------------+----------------------------------------------------------------|
Unless noted, port defaults to 25.
The label corresponds to an entry in a credentials table, as documented in
table(5). It is used with the "smtp+tls" and "smtps" protocols for
authentication. Server certificates for those protocols are verified by
default.
For secure connections, use the certificate associated with
<opensmtpd-pki> (declared in a pki directive) to prove the
client's identity to the remote mail server.
If #t, then when relaying a mail resulting from a forward, use the Sender
Rewriting Scheme to rewrite sender address.
When #t, Require TLS to be used when relaying, using mandatory STARTTLS by
default. When used with a smarthost, the protocol must not be
"smtp+notls://". When string "no-verify", then do not require a valid
certificate.
Use the alist <opensmtpd-table> for connecting to relay-url
using credentials. This option is usable only with fieldname host option.
Use the string mailaddress as MAIL FROM address within the SMTP transaction.
Use the string or <opensmtpd-table> sourceaddr for the
source IP address, which is useful on machines with multiple interfaces. If
the list contains more than one address, all of them are used in such a way
that traffic is routed as efficiently as possible.
This data type represents the configuration of an
<opensmtpd-filter>. This is the filter record one should use
if they want to use an external package to filter email eg: rspamd or
spamassassin.
The string name of the filter.
# TODO let proc be a gexp
The string command or process name. If proc-exec is #t, proc is
treated as a command to execute. Otherwise, it is a process name.
This data type represents the configuration of an
<opensmtpd-filter-phase>.
In a regular workflow, smtpd(8) may accept or reject a message based only on the content of envelopes. Its decisions are about the handling of the message, not about the handling of an active session.
Filtering extends the decision making process by allowing smtpd(8) to stop at each phase of an SMTP session, check that options are met, then decide if a session is allowed to move forward.
With filtering via an <opensmtpd-filter-phase> record, a
session may be interrupted at any phase before an envelope is complete. A
message may also be rejected after being submitted, regardless of whether the
envelope was accepted or not.
The string name of the filter phase.
The string name of the phase. Valid values are:
|-------------+-----------------------------------------------| | "connect" | upon connection, before a banner is displayed | | "helo" | after HELO command is submitted | | "ehlo" | after EHLO command is submitted | | "mail-from" | after MAIL FROM command is submitted | | "rcpt-to" | after RCPT TO command is submitted | | "data" | after DATA command is submitted | | "commit" | after message is fully is submitted | |-------------+-----------------------------------------------|
A list of unique <opensmtpd-option> records.
At each phase, various options, specified by a list of
<opensmtpd-option>, may be checked. The
<opensmtpd-option>~'s fieldname 'option' values of: "fcrdns",
"rdns", and "src" data are available in all phases, but other data must have
been already submitted before they are available. Options with a =<table>=
next to them require the ~<opensmtpd-option>~'s fieldname
~data to be an <opensmtpd-table>. These are the available
options:
|-------------------+----------------------------------------| | fcrdns | forward-confirmed reverse DNS is valid | | rdns | session has a reverse DNS | | rdns
These conditions may all be negated by setting
<opensmtpd-option>~'s fieldname ~not to #t.
Any conditions that require a table may indicate that tables include regexs
setting <opensmtpd-option>~'s fieldname ~regex to #t.
A string decision to be taken. Some decisions require an message or
value. Valid strings are:
|----------------------+------------------------------------------------| | "bypass" | the session or transaction bypasses filters | |----------------------+------------------------------------------------| | "disconnect" message | the session is disconnected with message | |----------------------+------------------------------------------------| | "junk" | the session or transaction is junked, i.e., an | | | ‘X-Spam: yes’ header is added to any messages | |----------------------+------------------------------------------------| | "reject" message | the command is rejected with message | |----------------------+------------------------------------------------| | "rewrite" value | the command parameter is rewritten with value | |----------------------+------------------------------------------------|
Decisions that involve a message require that the message be RFC valid, meaning that they should either start with a 4xx or 5xx status code. Descisions can be taken at any phase, though junking can only happen before a message is committed.
A string message beginning with a 4xx or 5xx status code.
A number value. value and message are mutually exclusive.
This data type represents the configuration of an
<opensmtpd-option>, which is used by
<opensmtpd-filter-phase> and ~~
to match various options for email.
A string option to be taken. Some options require a string or an
<opensmtpd-table> via the fieldname data. When the option
record is used inside of an <opensmtpd-filter-phase>, then
valid strings are:
At each phase, various options may be matched. The fcrdns, rdns, and src data are available in all phases, but other data must have been already submitted before they are available.
|---------------------+----------------------------------------| | "fcrdns" | forward-confirmed reverse DNS is valid | | "rdns" | session has a reverse DNS | | "rdns"
When <opensmtpd-option> is used inside of an
<opensmtpd-match>, then valid strigs for fieldname ~option~
are: "for", "for any", "for local", "for domain", "for rcpt-to", "from any"
"from auth", "from local", "from mail-from", "from rdns", "from socket",
"from src", "auth", "helo", "mail-from", "rcpt-to", "tag", or "tls".
-
Some options require a table to be present. One would specify that table
here.
-
Any options using a table may indicate that tables hold regex by
prefixing the table name with the keyword regex.
When #t, this option record is negated.
This data type represents the configuration of an
<opensmtpd-table>.
name is the name of the <opensmtpd-table> record.
data expects a list of strings or an alist, which is a list of
cons cells. eg: (data (list ("james" . "password"))) OR
(data (list ("gnu.org" "fsf.org"))).
This data type represents the configuration of an
<opensmtpd-pki>.
domain is the string name of the <opensmtpd-pki> record.
cert (default: #f)
cert is the string certificate filename to use for this pki.
key is the string certificate falename to use for this pki.
Specify the DHE string parameter to use for DHE cipher suites with host pkiname. Valid parameter values are "none", "legacy", or "auto". For "legacy", a fixed key length of 1024 bits is used, whereas for "auto", the key length is determined automatically. The default is "none", which disables DHE cipher suites.
Deliver the message to the maildir if pathname if specified, or by default
to ~/Maildir.
The pathname may contain format specifiers that are expanded before use (see FORMAT SPECIFIERS).
If the junk argument is #t, then the message will be moved to the ‘Junk’=
folder if it contains a positive =‘X-Spam’ header. This folder will be
created under pathname if it does not yet exist.
The string name for this MDA command.
Delegate the delivery to a command that receives the message on its standard input.
The command may contain format specifiers that are expanded before use (see FORMAT SPECIFIERS).
Store queue files in a compressed format. This may be useful to save disk space.
Encrypt queue files with EVP_aes_256_gcm(3). If no key is specified, it is read with getpass(3). If the string stdin or a single dash (‘-’) is given instead of a key, the key is read from the standard input.
Set the default expiration time for temporarily undeliverable messages, given as a positive decimal integer followed by a unit s, m, h, or d. The default is four days ("4d").
Data type representing an <opensmtpd-smtp> record.
Set the control string for SSL_CTX_set_cipher_list(3). The default is "HIGH:!aNULL:!MD5".
Limit the number of messages to count for each sessio
Limit the number of recipients to count for each transaction.
Reject messages larger than size, given as a positive number of bytes or as a string to be parsed with scan_scaled(3).
When resolving the local part of a local email address, ignore the ASCII
character and all characters following it. This is helpful for email
filters. "admin+bills@gnu.org" is the same email address as
"admin@gnu.org". BUT an email filter can filter emails addressed to first
email address into a 'Bills' email folder.
Set the secret key to use for SRS, the Sender Rewriting Scheme.
-
Set a backup secret key to use as a fallback for SRS. This can be used to
implement SRS key rotation.
Set the time-to-live delay for SRS envelopes. After this delay, a bounce reply to the SRS address will be discarded to limit risks of forged addresses.
Some configuration records support expansion of their parameters at
runtime. Such records (for example
<opensmtpd-maildir>, <opensmtpd-mda>) may use
format specifiers which are expanded before delivery or relaying. The
following formats are currently supported:
|---------------------+-------------------------------------------------------|
| %{sender} | sender email address, may be empty string |
| %{sender.user} | user part of the sender email address, may be empty |
| %{sender.domain} | domain part of the sender email address, may be empty |
| %{rcpt} | recipient email address |
| %{rcpt.user} | user part of the recipient email address |
| %{rcpt.domain} | domain part of the recipient email address |
| %{dest} | recipient email address after expansion |
| %{dest.user} | user part after expansion |
| %{dest.domain} | domain part after expansion |
| %{user.username} | local user |
| %{user.directory} | home directory of the local user |
| %{mbox.from} | name used in mbox From separator lines |
| %{mda} | mda command, only available for mda wrappers |
|---------------------+-------------------------------------------------------|
Expansion formats also support partial expansion using the optional bracket notations with substring offset. For example, with recipient domain =“example.org”=:
|------------------------+----------------------|
| %{rcpt.domain[0]} | expands to “e” |
| %{rcpt.domain[1]} | expands to “x” |
| %{rcpt.domain[8:]} | expands to “org” |
| %{rcpt.domain[-3:]} | expands to “org” |
| %{rcpt.domain[0:6]} | expands to “example” |
| %{rcpt.domain[0:-4]} | expands to “example” |
|------------------------+----------------------|
In addition, modifiers may be applied to the token. For example, with recipient =“User+Tag@Example.org”=:
|--------------------------+-----------------------------------|
| %{rcpt:lowercase} | expands to “user+tag@example.org” |
| %{rcpt:uppercase} | expands to “USER+TAG@EXAMPLE.ORG” |
| %{rcpt:strip} | expands to “User@Example.org” |
| %{rcpt:lowercasestrip} | expands to “user@example.org” |
|--------------------------+-----------------------------------|
For security concerns, expanded values are sanitized and potentially dangerous characters are replaced with ‘:’. In situations where they are desirable, the “raw” modifier may be applied. For example, with recipient =“user+t?g@example.org”=:
COMMENT some example <opensmtpd-configurations> that are probably out of date
|---------------+-----------------------------------|
| %{rcpt} | expands to “user+t:g@example.org” |
| %{rcpt:raw} | expands to “user+t?g@example.org” |
|---------------+-----------------------------------|
#+BEGIN_SRC scheme
;;this works! (opensmtpd-configuration->mixed-text-file (opensmtpd-configuration (smtp (opensmtpd-smtp (limit-max-rcpt 10)))))
;; (tables (list ;; (opensmtpd-table ;; (name "aliases") ;; (data ;; (list ;; (cons "webmaster" "root") ;; (cons "postmaster" "root") ;; (cons "abuse" "root")))) ;; ;; (opensmtpd-table ;; (name "vdoms") ;; (data (list "gnucode.me" ;; "gnu-hurd.com"))) ;; (opensmtpd-table ;; (name (opensmtpd-table ;; (name "virtual") ;; (data (list "root" "postmaster@gnu.org")))) ;; (data (list (cons "joshua@gnucode.me" "joshua") ;; (cons "jbranso@gnucode.me" "joshua") ;; (cons "postmaster@gnucode.me" "joshua"))))))
;; (filter-chains ;; (list ;; (opensmtpd-filter-chain ;; (name "dropDumbEmails") ;; (filter-names (list "nofcrdnsDisconnect" ;; "nordnsDisconnect"))))) ;; (filter-phases ;; (list (opensmtpd-filter-phase ;; (name "nofcrdnsDisconnect") ;; (phase-name "connect") ;; (options (list "!fcrdns")) ;; (decision "disconnect") ;; (message "You have not set up forward confirmed DNS.")) ;; (opensmtpd-filter-phase ;; (name "nordnsDisconnect") ;; (phase-name "connect") ;; (options (list "!rdns")) ;; ;; (decision "reject") ;; (message "You have not set up reverse DNS.")))) ;; (define example-opensmtpd-config-smaller (opensmtpd-configuration (interface (list ;; this forum help suggests that I listen on 0.0.0.0 and NOT eth0 ;; https://serverfault.com/questions/726795/opensmtpd-wont-work-at-reboot ;; this listens for email from the outside world ;; this lets local users logged into the system via ssh send email (opensmtpd-interface (interface "wlp2s0") (port 465)))) (matches (list (opensmtpd-match (name "maildir") (action (opensmtpd-local-delivery (method (opensmtpd-maildir (pathname "/home/%{rcpt.user}/Maildir") (junk #t))) (virtual (opensmtpd-table (name "virtual") (data (list "root" "james@gnu.org")))))) (for (opensmtpd-option (option "for local"))))))))
(define example-opensmtpd-config-small (let ([interface "wlp2s0"] [creds (opensmtpd-table (name "creds") (data (list (cons "joshua" "$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86."))))] [receive-action (opensmtpd-local-delivery (name "receive") (method (opensmtpd-maildir (pathname "/home/%{rcpt.user}/Maildir") (junk #t))) (virtual (opensmtpd-table (name "virtual") (data (list "root" "james@gnu.org")))))] [smtp.gnucode.me (opensmtpd-pki (domain "smtp.gnucode.me") (cert "opensmtpd.scm") (key "opensmtpd.scm"))]) (opensmtpd-configuration (interface (list ;; this forum help suggests that I listen on 0.0.0.0 and NOT eth0 ;; https://serverfault.com/questions/726795/opensmtpd-wont-work-at-reboot ;; this listens for email from the outside world (opensmtpd-interface (interface interface) (port 25) (secure-connection "tls") (pki smtp.gnucode.me)) ;; this lets local users logged into the system via ssh send email (opensmtpd-interface (interface interface) (port 465) (secure-connection "smtps") (pki smtp.gnucode.me) (auth creds)))) (matches (list (opensmtpd-match (action receive-action) (for (opensmtpd-option (option "for local")))))))))
(define example-opensmtpd-config (let ([interface "lo"] [creds (opensmtpd-table (name "creds") (data (list (cons "joshua" "$6$Ec4m8FgKjT2F/03Y$k66ABdse9TzCX6qaALB3WBL9GC1rmAWJmaoSjFMpbhzat7DOpFqpnOwpbZ34wwsQYIK8RQlqwM1I/v6vsRq86."))))] [receive-action (opensmtpd-local-delivery (name "receive") (method (opensmtpd-maildir (pathname "/home/%{rcpt.user}/Maildir") (junk #t))) (virtual (opensmtpd-table (name "virtual") (data (list "josh" "jbranso@dismail.de")))))] [smtp.gnucode.me (opensmtpd-pki (domain "smtp.gnucode.me") (cert "opensmtpd.scm") (key "opensmtpd.scm"))]) (opensmtpd-configuration ;; (mta-max-deferred 50) ;; (queue ;; (opensmtpd-queue ;; (compression #t))) ;; (smtp ;; (opensmtpd-smtp ;; (max-message-size "10M"))) ;; (srs ;; (opensmtpd-srs ;; (ttl-delay "5d"))) (interface (list ;; this forum help suggests that I listen on 0.0.0.0 and NOT eth0 ;; https://serverfault.com/questions/726795/opensmtpd-wont-work-at-reboot ;; this listens for email from the outside world (opensmtpd-interface (interface interface) (port 25) (secure-connection "tls") (pki smtp.gnucode.me)) ;; this lets local users logged into the system via ssh send email (opensmtpd-interface (interface "lo") (port 25) (secure-connection "tls") (pki smtp.gnucode.me)) (opensmtpd-interface (interface interface) (port 465) (secure-connection "smtps") (pki smtp.gnucode.me) (auth creds) ;;(filter ) ) (opensmtpd-interface (interface interface) (port 587) (secure-connection "tls-require") (pki smtp.gnucode.me) (auth creds)))) (matches (list (opensmtpd-match (action (opensmtpd-relay (name "send"))) (for (opensmtpd-option (option "for any"))) (from (opensmtpd-option (option "from any"))) (auth (opensmtpd-option (option "auth")))) (opensmtpd-match (action receive-action) (from (opensmtpd-option (option "from any"))) (for (opensmtpd-option (option "for domain") (value (list "gnucode.me" "gnu-hurd.com"))))) (opensmtpd-match (action receive-action) (for (opensmtpd-option (option "for local"))))))))) #+END_SRC
COMMENT some example smtpd.conf configs
COMMENT serving multiple domains with one pki
source: https://www.reddit.com/r/openbsd/comments/n41wkz/how_to_host_different_domains_for_an_email_server/
pki mail.primary.domain certpki mail.primary.domain cert "/etc/ssl/mail.primary.domain.fullchain.pem"
pki mail.primary.domain key "/etc/ssl/private/mail.primary.domain.key"
filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*', '.*\.dsl\..*' } \
disconnect "550 no residential connections"
filter check_rdns phase connect match !rdns \
disconnect "550 no rDNS is so 80s"
filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"
filter senderscore \
proc-exec "filter-senderscore -blockBelow 10 -junkBelow 70 -slowFactor 5000"
filter rspamd proc-exec "filter-rspamd"
table usermap file:/etc/mail/usermap
table credentials file:/etc/mail/credentials
table domains { primary.domain, second.domain }
listen on all tls pki mail.primary.domain \
filter { check_dyndns, check_rdns, check_fcrdns, senderscore, rspamd }
listen on egress port 465 smtps pki mail.primary.domain \
auth ~<credentials>~ filter rspamd
action "inbound" lmtp "/var/dovecot/lmtp" rcpt-to virtual ~<usermap>~ #maildir junk alias <aliases>
action "outbound" relay helo mail.primary.domain
match from any for domain ~<domains>~ action "inbound"
match for local action "inbound"
match from any auth for any action "outbound"
match for any action "outbound" "/etc/ssl/mail.primary.domain.fullchain.pem"
pki mail.primary.domain key "/etc/ssl/private/mail.primary.domain.key"
filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*', '.*\.dsl\..*' } \
disconnect "550 no residential connections"
filter check_rdns phase connect match !rdns \
disconnect "550 no rDNS is so 80s"
filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"
filter senderscore \
proc-exec "filter-senderscore -blockBelow 10 -junkBelow 70 -slowFactor 5000"
filter rspamd proc-exec "filter-rspamd"
table usermap file:/etc/mail/usermap
table credentials file:/etc/mail/credentials
table domains { primary.domain, second.domain }
listen on all tls pki mail.primary.domain \
filter { check_dyndns, check_rdns, check_fcrdns, senderscore, rspamd }
listen on egress port 465 smtps pki mail.primary.domain \
auth ~<credentials>~ filter rspamd
action "inbound" lmtp "/var/dovecot/lmtp" rcpt-to virtual ~<usermap>~ #maildir junk alias <aliases>
action "outbound" relay helo mail.primary.domain
match from any for domain ~<domains>~ action "inbound"
match for local action "inbound"
match from any auth for any action "outbound"
match for any action "outbound"
PROJ nice things to have [0/9]
TODO Should I delete <opensmtpd-mda> ? or fieldname 'opensmtpd-configuration-mda-wrapppers'?
~~'s fieldname 'method' allows for an mda configuration. BUT instead of an mda-configuration record, you could just use a list of strings and/or gexps.
mda wrapper name command
Associate command with the mail delivery agent wrapper named name. When a local
delivery specifies a wrapper, the command associated with the wrapper will be ex‐
ecuted instead. The command may contain format specifiers (see FORMAT
SPECIFIERS).
If I choose to NOT delete <opensmtpd-mda>, then should I delete
'opensmtpd-configuration-mda-wrapppers'?
Also should I delete the opensmtpd-local-delivery-wrapper?
TODO make the 'auth-optional' and 'auth' fieldnames for <opensmtpd-interface> autoencrypt passwords. [0/0]
Guix makes it pretty hard to find the openbsd binary file that encrypts passwords for you. If I can progmatically find this file, it would be nice to autoencrypt the users's passwords for you.
What does this mean practically? Suppose that a user sets up their config this way: In file passwords.scm (which is NOT in the git repo).
(define-module (passwords)
#:use-module (gnu services mail))
(define creds-table
(opensmtpd-table
(name "credentials")
(data '(("joshua@gnu.org" . "somePassword")
("postmaster@gnu.org") . "anotherSillyPassword"))))
Then in their config.scm
(use-modules (passwords))
(opensmtpd-interface
(interface interface)
(port 465)
(secure-connection "smtps")
(pki smtp.gnucode.me)
(auth creds-table)
(filters (list filter-dkimsign)))
Guix will then generate a smtpd.conf file =/gnu/store/saenthuseantaeueuaua/smtpd.conf= as something like:
table credentials { joshua@gnu.org = $some$Long$EncrytpedPassword, \
postmaster@gnu.org = $some$Long$Other$EncrytpedPassword }
You would need to encourage users NOT to have passwords in a public git repo. With guile-git, it might be possible to sanitize the config, to ensure that the passwords are NOT stored in the git repo.
Currently, users of opensmtpd, must generate user passwords manually, via the following:
guix install opensmtpd
$(find /gnu/store -name '*encrypt*' | grep -m 1 opensmtpd) "password"
$6$3prHAJvjxNhDGz7G$74ENoGsV4AnxXiNvPnhS0d9.0Cj5ywgxBCwndgxfvSRHAUWeuOSpkmsTyHEFk4O4z.9dVkx3bMUiaX18HvTbA.
:TheActualFilePathOfTheEncryptBinary:
ls -lha $(find /gnu/store -name '*encrypt*' | grep -m 1 opensmtpd)
lrwxrwxrwx 1 root root 87 Dec 31 1969 /gnu/store/i1bh9a0q9wshpmhl4dnkdkqygfq532dw-profile/libexec/opensmtpd/encrypt -> /gnu/store/qf84lf6nddsf1saan0qiv60qwz8hsic9-opensmtpd-6.8.0p2/libexec/opensmtpd/encrypt
:END:
I am trying to take a stab at auto-generating these user passwords, and as it turns out... I really do NOT understand gexps.
In a guile repl, I am not getting, well anything to work.
,use (gnu packages mail)
,use (guix gexps)
,use (guix monad-repl)
,m (gnu services mail)
#~(string-append #$(file-append opensmtpd "/sbin/smtpctl"))
$23 = #<gexp (string-append #<gexp-input #<file-append #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580> "/sbin/smtpctl">:out>) 7050f4a17750>
scheme@(gnu services mail) [11]> ,build $23
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (string-append #<gexp-input #<file-append #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580> "/sbin/smtpctl">:out>) 7050f4a17750>
scheme@(gnu services mail) [11]> #~(begin (string-append #$opensmtpd "/sbin/smtpctl"))
$24 = #<gexp (begin (string-append #<gexp-input #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580>:out> "/sbin/smtpctl")) 7050f4532d50>
scheme@(gnu services mail) [11]> ,build $24
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (begin (string-append #<gexp-input #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580>:out> "/sbin/smtpctl")) 7050f4532d50>
scheme@(gnu services mail) [11]>
$25 = #<gexp (begin (system* (string-append opensmtpd "/sbin/smtpctl") " password\n")) 7050f4a6cd20>
scheme@(gnu services mail) [11]> ,build $25
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (begin (system* (string-append opensmtpd "/sbin/smtpctl") " password\n")) 7050f4a6cd20>
scheme@(gnu services mail) [11]> (system* "ls")
ABOUT-NLS build-aux config.status etc guix INSTALL Makefile po scripts
aclocal.m4 ChangeLog configure gnu guix-daemon libformat.a Makefile.am pre-inst-env test-env
AUTHORS CODE-OF-CONDUCT configure.ac gnu.go guix.go libstore.a Makefile.in README tests
autom4te.cache config-daemon.ac COPYING gnu.scm guix.scm libutil.a NEWS ROADMAP THANKS
bootstrap config.log doc guile HACKING m4 nix run-opensmtpd-record-sanitation-test.log TODO
$26 = 0
scheme@(gnu services mail) [11]> #~(begin (system* (string-append opensmtpd #$ "/sbin/smtpctl") " password\n"))
$27 = #<gexp (begin (system* (string-append opensmtpd #<gexp-input "/sbin/smtpctl":out>) " password\n")) 7050f4364480>
scheme@(gnu services mail) [11]> ,build $27
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (begin (system* (string-append opensmtpd #<gexp-input "/sbin/smtpctl":out>) " password\n")) 7050f4364480>
scheme@(gnu services mail) [11]> #~(begin $#opensmtpd)
$28 = #<gexp (begin #{$#opensmtpd}#) 705106769e70>
scheme@(gnu services mail) [11]> ,build $28
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (begin #{$#opensmtpd}#) 705106769e70>
scheme@(gnu services mail) [11]> #~(begin (mkdir #$output)
(chdir #$output)
#$opensmtpd)
$29 = #<gexp (begin (mkdir #<gexp-output out>) (chdir #<gexp-output out>) #<gexp-input #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580>:out>) 7050f5cd3f60>
scheme@(gnu services mail) [11]> ,build $29
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (begin (mkdir #<gexp-output out>) (chdir #<gexp-output out>) #<gexp-input #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580>:out>) 7050f5cd3f60>
scheme@(gnu services mail) [11]> ,bt
1 (string-append #<file-append #<package opensmtpd@6.8.0p2 gnu/packages/mail.scm:3114 7050f7f5f580> "/sbin/smtpctl"> "/sbin/smtpctl")
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
scheme@(gnu services mail) [11]> #~(begin (mkdir $#output)
(mkdir (string-append #$output) "/libexec")
(string-append opensmtpd "/opensmtpd"))
$30 = #<gexp (begin (mkdir #{$#output}#) (mkdir (string-append #<gexp-output out>) "/libexec") (string-append opensmtpd "/opensmtpd")) 7050f5b271b0>
scheme@(gnu services mail) [11]> ,build $30
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp (begin (mkdir #{$#output}#) (mkdir (string-append #<gexp-output out>) "/libexec") (string-append opensmtpd "/opensmtpd")) 7050f5b271b0>
scheme@(gnu services mail) [11]>
PROJ Why does (opensmtpd-configuration) take so long to initialize? [0/1]
TODO one area to look for speed up improvements would be in the sanitize function of (opensmtpd-interface-filters).
PROJ check the code base for places to use apply, map, fold, eval, or remove [3/4]
For example, try to initialize my Example configuration. It takes almost 5 seconds.
DONE string-in-list would be a good place. maybe is-value-right-type
(define (string-in-list? string list)
(if (null? list)
#f
(if (and (string? (car list)) (string=? string (car list)))
#t
(string-in-list? string (cdr list)))))
(define (string-in-list? string list)
(primitive-eval (cons 'or (map (lambda (var) (string=? string var)) list))))
DONE contains-duplicate
(define (contains-duplicate? list)
(if (null? list)
#f
(or
;;<check whether (first list) is in (rest list)>
(let loop ([list (cdr list)]
[1st (car list)])
(if (null? list)
#f
(if (equal? 1st (car list))
(data #t 1st)
(loop (cdr list) 1st))))
;;<check where (rest list) contains a duplicate>
(contains-duplicate? (cdr list)))))
(define (contains-duplicate? list)
(if (null? list)
#f
(or (primitive-eval (cons 'or ; check if (car list) is in (cdr list)
(map (lambda (var) (equal? var (car list)))
(cdr list))))
;; check if (cdr list) contains duplicate
(contains-duplicate? (cdr list)))))
DONE using remove and flatten and map
(define (get-opensmtpd-tables value)
(delete-duplicates
(let loop ([list (flatten
(cond ((opensmtpd-table? value)
value)
((record? value)
(let* ([<record-type> (record-type-descriptor value)]
[list-of-record-fieldnames (record-type-fields <record-type>)])
(map (lambda (fieldname)
(get-opensmtpd-tables ((record-accessor <record-type> fieldname) value)))
list-of-record-fieldnames)))
((and (list? value) (not (null? list)))
(map (lambda (element-in-list)
(if (record? element-in-list)
(get-opensmtpd-tables element-in-list)
#f))
value))))])
(if (null? list)
'()
(if (opensmtpd-table? (car list))
(cons (car list) (loop (cdr list)))
(loop (cdr list)))))))
(define (get-opensmtpd-tables value)
(let loop ([list (flatten ;; turn (list '(1) '(2 '(3))) -> '(1 2 3)
(cond ((opensmtpd-table? value)
value)
((record? value)
(let* ([<record-type> (record-type-descriptor value)]
[list-of-record-fieldnames (record-type-fields <record-type>)])
(map (lambda (fieldname)
(get-opensmtpd-tables ((record-accessor <record-type> fieldname) value)))
list-of-record-fieldnames)))
((and (list? value) (not (null? list)))
(map (lambda (element-in-list)
(if (record? element-in-list)
(get-opensmtpd-tables element-in-list)
#f))
value))))])
(delete-duplicates (partition opensmtpd-table? list))))
TODO using map, apply, and fold is certainly awesome, but is it less efficient?
For example, list-of-type? using a named let is pretty efficient. It loops through the list once.
(define (list-of-type? list proc?)
(if (and (list? list)
(not (null? list)))
(let loop ([list list])
(if (null? list)
#t
(if (proc? (car list))
(loop (cdr list))
#f)))
#f))
BUT when I using map on this, it is slightly less efficient. It has to apply a simple procedure to each element in the list. Then it has to return the list of booleans. Then it has to build the primitive eval list, then it has to eval it.
(define (list-of-type? list proc?)
(if (and (list? list)
(not (null? list)))
(primitive-eval (cons 'and
(map (lambda (var)
(if (proc? var)
#t
#f))
list)))
#f))
PROJ improve [0/2]
TODO it would be nice if <opensmtpd-table> supported aliasing tables, as described in man 5 table
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many destinations. They can be
used in two contexts: primary domain aliases and virtual domain mapping.
action name method alias <table>
action name method virtual <table>
In a primary domain context, the key is the user part of the recipient address, whilst the value
is one or many recipients as described in aliases(5):
user1 otheruser
user2 otheruser1,otheruser2
user3 otheruser@example.com
In a virtual domain context, the key is either a user part, a full email address or a catch all,
following selection rules described in smtpd.conf(5), and the value is one or many recipients as
described in aliases(5):
user1 otheruser
user2@example.org otheruser1,otheruser2
@example.org otheruser@example.com
@ catchall@example.com
TODO make an with db #t, auto convert the table into a berkley database via makemap
<opensmtpd-table> supported aliasing tables, as described in man 5 table
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many destinations. They can be
used in two contexts: primary domain aliases and virtual domain mapping.
action name method alias <table>
action name method virtual <table>
In a primary domain context, the key is the user part of the recipient address, whilst the value
is one or many recipients as described in aliases(5):
user1 otheruser
user2 otheruser1,otheruser2
user3 otheruser@example.com
In a virtual domain context, the key is either a user part, a full email address or a catch all,
following selection rules described in smtpd.conf(5), and the value is one or many recipients as
described in aliases(5):
user1 otheruser
user2@example.org otheruser1,otheruser2
@example.org otheruser@example.com
@ catchall@example.com
Currently opensmtpd-table, does not support mapping a user to 5 email addresses. For example, if user 'dave' can email as 'postmaster@gnu.org', and 'other@gnu.org', and 5 other email addresses... does not support this kind of mapping. To support it, I may be able to just embed a table in smtpd.conf, or I may need to create an /etc/aliases table as man 5 aliases describes.
TODO writing out the pkis when there are no pkis gives the string "\n"...it might be better to give "" instead
See man 5 table and man smtpd.conf
PROJ Can I make some improvements to my/sanitize procedure? [0/4]
how does my/sanitize procedure work?
(opensmtpd-configuration-fieldname->string example-opensmtpd-with-0-pkis opensmtpd-configuration-pkis opensmtpd-pki->string)
(my/sanitize var "record-name" "fieldname" '(string? boolean? number?)')
It is essentially asking? are you any of the following: string?, boolean?, number? If not, then error out with a helpful error message.
How does my hard-coded sanitized procedure work? eg ![opensmtpd-interface-filters]( "opensmtpd-interface-filters")
This hard coded sanitize is a little different than the my/sanitize procedure. I
designed the thunk my/sanitize, such that each thunk (string?, false?,
boolean?) has a corresponding entry in the procedure .
However, it would be nice to have the sanitize invocation in opensmtpd-interface-filters use a my/sanitize invocation like so.
(my/sanitize var "opensmtpd-interface" "filters"
(list false?
'(list-has-duplicates-or-non-filters
"is a list in which each unique element is of type <opensmtpd-filter>\n"
"or <opensmtpd-filter-phase>.")
'(some-filters-in-list-need-message?
"<opensmtpd-filter-phase> fieldname: 'decision' options "
"\"disconnect\" and \"reject\" require fieldname 'message'\n"
"to have a string.\n")
'(some-filters-in-list-need-value?
"<opensmtpd-filter-phase> fieldname: 'decision' option "
"\"rewrite\" requires fieldname 'value'\n"
"to have a string.\n")))
PROJ better error messages for my/sanitize calls that use a lambda instead of a defined function [0/4]
THIS IS HARD TO DO... NOT DOING IT! I just chose to use a hard-coded error message baked into the lambda. I tried making my/sanitize better...but I could not get it to work. The hard-coded method just works:
(phase-name opensmtpd-filter-phase-phase-name ;; string
(default #f)
(sanitize (lambda (var)
(if (and (string? var)
(or (string=? "connect" var)
(string=? "helo" var)
(string=? "mail-from" var)
(string=? "rcpt-to" var)
(string=? "data" var)
(string=? "commit" var)))
var
(begin
(display (string-append "<opensmtpd-filter-phase> fieldname: 'phase-name' is of type "
"string. The string can be either 'connect',"
" 'helo', 'mail-from', 'rcpt-to', 'data', or 'commit.'\n "))
(throw 'bad! var))))))
Why? <opensmtpd-filter-phase> fieldnames only accept certain strings. I want to
sanitize each fieldname to make sure that it's strings is one of those strings.
How would I do this?
For example, <opensmtpd-filter-phase> fieldname 'decision' uses
a lambda to sanitize itself. This will result in an error message that is
descriptive enough to solve the problem. If I decide to do this, then I probably
should create a non-exported record.
(opensmtpd-filter-phase (name "cat") (phase-name "connect") (options "fcrdns") (decision "bypasse"))
(opensmtpd-filter-phase (name "cat") (phase-name "connect") (options "fcrdns") (decision "bypasse")) fieldname 'bypasse' is of type. #:972:0 (var)> ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `bad!' with args `(#:972:0 (var)>)'.
A solution may be to modify the my/sanitize procedure to accept something like
(my/sanitize var "<record>" "'fieldname'" (list ((lambda (var) ...) . "list of unique numbers or strings")))
I have some example code It probably won't work, but it is a rough sketch
of what could work.
[(eq? (cons? (car procedures)))
(cdr (car procedures))]
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
TODO Now make all the other sanitize sections that use a lambda use this new functionality:
eg:
(family opensmtpd-interface-family
(default #f)
(sanitize (lambda (var)
(cond
[(eq? #f var) ;; var == #f
var]
[(and (string? var)
(or (string=? "inet4" var)
(string=? "inet6" var)))
var]
[else
(begin
(display "<opensmtpd-interface> fieldname 'family' must be string \"inet4\" or \"inet6\".\n")
(throw 'bad! var))]))))
TODO perhaps I can create an unexported record [0/2]
TODO Perhaps I could try to make my/sanitize work more like the opensmtpd-interface-filters does.
fieldnames: 'procedure', 'error message'.
It looks like tiny errors first. And shows you those relevent errors. When you fix those tiny errors it starts looking for harder errors.
This is nice because when you get something wrong in the config, you get the specific error message.
TODO the has lost of hard coded error checking.
TODO rework my/sanitize to be like opensmtpd-interface-filters
The way my/sanitize currently works, if you get one thing wrong, then you get 4 reasons for what you might have done wrong. It would be nice to hook this up to my/sanitize. Along with other bits of the code.
opensmtpd-interface-filters works like so:
Is the variable (not (false? var))
Is the variable (need-some-messages?)
Does the variable (need-some-value) ?
else var.
For example, this
(define-record-type* <opensmtpd-table>
opensmtpd-table make-opensmtpd-table
opensmtpd-table?
this-record
(name opensmtpd-table-name ;; string
(default #f)
(sanitize (lambda (var)
(my/sanitize var "opensmtpd-table" "name" (list string?)))))
(db opensmtpd-table-db
(default #f)
(sanitize (lambda (var)
(my/sanitize var "opensmtpd-table" "db"
(list boolean?)))))
would become:
(define-record-type* <opensmtpd-table>
opensmtpd-table make-opensmtpd-table
opensmtpd-table?
this-record
(name opensmtpd-table-name ;; string
(default #f)
(sanitize (lambda (var)
(my/sanitize var "opensmtpd-table" "name" (list not-string?)))))
(db opensmtpd-table-db
(default #f)
(sanitize (lambda (var)
(my/sanitize var "opensmtpd-table" "db"
(list not-boolean?)))))
This
(secure-connection opensmtpd-interface-secure-connection
(default #f)
(sanitize (lambda (var)
(cond [(boolean? var)
var]
[(and (string? var)
(string-in-list? var
(list "smtps" "tls"
"tls-require"
"tls-require-verify")))
var]
[else
(begin
(display (string-append "<opensmtd-listen-on> fieldname 'secure-connection' can be "
"one of the following strings: \n'smtps', 'tls', 'tls-require', "
"or 'tls-require-verify'.\n"))
(throw 'bad! var))]))))
would become (finish this thought exercise.)
(secure-connection opensmtpd-interface-secure-connection
(default #f)
(sanitize (lambda (var)
(list not-boolean
(sanitize-proc-configuration
string-in-list?
(list "smtps" "tls"
"tls-require"
"tls-require-verify"))
[else
(begin
(display (string-append "<opensmtd-listen-on> fieldname 'secure-connection' can be "
"one of the following strings: \n'smtps', 'tls', 'tls-require', "
"or 'tls-require-verify'.\n"))
(throw 'bad! var))]))))
PROJ can we merge my/sanitize syntax into (guix records)?
(define-record-type* <opensmtpd-option>
opensmtpd-option make-opensmtpd-option
opensmtpd-option?
(documentation (list "<opensmtpd-match> uses <opensmtpd-option> to\n"
"tweak various options."))
(sanitize (sanitize-configuration ; this sanitizes the whole <opensmtpd-option> record.
(list (lambda (value)
...
))))
(option opensmtpd-option-option
(default #f)
(sanitize (sanitize-configuration
(list string?))))
(bool opensmtpd-option-bool
(default #f)
(sanitize (sanitize-configuration
(list boolean?)) ))
(regex opensmtpd-option-regex
(default #f)
(sanitize (sanitize-configuration '(boolean?))))
(value opensmtpd-option-value
(default #f)
(sanitize (sanitize-configuration
;; note that it is smart enough to realize that opensmtpd-table? is a record,
;; so the error message it returns is something like "<opensmtpd-match> fieldname is of
;; type <opensmtpd-table>."
(list false? string? opensmtpd-table?)))))
TODO some of the error messages say "bad var #f". This is not very helpful.
PROJ add support for <listen-on>= fieldname 'senders': syntax "senders =<users> [masquerade]" [0/4]
TODO add a record type
-
Where it is useful I should do a ~(throw 'bad! record)~ instead of
~(throw `bad! #f)~
:LOGBOOK:
TODO change the sanitize portion of the fieldname 'senders' in the
fieldnames: 'table (accepts '), and 'masquerade' (accepts boolean).
The below code does work in a REPL.
(add-to-load-path (dirname (current-filename)))
(use-modules (opensmtpd-records))
(opensmtpd-interface
(auth
(opensmtpd-table
(name "My-table")
(data '(("joshua" . "$some$Long$EncrytpedPassword"))))))
AND the below code will correctly result in an error!
(add-to-load-path (dirname (current-filename)))
(use-modules (opensmtpd-records))
(opensmtpd-interface
(auth
(opensmtpd-table
(name "My-table")
(data '("joshua" "$some$Long$EncrytpedPassword")))))
~= fieldname: 'auth' is of type boolean, or an =~ record whose fieldname 'values' are an assoc-list
(eg: (opensmtpd-table (name "table") (data '("joshua" . "$encrypted$password")))).
TODO change relevant portions in opensmtpd-interface->string
This bit of code works in the repl too!
(add-to-load-path (dirname (current-filename)))
(use-modules (opensmtpd-records))
((@@ (opensmtpd-records) opensmtpd-interface->string)
(opensmtpd-interface
(auth
(opensmtpd-table
(name "credentials")
(data '(("joshua" . "$someLongEncrytpedPassword")))))))
TODO support the masquerade option
TODO write out of examples of <opensmtpd-configuration> records that will fail to start or do not make sense.
Right now, senders just accepts an , but I am not allowing the user to turn on or off the masquerade option. Provide appropriate error messages.
There is a trend of guix services that "work" but are not dummy proof. For example, the XMPP service wants a cert in the format of "
Shepherd will not tell where the XMPP configuration file can be found. You have
to manually go searching for the config file. Then you have to manually check
the configuration syntax of the file, though the command to start the service
may have a flag to check the syntax. Anyway it's annoying. Guix services should
be able to get a <service-configuration> record and just by looking at the
record tell, if you have done something silly that will make the service refuse
to start or behave in a weird way, and provide you appropriate error messages so
you don't have to go syntax hunting.
Examples:
Some notes on working on the service workflows and such
disabling centaur-tabs-mode seems to help. and NOT working in the console helps too.
I think that having the geiser repl running via
M-x geiser M-x geiser-load-file RET opensmtpd-records.scm ,m (opensmtpd-records)
May be causing Emacs to move slowly after a while.
It may be better to instead do:
cd prog/gnu/guix-config/linode-system-configuration; guile -L . --listen=9999
And then in Emacs (as described here: https://www.nongnu.org/geiser/geiser_3.html) connect to the external repl via M-x geiser-connect