|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Sendmail is one of the oldest and the mostly widely used MTAs in the world. It is the default MTA for most UNIX distributions, including HP's HP-UX, IBM's AIX, and Sun Microsystems' Solaris OS. It is also default of Red Hat. Suse uses Postfix.
Sendmail's has a lot of problems early in its life. It is also complicated to configure and maintain, but it is a pretty powerful, albeit obscure mail router. Since 2011 there were no new versions of sendmail, so in a way it is very close to abandonware.
|
|
First appearing over 30 years ago, Sendmail has evolved into a robust, feature-rich method for transporting electronic mail from one location to another. Originally designed at a time when hard drives were tini and disk space was premium, Sendmail used every trick in the book to conserve space.
Sendmail configuration file is pretty obscure and used such cryptic parameters as "Fw" for "Domains we receive mail for" and "DH" for "Who gets all local email."
Over the years, as features were added to Sendmail, the configuration process became more and more complicated. To make it more administrator-friendly, Sendmail start using a m4-based compilation and configuration model. This layer between the administrator and the build and configuration process makes Sendmail easier to set up but creates the problem of two sources inherent in macrogenerators.
Sendmail is a mail router: it routs mail between the various mail programs found on UNIX systems. In addition to routing mail between user programs sendmail also provides several other functions:
Receives and delivers SMTP (internet) mail
Provides mail aliases, which allow mailing lists. Mail aliases defined in
aliases file (alias: recipient[,
recipient,...]) provide for:
Alternate names (nicknames) for individual users
Forwarding of mail to other hosts
Mailing lists
sendmail usually run as a daemon and starts and exists from system startup scripts (RC-scripts). The sendmail daemon listens to TCP port 25. In most cases this RC script is installed during system installation.
For example Solaris uses /etc/init.d/sendmail script for starting sendmail.
The mail queue directory holds mail that has not yet been delivered. It is possible that the system went down while the mail queue was being processed.
alias is the name to which the mail is addressed, and
recipient is the name to which the mail is delivered.
recipient can be a username, the name of another alias, or a full
email address containing both a username and a hostname. Including a hostname allows
mail to be forwarded to a remote host. Additionally, there can be multiple recipients
for a single alias. Mail addressed to that alias is delivered to all of the recipients,
thus creating a mailing list.
Aliases that define nicknames for individual users can be used to handle frequently misspelled names. You can also use aliases to deliver mail addressed to special names, such as postmaster or root, to the real users that do those jobs. Aliases can also be used to implement simplified mail addressing, especially when used in conjunction with MX records. This aliases file from almond shows all of these uses:
# special names
postmaster: clark
root: norman
# accept [email protected]
rebecca.hunt: becky@peanut
jessie.mccafferty: jessie@walnut
anthony.resnick: anthony@pecan
andy.wright: andy@filbert
# a mailing list
admin: kathy, david@peanut, sara@pecan, becky@peanut, craig,
anna@peanut, jane@peanut, christy@filbert
owner-admin: admin-request
admin-request: craig
The first two aliases are special names. Using these aliases, mail addressed to postmaster is delivered to the local user clark, and mail addressed to root is delivered to norman.
The second set of aliases is in the form of firstname and lastname. The first alias in this group is rebecca.hunt. Mail addressed to rebecca.hunt is forwarded from almond and delivered to becky@peanut. Combine this alias with an MX record that names almond as the mail server for nuts.com, and mail addressed to [email protected] is delivered to [email protected]. This type of addressing scheme allows each user to advertise a consistent mailing address that does not change just because the user's account moves to another host. Additionally, if a remote user knows that this firstname.lastname addressing scheme is used at nuts.com, he can address mail to Rebecca Hunt as [email protected] without knowing her real email address.
The last two aliases are for a mailing list. The alias admin defines the list itself. If mail is sent to admin, a copy of the mail is sent to each of the recipients (kathy, david, sara, becky, craig, anna, jane, and christy). Note that the mailing list continues across multiple lines. A line that starts with a blank or a tab is a continuation line.
The owner-admin alias is a special form used by sendmail. The format of this special alias is owner-listname where listname is the name of a mailing list. The person specified on this alias line is responsible for the list identified by listname. If sendmail has problems delivering mail to any of the recipients in the admin list, an error message is sent to owner-admin. The owner-admin alias points to admin-request as the person responsible for maintaining the mailing list admin. Aliases in the form of listname-request are commonly used for administrative requests, such as subscribing to a list, for manually maintained mailing lists. Notice that we point an alias to another alias, which is perfectly legal. The admin-request alias resolves to craig.
sendmail does not use the aliases file directly. The aliases file must first be processed by the newaliases command. newaliases is equivalent to sendmail with the -bi option, which causes sendmail to build the aliases database. newaliases creates the database files that are used by sendmail when it is searching for aliases. Invoke newaliases after updating the aliases file to make sure that sendmail is able to use the new aliases.
[4] If the D option is used (see Appendix E, A sendmail Reference), sendmail automatically rebuilds the aliases database - even if newaliases is not run.
In addition to the mail forwarding provided by aliases, sendmail allows individual users to define their own forwarding. The user defines her personal forwarding in the .forward file in her home directory. sendmail checks for this file after using the aliases file and before making final delivery to the user. If the .forward file exists, sendmail delivers the mail as directed by that file. For example, say that user kathy has a .forward file in her home directory that contains [email protected]. The mail that sendmail would normally deliver to the local user kathy is forwarded to kathy's account at podunk.edu.
Use the .forward file for temporary forwarding. Modifying aliases and rebuilding the database takes more effort than modifying a .forward file, particularly if the forwarding change will be short-lived. Additionally, the .forward file puts the user in charge of his own mail forwarding.
Mail aliases and mail forwarding are handled by the aliases file and the .forward file. Everything else about the sendmail configuration is handled in the sendmail.cf file.
The sendmail configuration file is sendmail.cf. It contains most of the sendmail configuration, including the information required to route mail between the user mail programs and the mail delivery programs. The sendmail.cf file has three main functions:
It defines the sendmail environment.
It rewrites addresses into the appropriate syntax for the receiving mailer.
It maps addresses into the instructions necessary to deliver the mail.
Several commands are necessary to perform all of these functions. Macro definitions and option commands define the environment. Rewrite rules rewrite email addresses. Mailer definitions define the instructions necessary to deliver the mail. The terse syntax of these commands makes most system administrators reluctant to read a sendmail.cf file, let alone write one! Fortunately, you can avoid writing your own sendmail.cf file, and we'll show you how.
There is rarely any good reason to write a sendmail.cf file from scratch. Locate an existing file with a configuration similar to your system's and modify it. That's how you configure sendmail, and that's what we discuss in this section.
Sample configuration files are delivered with most systems' software.
Often system administrators prefer to use the latest version of sendmail. They download the sendmail.tar file compile it and and use the m4 source files it contains to build a sendmail.cf file.
The sendmail cf/cf directory contains several sample configuration files. Several of these are generic files preconfigured for different operating systems. The cf/cf directory on my system contains generic configurations for BSD, Solaris, SunOS, HP Unix, Ultrix, OSF1, and Next Step. The directory also contains a few prototype files designed to be easily modified and used for other operating systems. We will modify the tcpproto.mc file, which is for systems that have direct TCP/IP network connections and no direct UUCP connections, to run on our Linux system.
In most Linux distributions and commercial Unixes sendmail is configured "ready to run." as a delivery agent not as MTA. To use sendmail as MTA you need to edit and then process with the m4 macro processor the actual configuration files.
Many sendmail.cf files have more or less the same structure because most are descendants of a few original files. Therefore, the files provided with your system probably are similar to the ones used in our examples. Some systems use a different structure, but the functions of the sections described here will be found somewhere in most sendmail.cf files. The sections are:
Defines the information that is specific to the individual host. In the linux.smtp.cf file, Local Information defines the host name, the names of any mail relay hosts, and the mail domain. It also contains the name that sendmail uses to identify itself when it returns error messages, the message that sendmail displays during an SMTP login, and the version number of the sendmail.cf file. (Increase the version number each time you modify the configuration.) This section is usually customized during configuration.
Defines the sendmail options. This section usually requires no modifications.
Defines the various message precedence values used by sendmail. This section is not modified.
Defines the users who are trusted to override the sender address when they are sending mail. This section is not modified. Adding users to this list is a potential security problem.
Defines the format of the headers that sendmail inserts into mail. This section is not modified.
Defines the rules used to rewrite mail addresses. Rewriting Rules contains the general rules called by sendmail or other rewrite rules. This section is not modified during the initial sendmail configuration. Rewrite rules are usually only modified to correct a problem or to add a new service.
Defines the instructions used by sendmail to invoke the mail delivery programs. The specific rewrite rules associated with each individual mailer are also defined in this section. The mailer definitions are usually not modified. However, the rewrite rules associated with the mailers are sometimes modified to correct a problem or to add a new service.
The section labels in the sample file delivered with your system are probably different from these. However, the structure of your sample file is probably similar to the structure discussed above in these ways:
The information that is customized for each host is probably at the beginning of the file.
Similar types of commands, e.g., option commands, header commands, etc., are usually grouped together.
The bulk of the file consists of rewrite rules.
The last part of the file probably contains mailer definitions intermixed with the rewrite rules that are associated with the individual mailers.
Look at the comments in your sendmail.cf file. Sometimes these comments provide valuable insight into the file structure and the things that are necessary to configure a system.
It's important to realize how little of sendmail.cf needs to be modified for a typical system. If you pick the right sample file to work from, you may only need to modify a few lines in the first section. From this perspective, sendmail configuration appears to be a trivial task. So why are system administrators intimidated by it? In large part it is because of the difficult syntax of the sendmail.cf configuration language.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Rajappa Iyer wrote:
>
> http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm
>
> Any obvious reasons why FreeBSD performed so poorly for these people?Here is a repeat of my post to -advocacy:
-- Terry
----
The article is meaningless.
Too bad they titled it "Which OS is Fastest for High-
Performance Network Applications?" instead of "Which OS is
Fastest for MailEngine?".The only implied caveat is the statement "Our customers
frequently ask us which operating system is best for
running our software" in paragraph 3 of the "Background"
section. This should have been in bold type in the first
paragraph.
--It makes a number of very large blunders, which are really
inexcusable, given that it tries to represent itself as a
fair and unbiased comparison.These blunders are in the tuning of FreeBSD, the best
architecture for FreeBSD applications (one shich they did
not even try to consider), in their choice of which items
they could micro-benchmark would really be indicative of
real-world performance, and, finally, in their experimental
methodology.Here is a short list, off the top of my head:
1) The mail server they were using doesn't come
with any of these systems "out of the box".2) Threaded processes are vastly inferior to
finite state automatons, when it comes to CPU
utilization on single CPU systems, and even on
multiple CPU systems, if there is async I/O
that can be scheduled on multiple CPUs.3) FreeBSD turns of write caching on IDE drives, by
default, in FreeBSD 4.3 and above; you can set
it to be like Linux, Solaris, and Windows, if
you don't care about your data. On FreeBSD 4.2
and below, Soft Updates are not enabled by
default. Either way, without tuning, you lose.4) IDE drives do not support tagged command queueing,
except IBM DTLA drives, which are known to fail
due to overheating and due to their electronics
being too slow for their radial track density for
interior tracks.5) Real servers with storage and I/O requirements
use SCSI drives so they can benefit from tagged
command queues, which allow I/O to be interleaved
instead of serialized.6) No well designed mail server keeps all queue
files in the same directory, unless it has been
designed to run on a particular system where that
is not a problem; this is a design portability
issue, not a performance issue.7) Sendmail can handle 400,000 8k emails in a 24 hour
period on a < 500MHz box, if it is properly set up
and queue dispersal is optimally configured (e.g.
with the patches from ftp://ftp.whistle.com/ ).8) "The most efficient asynchornous architecture" for
an application is OS-dependent.9) There are more than 3 ways to skin a cat, or to
architect a task.10) Sending an RSET instead of data measures only the
connection setup and teardown speeds, and does not
measure real throughput, and is not representative
of real world behaviour, in which mail messages,
when sent, contain data, and not just trivial
addressing information.11) Mail servers which support the ESMTP PIPELINE ability
have significantly higher throughput, even when just
doing addressing.12) You can not "tweak" FreeBSD's network connection
limits at run time; socket structurse, inpcb's,
and tcpcb's are allocated via a zone allocator,
prior to the system actually being started. This
zone can not be resized. Without the patch I posted
to make maxfiles boot-time tunable, FreeBSD can not
increase the number of sockets and files that it can
simultaneously handle, without a kernel recompile.
Thus the "tweaking" used was useless.13) For each connection, there is a tcptmpl structure,
which is used for keepalives. This structure will
consume one mbuf per connection; in addition, the
average TCP window size will be 16k; so you will
need 16k/2k (8) mbufs for custer pointers plus
16k/256 (64) mbufs for the window data, plus one
mbuf per connection, pplus one mbuf per connection,
if you are setting options. This means that you
will potentially need 74 mbufs per connection you
intend to support; without patching, this also is
not tunable except at compile time, and the value
was not tuned.14) The "average througput per network architecture" is
extremely misleading, both because of the limited
and inefficient architectures used in the test, and
in using an average to "determine" which was "the
best architecture for use on all OSs". Per OS numbers
would have been much more meaningful, since the final
architecture was chosen based on the average, and not
based on what was best for the OS being tested.15) Creation and deletion of large numbers of files in a
single directory is rather meaningless; witness the
moronic 'postmark' "benchmark", and the resulting
discussion on several FreeBSD lists. The "benchmark"
was clearly designed to put forth a political agenda
(in the context of the list discussion, this agenda
was the pro-ReiserFS position, despite Reiser's use
of several USL/Novell patents on Delayed Ordered
Writes, without the permission of the patent holders,
which render a pro-ResierFS argument as meaningless
as arguing about the number of angels which can dance
on the head of a pin).16) When you have an answer you want, all the evidence you
gather will tend to support the conclusion you have
already drawn, unless you are very, very careful to
eliminate your assumed biases in your experimental
design. This is very hard to do, even when trained
scientists are involved.
Feel free to pass this on to the magazine editors, the author,
or both; at the very least, it may teach them a little bit
about how to actually tune FreeBSD to get good numbers out of
it, instead of frobbing meaningless knobs and merely _believing_
they are tuning the system for higher performance.-- Terry
|
|
|
From: [email protected]
Date: Thu Sep 07 2000 - 00:58:44 CDT
Hello all,
Special thanks to the following gurus who helped. You guys are great!
J. J. Johnson
Emanuel Almeida
Sean Quaint
Brett Lymn
Jay Lessert
The following are the answers to my question (see below):
1) There is another way of checking for the sendmail version. Try:
# /usr/lib/sendmail -bt -d
You should see:
Version 8.9.3+Sun
Compiled with: LDAPMAP MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7
NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS
NISPLUS
QUEUE SCANF SMTP USERDB XDEBUG
Another variant is this:
# /usr/lib/sendmail -d0.1 -bt < /dev/null
I think both means the same thing :)
2) On the box that you are trying to connect to, edit the following
etc/default/login file
and "comment" the line as follows:
# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
#CONSOLE=/dev/console
Actually, I have yet to try them as my system administrator is busy. On the
other hand, it's only polite if I submit the summary early. Anyway, I think
it should work since others have tried them successfully. I'll try it once
my sys admin is free. If the results are different from the above, I'll
post another summary.
cheers!
heemeng
*** Original Question ***
Hi gurus,
I'm currently trying to check for the version of sendmail used in our
servers.
I know of one way of doing so, that is to telnet locally to the server
itself.
After logging in, I managed to get the following from one of my servers:
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 [email protected] ESMTP Sendmail 8.9.3+Sun/8.9.3; Mon, 28 Aug
2000
15:25:18
+0800 (SGT)
|
|
|
Tip of the Trade: Sendmail's Greet_Pause
By Carla SchroderSlamming is a popular spammer tactic in which the spammer quickly fires off SMTP messages without waiting for responses from the receiving server. A poorly behaved MTA will then accept traffic from the spammer, instead of rejecting it as it should. But even well-behaved MTAs are affected because of the sheer volume of traffic with which they are forced to deal. The venerable sendmail, as of version 8.13, has a nifty feature called "greet_pause" that not only rejects incorrect SMTP transactions, but also discourages re-sends.
In a normal SMTP transaction, the client first connects and the server is supposed to send back a "220" greeting, something like:
$ telnet mail.foo.org 25 Trying 12.34.56.78... Connected to foo.com. Escape character is '^]'. 220-host6.foo.org ESMTP Sendmail 8.13.6/8.13.6; Wed, 14 Jun 2006 18:04:49 -0600 220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail.Then, the client says "ehlo" or "helo," and the transaction continues. When the client is an impatient spammer and sends more commands without listening, the greet_pause feature detects this, marks the connection bad, and responds to anything else that tries to come over that connection with a 554 (transaction failed) message. It works by pausing briefly before sending out its 220 messages.The pause interval is configurable, so you can tune it as needed.
Interestingly, you'll probably find that your total spam attempts drop significantly after implementing greet_pause, possibly because the spammer's software thinks it's hitting a bad server or bad addresses, or otherwise getting stuck somehow. It's an ingenious and simple method with a low-overhead that discourages significant amounts of spam.
As always, be sure to whitelist all of your important addresses. Visit sendmail.org/doc/ to learn more.
Google matched content |
See also Sendmail Classes
Here are the top ten reasons _not_ to switch to qmail. 10. You rely on Sendmail's special features, such as using it to gain access to the root account when you forget the root password. 9. Having the CPU pegged at 100% all the time allows the server to double as a coffee warmer. 8. Afraid that users might use the disk space freed (when you delete Sendmail and replace it with qmail) to start a porno server. 7. Everyone who has ever touched your system's sendmail.cf file has died soon after under mysterious circumstances, 6. If you collect one more Sendmail bug-of-the-month, you win a free toaster! 5. Could no longer use handy excuse: "Oh, I didn't get your email; Sendmail must've eaten it." 4. Warm feeling your users get from hard-to-decipher failure messages. 3. You refuse to install anything you're not sure how to pronounce. 2. Eric Allman hypnotized you, and now you're convinced they just found The Last Bug. And, the number one reason for not switching to qmail: 1. You'd miss that good ole' Sendmail cruftiness.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
