Op Tue, 29 Mar 2016 12:47:48 +0200 schreef Joerg Jung <[email protected]>:
Am 29.03.2016 um 12:05 schrieb Boudewijn Dijkstra
<[email protected]>:
It was a bit of a struggle, but I managed to set up a simple build
environment in OpenBSD 5.9 for creating OpenSMTPD filters. I currently
havea filter in beta quality that performs an SPF check using libspf2
andinserts a "Received-SPF:" header into the message. Would the
OpenSMTPDdevelopers be interested in integrating such a program into
the Extraspackage?
Absolutely, yes. Send a diff or better a pull request, please :)
Make sure you follow coding style of existing filters.
Good, I will do that.
I am planning to build upon this to create a spammer-filter that
resemblesOpenBSD's spamd (in greylisting mode), but based on domain
names (and alsosender glob patterns).
This sounds as you want to do to many things in a single filter.
You can easily chain filters, so try to do single simple tasks in a
filter.
Keep it simple for a start and have a look into the existing ones, e.g.
filter-regex
Right, I could have different filters for checking, for tarpitting and for
greylisting. But they need to work together, which creates its own
challenges...
Alas the filter API doesn't provide a direct way to 'stutter' an entire
conversation, though of course it is possible to pause on every callback
event. What do you think of the idea of a stutter mode in OpenSMTPD?
I use it already, see filter-pause. You may want to extend it, instead
of re-inventing the wheel.
As mentioned above, you can chain things.
Make sure you follow timeouts recommended in RFCs for stuttering.
Filter-pause is useful, but spamd can pause after every outgoing
character. This is used for tarpitting; I often see tarpitted SMTP
conversations lasting about 8 minutes. When dealing with spammers,
following RFCs is not a primary concern.
This spammer-filter needs an interface to a database where greylisting
status is kept and where policies are kept. For a filter program, what
would you recommend for persistent storage?
This again sounds a bit over-engineered. Start simple, and add DB later.
Right, I can start with simple text files.
Do you really want to re-implement spamd, why?
Yes. Because:
1. Spammers often use the same domain names, but not the same IP address.
Domain-based policies make it possible to reject (SPF-[soft]failed) mail
from explicitly untrusted domains without a chance to pass the greylisting
test, when encountering a previously unknown IP-address.
2. Some big domains perform retries on different IP-addresses.
Domain-based greylisting alleviates the burden of maintaining big
whitelists.
3. Domain-based policies make it possible to accept (SPF-passed) mail from
trusted domains without greylisting delays, when encountering a previously
unknown IP-address.
4. Whitelisting an IP-address for all mail is kinda bad. (This is also why
SPF exists.)
I do admit that it can get overly complicated really quickly if you start
thinking about the combinations of different SPF results, different domain
trust levels and different strategies, but I do believe that it is
possible to have something that is both effective and easy to operate.
There are already tables in extras which use various DBs for lookups,
have a look there for ideas.
Ah, I hadn't looked there yet.
--
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
