| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Rationale: when you publish DANE records for certificate pinning, you MUST
offer TLS on the indicated service. Not offering TLS is verboten since
that would re-open the door for a MitM. This is obviously fundamentally
incompatible with having spamd in front of your mailservers - spamd kinda
is a MitM here, but intentional and utterly valid.
DANE is desirable because it allows one to not have to trust the broken
SSL CA model, and, depending on the mode chosen, even show the SSL cert
mafia the middle finger by not needing them at all.
ok reyk jsing bob
|
| |
|
|
|
| |
with backwards compatibility for records with 32-bit times.
OK deraadt@ beck@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an HMAC protected synchronization protocol for use by spamd and
spamlogd.
- spamd can receive updates from other hosts for GREY, WHITE, and TRAPPED db
entries, and will update the local /var/db/spamd accordingly.
- spamd can send updates when it makes changes to the GREY or TRAPPED
entries in the db to other hosts running spamd. (Note it does not send
WHITE entries because the other spamd will see the GREY changes and have
complete information to make appropritate decisions)
- spamlogd can send updates for WHITE db entries that it performs on the local
db to other hosts running spamd, which will then apply them on remote hosts.
note that while this diff provides synchronization for changes made to the
spamd db by the daemons, it does *not* provide for sychonizing changes
to the spamd db made manually with the spamdb command.
Synchronization protocol and most of the work by reyk@,
with a bunch of the spamd, and spamlogd stuff by me.
testing mostly at the U of A, running happily there under big load.
ok reyk@ jmc@
|
| | |
|
| |
|
|
|
|
|
|
|
| |
originates from a paper by Evan Harris which can be found at
http://projects.puremagic.com/greylisting/. This implementation makes
spamd allow for non-blacklisted addresses to be treated as "greylisted".
where they are tracked in a db file, and whitelisted by addition to a
pf table when the same envelope from and to are retried from the same
source IP address. Testing by many, ok deraadt@
|
| | |
|
| | |
|
| |
|
|
|
| |
-ansi -Wstrict-prototypes, update the Makefile to reflect
that.
|
| |
|
|
|
|
|
| |
which configures individual blacklists sources and deals with whitelists.
Perl still needs some stylistic changes as suggested by bmc which will go
in shortly.
ok deraadt@
|
| | |
|
| |
|