Spam-block alerting via email?

[Marco Pizzoli]

Hi all,

I am using rspamd as a spam filter also on *outgoing* emails.

I am doing this only for permitting my users to send test emails before sending the actual newsletter.
for these tests they are giving me enough information so I can activate the spam system only for test emails.
The aim is to be capable of giving my internal customer evidence of potential spammyness of that specific mailing.

Now my problem is, I would like to give them evidence about the potential actual blocking.
Is there a way to send an email to a fixed email address reporting about the block?

And what if I am serving more than one domain and I need to report to a different email address based on the sending domain?

Too crazy? ;-)

I thought about the opportunity to leverage the rsyslog email-alerting feature, but I see (correct me if I am wrong) that I can't get enough information on a single log line just to produce the conditional email-alerting.

Thank you for your help

Marco

[Andrew Lewis]

Hi Marco,

> Is there a way to send an email to a fixed email address reporting about
> the block?

For outbound filtering, particularly if you will be talking to MUAs, I
would recommend silently discarding/redirecting mail and then alerting
on this rather than rejecting which may encourage the MUA to
retransmit. Suspected spam messages could be be delivered somewhere
(ie. actual message is the alert) or fed to some script which could
generate notifications. How this might work is integration-dependent.

If you want to generate alerts within rspamd, that is a possibility
too. In 1.5 lua_tcp is able to send email over SMTP:
https://rspamd.com/doc/lua/tcp.html - You could use metadata exporter:
https://rspamd.com/doc/modules/metadata_exporter.html - or your own
postfilter following similar design to push whole messages of interest
of information about these to redis pubsub / http / other. The issue
with this is that it will not be resilient to unavailability of the
services it integrates with - it will just time out and move on. You
could work around that by forcing 'soft reject' (message deferral) in
case of such failures.

Syslog-approach seems like it should be workable too. If you don't
have enough information on rspamd_task_write_log lines I would suggest
adding symbols to supplement this.

Best,
-AL.