IntelMQ Mailgen
===============
IntelMQ command line tool to process events.
Call `intelmqcbmail --help` to see the current usage.
Installation
============
Dependencies
------------
These libraries and programs are required:
- The python library `psycopg2` (`python3-psycopg2`) for PostgreSQL communication.
- The python library `gpg` (`python3-gpg`), part of the library gpgme.
Due to issues with Ubuntu 20.04, this dependency is not installed when installed with `pip` or `setup.py`
Other means of distributions (deb packages) are not affected by this bug.
- GnuPG (v>=2.2) for `python3-gpg`.
As a Python3 application, see the `install_requires` section
in setup.py for its dependencies.
If you install the deb-packages, the package management handles all dependencies.
For an installation from source use this command:
```
pip3 install -v -e .
```
**In order to use IntelMQ Mailgen, you require a working certbund-contact-expert
in IntelMQ, as Mailgen makes use of information and data which is not available
in the IntelMQs default fields.**
IntelMQ Configuration
---------------------
For Mailgen to work, the following IntelMQ bots will need to be configured
first:
1. Expert: CERT-bund Contact Database
2. Expert: CERT-bund Contact Rules
3. Output: PostgreSQL
You **must follow the setup instructions for these bots** before
setting up Mailgen.
Database
--------
The `intelmq-events` database and the `intelmq` database-user should
already have been set up by the configuration of the PostgreSQL output
bot. For use with Mailgen this setup has to be extended:
As database-superuser (usually via system user postgres):
1. Create a new database-user:
```
createuser --encrypted --pwprompt intelmq_mailgen
```
2. Extend the database:
```
psql -f sql/notifications.sql intelmq-events
```
3. Grant `intelmq` the right to insert new events via a trigger:
```
psql -c "GRANT eventdb_insert TO intelmq" intelmq-events
```
4. Grant the new user the right to send out notifications:
```
psql -c "GRANT eventdb_send_notifications TO intelmq_mailgen" intelmq-events
```
Interaction with IntelMQ and the events database
------------------------------------------------
The events written into the events database have been processed by the
rules bot which adds notification directives to the events. The
directives tell mailgen which notifications to generate based on that
event. The statements in `sql/notifications.sql` add triggers and tables
to the event database that process these directives as they come in and
prepare them for use by mailgen. In particular:
- The `directives` table contains all the directives. The main
attributes of a directive are
- ID of the event
- recipient address
- data format
- template name (see "Templates" below)
- how to aggregate
- whether and when it was sent. this is the ID of the corresponding
row in the `sent` table (see below)
- When a new event is inserted into the `events` table, a trigger
procedure extracts the directives and inserts them into `directives`.
- The `sent` table records which notifications have actually been sent.
Its main attributes are
- the ticket number generated for the notification
- a time stamp indicating when it was sent
When mailgen processes the directives, it reads the still unsent
directives from the database, aggregates directives that are
sufficiently similar that they could be sent in the same mail and calls
a series of scripts for each of the aggregated directives. These scripts
inspect the directive and if they can process the directive generate
mails from it. mailgen then sends these mails and records it in the
`sent` table.
Ticket Numbers
--------------
For every email sent by Mailgen a ticket number is generated. If a mail
was successfully sent, this number is stored in the table `sent`,
together with a timestamp when the mail was sent.
Configuration
=============
`intelmq-mailgen` currently searches for configuration files in two places:
1. `$HOME/.intelmq/intelmq-mailgen.conf` (user configuration file) and
2. `/etc/intelmq/intelmq-mailgen.conf` (system configuration file).
Settings are read from both files with the one in the user's home directory
taking precedence.
The sytem configuration file path can be overridden with the `--config`
command line parameter.
Both files must be in JSON format. A complete example can be found in
`intelmq-mailgen.conf.example`.
OpenPGP Signatures
------------------
`gnupg_home` has to point to the GnuPG home directory for email signatures.
It must:
* contains the private and public key parts for the OpenPGP signature without
password protection.
* is read/writable for the user running intelmq-mailgen.
For example, the following steps will create such a directory
and import a test signing key.
```
GNUPGHOME=/tmp/gnupghome mkdir $GNUPGHOME
chmod og-rwx $GNUPGHOME
GNUPGHOME=/tmp/gnupghome gpg2 --list-secret-keys
GNUPGHOME=/tmp/gnupghome gpg2 --import src/intelmq-mailgen/tests/keys/test1.sec
```
Depending on your GnuPG version you may want to set additional options
by editing `$GNUPGHOME/gpg.conf`.
For example, the following settings will set the default digest algorithm,
suppress emitting the GnuPG version, and add a comment line for signatures:
```
personal-digest-preferences SHA256
no-emit-version
comment Key verification <https://example.org/hints-about-verification>
```
(See the GnuPG documentation for details.)
Now, you should be able to sign using this key without being prompted for
a passphrase. Try, for example:
```
echo Moin moin. | GNUPGHOME=/tmp/gnupghome gpg2 --clearsign --local-user "5F503EFAC8C89323D54C252591B8CD7E15925678"
```
Templates
---------
mailgen comes with a templating mechanism that the scripts that process
the directives can use. This mechanism assumes that all templates are
files in the directory from the `template_dir` setting in the
configuration file.
The scripts that come with mailgen simply take the template name from
the directive they are processing. This means that the name is set by
the rules used by the rules bot, so see its documentation and
configuration for which templates you need.
Template Format
---------------
The first line of a template file is used as the subject line for mails.
The remaining lines will become the mail body. The body may optionally
be separated from the subject line by one or more empty lines.
Both subject and body text will be interpreted as
[Python3 Template strings](https://docs.python.org/3/library/string.html#template-strings)
and may allow some substitutions depending on the format. Subject and
body allow the same substitutions.
Typically supported substitutions:
- All formats:
- `${ticket_number}`
- Additional substitutions for CSV-based formats:
- `${events_as_csv}` for the CSV-formatted event data. This is only
useful in the body.
- When aggregating by event fields the event fields can also be used.
E.g. if a directive aggregates by `source.asn` you can use
`${source.asn}`
Like the template name, aggregation is determined by the rules bot,
so see there for details.
Database
--------
The database section in the configuration may look like:
```
"database": {
"event": {
"name": "intelmq-events",
"username": "intelmq_mailgen",
"password": "your DB password",
"host": "localhost",
"port": 5432
},
"additional_directive_where": ""
},
```
`additional_directive_where` parameter is optional and can contain SQL code
appended to the `WHERE` clause of the `SELECT` operation on the table
`directives`. The `AND` is appended automatically.
The columns of table `directives` are available as `d3` and the columns of
table `events` as `events`. Normally the table `events` is not queried and
only joined for the where statement if `additional_directive_where` contains
`events.`.
Examples:
```json
"additional_directive_where": "\"template_name\" = 'qakbot_provider'"
"additional_directive_where": "events.\"feed.code\" = 'oneshot'"
```
Mind the correct quoting.
If access to the table events is required, the used postgres user needs
`UPDATE` permissions access to the table. This is by default not the case
for mailgen-installations!
This imperfection is a result of the update-locking on the table `directives`
and the join of `events` in the same sub-statement.
Operation manual
================
The logfile shall be monitored for errors to detect unwanted conditions.
Especially grep for:
```
* 'ERROR'
* 'Error:'
```
Each error condition should be handled by an administrator
or service technician soon. It is recommended to use a monitor system
to notify administrators as soon as such a string occurs in the log.
#### Log file contents
There should be no `Traceback` or other ERROR information in the log
of mailgen. Please read the lines in question, often they have good
hints about cause of the failure. Some problem may be solved by correcting
the configuration.
INFO lines appear during normal operations.
One condition to get an INFO message is if Mailgen detects
that it is already running to that a second instance does not start.
If this is the case, the running Mailgen process may still have problems
and during the nature of log file, the messages of the Mailgen that
tries to start up, may appear interwoven with the error conditions.
#### Mailgen needs to lock db rows
During a run, if mailgen is started a second time,
it will fail to lock the necessary rows in the
database. The `postgres.log` file will record the failed locks, e.g. like
```
2020-12-15 09:00:02 UTC ERROR: could not obtain lock on row in relation "directives"
```
which can be ignored.
#### Mailgen tries to continue
Mailgen will try to continue processing directives and sending mails,
even if some batch of mails could not be send for several reasons.
If it can't find templates, for instance, it will continue with the next
directive and log an error message and the stacktrace. The error message
contains information about the directives that could not be processed.
The `directive_ids` part in the output is a list with the IDs of the
rows in the `directives` table and `event_ids` a list with ids for
events in the `events` table.
This information can be used by an administrator to see which events and emails
may not have gone out in detail, to deal with them later, possibly with
a small script depending on the problem cause.
Developer Information
=====================
Security Considerations
-----------------------
* It is assumed that we need to protect against malicious external
data coming to us via the database.
* We do not need (or can) protect against local attacks
with administration rights.
* As our command will be able to run with and without user interaction,
we assume that only users with administration rights
have access to the machine and are allowed to start the interactive variant.
* The private key material for signing will have
no extra protection by passphrase, thus the system itself
needs to be secured adequately. (This can include separating
the setup of intelmq itself on a different machine with only access
to fill the database.)
* We should pay attention to preventing that the complete system
becomes an effective signature (or encryption) oracle.
To explain: Consider an attacker who will receive an automatic notification
from our system. If this attacker also can trigger a warning over
an used feed, she may partly control which plaintext is to be signed
(or somewhere encrypted) and gets the automated result. There is a small
potential under some circumstances that this can be used for
an adaptive-plaintext attack.
Column Names
------------
It is possible to define names for the CSV-columns in code. For instance
in `example_scripts/10shadowservercsv.py`, the dictionary
`standard_column_titles` maps event field names to column titles. These
are used by most of the CSV formats later defined in `table_formats`.
The formats specified there can still use special column titles if
necessary.
Transformations
---------------
Currently, data is not transformed when it is being added to the CSV output.
Mailgen always removes the "UTC" notations from time stamps in `time.source`.
It ensures that time stamps will always be UTC.
Testing
-------
An easy way to test the actual sending of emails is to use Python's
`smtpd` module running the `DebuggingServer`:
python3 -m smtpd -d -n -c DebuggingServer localhost:8025
(Don't forget to configure the corresponding
SMTP host and port in your config.)
If you want to capture emails in Maildir format you can use
https://pypi.org/project/dsmtpd/, e.g.
```sh
git clone git://github.com/matrixise/dsmtpd.git
cd dsmtpd
python3 -m dsmtpd -i localhost -p 8025 -d /path/to/Maildir
```
`/path/to/Maildir` has to be either an existing
[Maildir](https://en.wikipedia.org/wiki/Maildir) or non-existing,
in which case it will be created by dsmtpd.
You can access the Maildir with mutt, for example:
```
mutt -f /path/to/Maildir
```
Hint: By default `Esc P` will trigger mutt's `<check-traditional-pgp>`
[function](http://www.mutt.org/doc/manual/#reading-misc), in case you
want to check a no-MIME signature.
Test Suite
----------
The test suite is split into two parts because some tests may fail depending on
hardware specs (execution time) and their failure would not indicate errors per
se.
The regular unit tests which must succeed can be started with ``make check``;
to run the complete test suite, use ``make check_all``.
History
=======
The intelmq-mailgen file was initially copied from
https://github.com/certat/intelmq/blob/a29da5d798bd114535326ffdd2f5000c4b6a21e7/intelmq/bin/intelmqcli (revision from 2016-03-08).
Raw data
{
"_id": null,
"home_page": "https://github.com/intevation/intelmq-mailgen",
"name": "intelmqmail",
"maintainer": "Intevation GmbH",
"docs_url": null,
"requires_python": "",
"maintainer_email": "sebastian.wagner@intevation.de",
"keywords": "intelmq mailer postgresql abuse-handling",
"author": "Intevation GmbH",
"author_email": "info@intevation.de",
"download_url": "https://files.pythonhosted.org/packages/31/fb/62256325376eae1a57d3730d87768f411b6c505ed28786a16b173cca8dac/intelmqmail-1.3.1.tar.gz",
"platform": null,
"description": "IntelMQ Mailgen\n===============\n\nIntelMQ command line tool to process events.\n\nCall `intelmqcbmail --help` to see the current usage.\n\nInstallation\n============\n\nDependencies\n------------\n\nThese libraries and programs are required:\n- The python library `psycopg2` (`python3-psycopg2`) for PostgreSQL communication.\n- The python library `gpg` (`python3-gpg`), part of the library gpgme.\n Due to issues with Ubuntu 20.04, this dependency is not installed when installed with `pip` or `setup.py`\n Other means of distributions (deb packages) are not affected by this bug.\n- GnuPG (v>=2.2) for `python3-gpg`.\n\nAs a Python3 application, see the `install_requires` section\nin setup.py for its dependencies.\n\nIf you install the deb-packages, the package management handles all dependencies.\n\nFor an installation from source use this command:\n```\npip3 install -v -e .\n```\n\n**In order to use IntelMQ Mailgen, you require a working certbund-contact-expert\nin IntelMQ, as Mailgen makes use of information and data which is not available\nin the IntelMQs default fields.**\n\nIntelMQ Configuration\n---------------------\n\nFor Mailgen to work, the following IntelMQ bots will need to be configured\nfirst:\n\n 1. Expert: CERT-bund Contact Database\n 2. Expert: CERT-bund Contact Rules\n 3. Output: PostgreSQL\n\nYou **must follow the setup instructions for these bots** before\nsetting up Mailgen.\n\n\nDatabase\n--------\n\nThe `intelmq-events` database and the `intelmq` database-user should\nalready have been set up by the configuration of the PostgreSQL output\nbot. For use with Mailgen this setup has to be extended:\n\nAs database-superuser (usually via system user postgres):\n\n1. Create a new database-user:\n ```\n createuser --encrypted --pwprompt intelmq_mailgen\n ```\n\n2. Extend the database:\n ```\n psql -f sql/notifications.sql intelmq-events\n ```\n\n3. Grant `intelmq` the right to insert new events via a trigger:\n ```\n psql -c \"GRANT eventdb_insert TO intelmq\" intelmq-events\n ```\n\n4. Grant the new user the right to send out notifications:\n ```\n psql -c \"GRANT eventdb_send_notifications TO intelmq_mailgen\" intelmq-events\n ```\n\n\nInteraction with IntelMQ and the events database\n------------------------------------------------\n\nThe events written into the events database have been processed by the\nrules bot which adds notification directives to the events. The\ndirectives tell mailgen which notifications to generate based on that\nevent. The statements in `sql/notifications.sql` add triggers and tables\nto the event database that process these directives as they come in and\nprepare them for use by mailgen. In particular:\n\n - The `directives` table contains all the directives. The main\n attributes of a directive are\n\n - ID of the event\n - recipient address\n - data format\n - template name (see \"Templates\" below)\n - how to aggregate\n - whether and when it was sent. this is the ID of the corresponding\n row in the `sent` table (see below)\n\n - When a new event is inserted into the `events` table, a trigger\n procedure extracts the directives and inserts them into `directives`.\n\n - The `sent` table records which notifications have actually been sent.\n Its main attributes are\n\n - the ticket number generated for the notification\n - a time stamp indicating when it was sent\n\n\nWhen mailgen processes the directives, it reads the still unsent\ndirectives from the database, aggregates directives that are\nsufficiently similar that they could be sent in the same mail and calls\na series of scripts for each of the aggregated directives. These scripts\ninspect the directive and if they can process the directive generate\nmails from it. mailgen then sends these mails and records it in the\n`sent` table.\n\n\nTicket Numbers\n--------------\n\nFor every email sent by Mailgen a ticket number is generated. If a mail\nwas successfully sent, this number is stored in the table `sent`,\ntogether with a timestamp when the mail was sent.\n\n\nConfiguration\n=============\n\n`intelmq-mailgen` currently searches for configuration files in two places:\n\n 1. `$HOME/.intelmq/intelmq-mailgen.conf` (user configuration file) and\n 2. `/etc/intelmq/intelmq-mailgen.conf` (system configuration file).\n\nSettings are read from both files with the one in the user's home directory\ntaking precedence.\n\nThe sytem configuration file path can be overridden with the `--config`\ncommand line parameter.\n\nBoth files must be in JSON format. A complete example can be found in\n`intelmq-mailgen.conf.example`.\n\nOpenPGP Signatures\n------------------\n\n`gnupg_home` has to point to the GnuPG home directory for email signatures.\nIt must:\n\n * contains the private and public key parts for the OpenPGP signature without\n password protection.\n * is read/writable for the user running intelmq-mailgen.\n\nFor example, the following steps will create such a directory\nand import a test signing key.\n\n```\nGNUPGHOME=/tmp/gnupghome mkdir $GNUPGHOME\nchmod og-rwx $GNUPGHOME\nGNUPGHOME=/tmp/gnupghome gpg2 --list-secret-keys\nGNUPGHOME=/tmp/gnupghome gpg2 --import src/intelmq-mailgen/tests/keys/test1.sec\n```\n\nDepending on your GnuPG version you may want to set additional options\nby editing `$GNUPGHOME/gpg.conf`.\n\nFor example, the following settings will set the default digest algorithm,\nsuppress emitting the GnuPG version, and add a comment line for signatures:\n\n```\npersonal-digest-preferences SHA256\nno-emit-version\ncomment Key verification <https://example.org/hints-about-verification>\n```\n(See the GnuPG documentation for details.)\n\nNow, you should be able to sign using this key without being prompted for\na passphrase. Try, for example:\n\n```\necho Moin moin. | GNUPGHOME=/tmp/gnupghome gpg2 --clearsign --local-user \"5F503EFAC8C89323D54C252591B8CD7E15925678\"\n```\n\nTemplates\n---------\n\nmailgen comes with a templating mechanism that the scripts that process\nthe directives can use. This mechanism assumes that all templates are\nfiles in the directory from the `template_dir` setting in the\nconfiguration file.\n\nThe scripts that come with mailgen simply take the template name from\nthe directive they are processing. This means that the name is set by\nthe rules used by the rules bot, so see its documentation and\nconfiguration for which templates you need.\n\n\nTemplate Format\n---------------\n\nThe first line of a template file is used as the subject line for mails.\nThe remaining lines will become the mail body. The body may optionally\nbe separated from the subject line by one or more empty lines.\n\nBoth subject and body text will be interpreted as\n[Python3 Template strings](https://docs.python.org/3/library/string.html#template-strings)\nand may allow some substitutions depending on the format. Subject and\nbody allow the same substitutions.\n\nTypically supported substitutions:\n\n - All formats:\n\n - `${ticket_number}`\n\n - Additional substitutions for CSV-based formats:\n\n - `${events_as_csv}` for the CSV-formatted event data. This is only\n useful in the body.\n\n - When aggregating by event fields the event fields can also be used.\n E.g. if a directive aggregates by `source.asn` you can use\n `${source.asn}`\n\n Like the template name, aggregation is determined by the rules bot,\n so see there for details.\n\nDatabase\n--------\n\nThe database section in the configuration may look like:\n\n```\n \"database\": {\n \"event\": {\n \"name\": \"intelmq-events\",\n \"username\": \"intelmq_mailgen\",\n \"password\": \"your DB password\",\n \"host\": \"localhost\",\n \"port\": 5432\n },\n \"additional_directive_where\": \"\"\n },\n```\n\n\n\n`additional_directive_where` parameter is optional and can contain SQL code\nappended to the `WHERE` clause of the `SELECT` operation on the table\n`directives`. The `AND` is appended automatically.\nThe columns of table `directives` are available as `d3` and the columns of\ntable `events` as `events`. Normally the table `events` is not queried and\nonly joined for the where statement if `additional_directive_where` contains\n`events.`.\nExamples:\n```json\n \"additional_directive_where\": \"\\\"template_name\\\" = 'qakbot_provider'\"\n \"additional_directive_where\": \"events.\\\"feed.code\\\" = 'oneshot'\"\n```\nMind the correct quoting.\nIf access to the table events is required, the used postgres user needs\n`UPDATE` permissions access to the table. This is by default not the case\nfor mailgen-installations!\nThis imperfection is a result of the update-locking on the table `directives`\nand the join of `events` in the same sub-statement.\n\nOperation manual\n================\n\nThe logfile shall be monitored for errors to detect unwanted conditions.\nEspecially grep for:\n```\n * 'ERROR'\n * 'Error:'\n```\n\nEach error condition should be handled by an administrator\nor service technician soon. It is recommended to use a monitor system\nto notify administrators as soon as such a string occurs in the log.\n\n#### Log file contents\nThere should be no `Traceback` or other ERROR information in the log\nof mailgen. Please read the lines in question, often they have good\nhints about cause of the failure. Some problem may be solved by correcting\nthe configuration.\n\nINFO lines appear during normal operations.\nOne condition to get an INFO message is if Mailgen detects\nthat it is already running to that a second instance does not start.\nIf this is the case, the running Mailgen process may still have problems\nand during the nature of log file, the messages of the Mailgen that\ntries to start up, may appear interwoven with the error conditions.\n\n#### Mailgen needs to lock db rows\nDuring a run, if mailgen is started a second time,\nit will fail to lock the necessary rows in the\ndatabase. The `postgres.log` file will record the failed locks, e.g. like\n```\n2020-12-15 09:00:02 UTC ERROR: could not obtain lock on row in relation \"directives\"\n```\nwhich can be ignored.\n\n#### Mailgen tries to continue\nMailgen will try to continue processing directives and sending mails,\neven if some batch of mails could not be send for several reasons.\n\nIf it can't find templates, for instance, it will continue with the next\ndirective and log an error message and the stacktrace. The error message\ncontains information about the directives that could not be processed.\nThe `directive_ids` part in the output is a list with the IDs of the\nrows in the `directives` table and `event_ids` a list with ids for\nevents in the `events` table.\n\nThis information can be used by an administrator to see which events and emails\nmay not have gone out in detail, to deal with them later, possibly with\na small script depending on the problem cause.\n\n\nDeveloper Information\n=====================\n\nSecurity Considerations\n-----------------------\n * It is assumed that we need to protect against malicious external\ndata coming to us via the database.\n * We do not need (or can) protect against local attacks\nwith administration rights.\n * As our command will be able to run with and without user interaction,\nwe assume that only users with administration rights\nhave access to the machine and are allowed to start the interactive variant.\n * The private key material for signing will have\nno extra protection by passphrase, thus the system itself\nneeds to be secured adequately. (This can include separating\nthe setup of intelmq itself on a different machine with only access\nto fill the database.)\n* We should pay attention to preventing that the complete system\nbecomes an effective signature (or encryption) oracle.\nTo explain: Consider an attacker who will receive an automatic notification\nfrom our system. If this attacker also can trigger a warning over\nan used feed, she may partly control which plaintext is to be signed\n(or somewhere encrypted) and gets the automated result. There is a small\npotential under some circumstances that this can be used for\nan adaptive-plaintext attack.\n\n\nColumn Names\n------------\n\nIt is possible to define names for the CSV-columns in code. For instance\nin `example_scripts/10shadowservercsv.py`, the dictionary\n`standard_column_titles` maps event field names to column titles. These\nare used by most of the CSV formats later defined in `table_formats`.\nThe formats specified there can still use special column titles if\nnecessary.\n\n\nTransformations\n---------------\n\nCurrently, data is not transformed when it is being added to the CSV output.\n\nMailgen always removes the \"UTC\" notations from time stamps in `time.source`.\nIt ensures that time stamps will always be UTC.\n\nTesting\n-------\n\nAn easy way to test the actual sending of emails is to use Python's\n`smtpd` module running the `DebuggingServer`:\n\n python3 -m smtpd -d -n -c DebuggingServer localhost:8025\n\n(Don't forget to configure the corresponding\nSMTP host and port in your config.)\n\nIf you want to capture emails in Maildir format you can use\nhttps://pypi.org/project/dsmtpd/, e.g.\n```sh\ngit clone git://github.com/matrixise/dsmtpd.git\ncd dsmtpd\npython3 -m dsmtpd -i localhost -p 8025 -d /path/to/Maildir\n```\n\n`/path/to/Maildir` has to be either an existing\n[Maildir](https://en.wikipedia.org/wiki/Maildir) or non-existing,\nin which case it will be created by dsmtpd.\n\nYou can access the Maildir with mutt, for example:\n```\nmutt -f /path/to/Maildir\n```\nHint: By default `Esc P` will trigger mutt's `<check-traditional-pgp>`\n[function](http://www.mutt.org/doc/manual/#reading-misc), in case you\nwant to check a no-MIME signature.\n\n\nTest Suite\n----------\n\nThe test suite is split into two parts because some tests may fail depending on\nhardware specs (execution time) and their failure would not indicate errors per\nse.\n\nThe regular unit tests which must succeed can be started with ``make check``;\nto run the complete test suite, use ``make check_all``.\n\n\nHistory\n=======\n\nThe intelmq-mailgen file was initially copied from\nhttps://github.com/certat/intelmq/blob/a29da5d798bd114535326ffdd2f5000c4b6a21e7/intelmq/bin/intelmqcli (revision from 2016-03-08).\n",
"bugtrack_url": null,
"license": "GNU Affero General Public License",
"summary": "A mail sending module for IntelMQ",
"version": "1.3.1",
"split_keywords": [
"intelmq",
"mailer",
"postgresql",
"abuse-handling"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "f35a7f11756c1648cc341769415acc0643f89c5ae3ff48ba16aab3d00c61c4fc",
"md5": "fca27846dc96b86d7f682c4ec5f790ae",
"sha256": "ff7531f4840d0ec31aeb1c9dfe76c80ba09742c4c9a6377f2c3a48d1002aa4d8"
},
"downloads": -1,
"filename": "intelmqmail-1.3.1-py2.py3-none-any.whl",
"has_sig": true,
"md5_digest": "fca27846dc96b86d7f682c4ec5f790ae",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": null,
"size": 29855,
"upload_time": "2023-03-15T10:32:49",
"upload_time_iso_8601": "2023-03-15T10:32:49.508085Z",
"url": "https://files.pythonhosted.org/packages/f3/5a/7f11756c1648cc341769415acc0643f89c5ae3ff48ba16aab3d00c61c4fc/intelmqmail-1.3.1-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "31fb62256325376eae1a57d3730d87768f411b6c505ed28786a16b173cca8dac",
"md5": "b423ed5fcb470b95160afdf8ec69e993",
"sha256": "75bc75a5b299c6ea3aab96ed78d79ae12bb38ca96f3cc14064778936ccdacfc8"
},
"downloads": -1,
"filename": "intelmqmail-1.3.1.tar.gz",
"has_sig": true,
"md5_digest": "b423ed5fcb470b95160afdf8ec69e993",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 32110,
"upload_time": "2023-03-15T10:32:52",
"upload_time_iso_8601": "2023-03-15T10:32:52.378310Z",
"url": "https://files.pythonhosted.org/packages/31/fb/62256325376eae1a57d3730d87768f411b6c505ed28786a16b173cca8dac/intelmqmail-1.3.1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-03-15 10:32:52",
"github": true,
"gitlab": false,
"bitbucket": false,
"github_user": "intevation",
"github_project": "intelmq-mailgen",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "intelmqmail"
}
JSON
