New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2018-11-03/opensmtpd-released-and-upcoming-filters-preview/ #6

Open
poolpOrg opened this Issue Nov 3, 2018 · 5 comments

Comments

4 participants
@kaey

This comment has been minimized.

kaey commented Nov 4, 2018

Filters protocol looks very similar to communigate
https://www.communigate.com/communigatepro/Helpers.html#Filters
https://www.communigate.com/communigatepro/VirusScan.html

Congrats on releasing it!

@leo-unglaub

This comment has been minimized.

leo-unglaub commented Nov 5, 2018

The new filter design is absolutley amazing. I love it. It allows people to quickly write a filter in a simple shell script but it also allows you to redirect the filter-requests to a different (central filtering server) and process there. It's simply amazing.

I have already written a SPF filter in Rust. Works perfect.
Thanks for all your work!

@poolpOrg

This comment has been minimized.

Owner

poolpOrg commented Nov 6, 2018

@kaey I wasn't aware but it's not really surprising, I didn't do rocket science, the interesting part is not so much the protocol but rather the split between events reporting and filtering, where a filter may or not depend on reporting to build its state, this and the read from stdin / write to stdout logic which makes it trivial to plug with any language. Thanks for your comment.

@leo-unglaub oh my, I created a monster... :-)

@poolpOrg poolpOrg self-assigned this Nov 6, 2018

@ghewgill

This comment has been minimized.

ghewgill commented Nov 8, 2018

This looks great! Some requests:

  • Filter on link-connect event (for connection rejection before welcome message)
  • Some way to invoke spamd-like tarpit behaviour (slow responses), even if the remainder of the session has to be handled within the filter
  • A way to pass a tag back from a filter to smtpd
  • Consider a filter data format option, eg. JSON might make more sense for some filter implementations than pipe-delimited
@poolpOrg

This comment has been minimized.

Owner

poolpOrg commented Nov 8, 2018

This looks great! Some requests:

  • Filter on link-connect event (for connection rejection before welcome message)

This is already implemented, I use it myself

  • Some way to invoke spamd-like tarpit behaviour (slow responses), even if the remainder of the session has to be handled within the filter

This can be done using proc filters which actively slow down responses.

I have implemented a PoC filter which paused 5 seconds for each reply to
a particular IP address.

  • A way to pass a tag back from a filter to smtpd

This will be done, it was even discussed yesterday on IRC but I want the
DATA part to be finished first.

Tags are trickier because we already have a tagging mechanism which does
not operate at the same level so, technicity set apart, we need to think
how these two mechanisms will impact each other.

  • Consider a filter data format option, eg. JSON might make more sense for some filter implementations than pipe-delimited

That's a nope :-)

I don't want to deal with multiple formats in OpenSMTPD itself.

If a filter wants to work with json, in most languages that provide json
facilities it is trivial to convert |-delimited lines into json objects,
even using one-liners:

>>> import json
>>> json.dumps('report|smtp-in|protocol-server|1541271222|3189ac6874354895|250 poolp.org Hello localhost [127.0.0.1], pleased to meet you'.split('|'))
'["report", "smtp-in", "protocol-server", "1541271222", "3189ac6874354895", "250 poolp.org Hello localhost [127.0.0.1], pleased to meet you"]'
>>>

It doesn't make sense to me that OpenSMTPD should start supporting json,
otherwise next week someone will want XML and there will be no reason to
not implement that format, until someone comes with a thirds, etc...

Filters get to convert the simple format into what they want, and this way
our MTA gets to not depend on a json library :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment