[
https://issues.apache.org/jira/browse/JAMES-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17609107#comment-17609107
]
ouvtam edited comment on JAMES-3819 at 9/25/22 1:11 PM:
--------------------------------------------------------
Regarding DNS blocklist caching:
* dns4java already implements cache (memory) based on DNS TTL
* I would leave the caching to a local DNS cache resolver (e.g. unbound) which
can be tuned by applying a negative TTL when TTLs are too short (e.g. 60s)
* a lot of blocklists and allowlists (i.e. whitelists) penalize access through
public resolvers (e.g. Google / Cloudflare) and may return a special return
code (see [https://www.dnswl.org/?page_id=15] or
[https://www.spamhaus.org/returnc/pub/] ) which would lead to false positives
(i.e. James treats any response as listed=true, this should not apply to
special return codes). Since special return codes are implementation specifc it
would be wiser in my opinion to use a local DNS resolver (e.g. unbound) and
configure to access the blocklists/allowlists recursively (e.g. in unbound
configure them as stub-zones). I could provide a docker-compose example for
this.
* a local cache dns resolver can also be used in a distributed setup. It is
best practice to use a local DNS resolver when operating a SMTP relay anyway.
Regarding fail2ban:
We are using fail2ban rules that parse James' logfile (e.g. "Connection
restricted ...") to block IP addresses which appear on blocklists with
incremental ban time.
was (Author: JIRAUSER291242):
Regarding DNS blocklist caching:
* dns4java already implements cache (memory) based on DNS TTL
* I would leave the caching to a local DNS cache resolver (e.g. unbound) which
can be tuned by applying a negative TTL when TTLs are to short (e.g. 60s)
* a lot of blocklists and allowlists (i.e. whitelists) penalize access through
public resolvers (e.g. Google / Cloudflare) and may return a special return
code (see [https://www.dnswl.org/?page_id=15] or
[https://www.spamhaus.org/returnc/pub/] ) which would lead to false positives
(i.e. James treats any response as listed=true, this should not apply to
special return codes). Since special return codes are implementation specifc it
would be wiser in my opinion to use a local DNS resolver (e.g. unbound) and
configure to access the blocklists/allowlists recursively (e.g. in unbound
configure them as stub-zones). I could provide a docker-compose example for
this.
* a local cache dns resolver can also be used in a distributed setup. It is
best practice to use a local DNS resolver when operating a SMTP relay anyway.
Regarding fail2ban:
We are using fail2ban rules that parse James' logfile (e.g. "Connection
restricted ...") to block IP addresses which appear on blocklists with
incremental ban time.
> [GSOC] James as a (distributed) MX server
> -----------------------------------------
>
> Key: JAMES-3819
> URL: https://issues.apache.org/jira/browse/JAMES-3819
> Project: James Server
> Issue Type: Improvement
> Components: SMTPServer
> Reporter: Benoit Tellier
> Priority: Major
> Labels: gscoc2023, gsoc
>
> h3. Why ?
> Alternatives like Postfix...
> - Do not offer a unified view of the mail queue across nodes
> - Requires statefull persistent storage
> Given Apache James recent push to adopt a distributed mail queue based on
> Pulsar supporting delays (JAMES-3687), it starts making sense developing
> tooling for MX related tooling.
> I propose myself to mentor a Gsoc on this topic.
> h3. Benefits for the student
> At the end of this GSOC you will...
> - Have a solid understanding of email relaying and associated mechanics
> - Understand James modular architecture (mailet/ matcher / routes)
> - Have a hands-on expertise in SQL / NoSQL working with technologies like
> Cassandra, Redis, JPA...
> - Identify fix and solve architecture problems.
> - Conduct performance tests and develop an operational mindset
> h3. Inventory...
> James ships a couple of MX related tools within smtp-hooks/mailets in default
> packages. It would make sense to me to move those as an extension.
> James supports today...
> *checks agains DNS blacklists*. `DNSRBLHandler` smtp hook for instance.
> I did get an operational issue here: querying the blacklist on each mail can
> be slow. I bet a cache here would make sense to reduce the load on such
> blacklist.
> We could have a non-distributed extension based on a memory cache
> We could have a distributed extension based on a Redis cache.
> We would also need a little performance benchmark to document performance
> implications of activating DNS-RBL.
> Finally as quoted by a gitter guy: it would make more sens to have this done
> as a MailHook rather as a RcptHook as it would avoid doing the same job again
> and over again for each recipients.
> *Grey listing*. There's an existing implementation using JDBC as an
> underlying storage.
> Move it as an extension.
> Remove JDBC storage, propose 2 storage possibilities: in-memory for single
> node, REDIS for a distributed topology.
> Some work around *whitelist mailets*? Move it as an extension, propose JPA,
> Cassandra, and XML configured implementations ? With a route to manage
> entries in there for JPA + Cassandra ?
> Lossly related but a *distributed fail2ban* would be awesome to me!
> I would expect a student to do his *own little audit* and come up with extra
> suggestions!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
