Added this SQL file in iRedMail, will be available in next release.

If someone want to contribute, please:

1) Create a new topic in this forum
2) Or, open an issue in https://bitbucket.org/zhb/iredmail/issues

I will commit them into iRedMail.

While I like the idea, the actual SQL Code is killing me to look at, why not just repeat the VALUES (...) clause?

INSERT INTO greylisting_whitelist (Source,Comment,Disabled) VALUES
('SenderIP:216.239.32.0/19','GOOGLE',0),
('SenderIP:64.233.160.0/19','GOOGLE',0)........

Hi,

in general I like the idea of sharing whitelists, but on this approach I don't like the fact, it's not updated constantly. So entries could become outdated (either new IPs missing or old IPs left in the list).

It would be nice to have some online and up2date version of whitelists. Either DNS zones similar to DNSBL or at leased a mechanism how to update whitelists via cron (inserts and also deletes).

Just idea: Maybe it could be good to share stable members of autowhitelists across trusted iRM installations and update all iRM servers with it? So choosen servers would have R/W access to this database and all others will just read from it.

that would be great 7t3chguy

7t3chguy - I would be very keen to support this idea.. Manual entry input into a site, CRONd update to servers. Bit of research will go a long way. This sounds like something that has been attempted lots before, collaboration is difficult...

camel1cz - Sharing AWL sounds problematic , its always possible people have different thresholds etc but still the option of sharing sounds nice.

I run iRM on PgSQL backend and everything is in PgSQL, also the cluebringer DB is in separate PgSQL database.

Just an idea - is't such a list already available somewhere? Maybe we can just integrate with existing service?

I like the idea, actually, it's been discussed privately long time ago, but not publicly (that's the mistake).

The idea discussed in this thread sounds like DNSBL, or some kind of central Postfix policy server. I believe we all agree fighting spam is not a one-time job, we have to continue working on white/blacklist/... to get better effect.

I'm in if you guys have time and technical skills to build this "service". I will contribute if i have required skills/time/...

Hi Zhang,

I cannot agree more!

From my point of view, I would do following:
- create central server with all policy lists used in iRM: for graylisting autowhitelist and autoblacklist and for both graylisting and checkhelo whitelist and blacklist (6 lists in total for now).
- every admin of iRM should have following options for each of above lists:
a) not use the shared list and maintain it locally (current functionality) and probably should be default option,
b) use the shared list but not to contribute (download only, no data sent to the central server),
c) contribute only (only sends out the data to the central server while local list remains w/o change),
d) both contribute local data and also synchronize with central list.
- update should be done once per day and scheduled via cron to random time to spread the load,

On central server:
- data from any host should be accepted,
- data to any host should be provided,
- structure of central list tables should be similar to the local + reference to the table "origin" which should have at least source IP and flag if trusted,
- only data from trusted  origins should be published,

Note to auto lists from graylisting:
- central server needs to track also the thresholds used when gathering data,
- client should tell the central server its configurated thresholds while requsting the list - server should provide only data with the same or stronger threshold setup.
- on local mailserver we have to make sure synchronization will not interfere with local expiration routines.

For all entries in local storage should be set a source - either local (default value) or remote (data came from the central server)

Qustions:
- should we do any kind of authentication agains the central server? Probably generated hash should be OK if any.
- is https communication secure enough (man in the middle attack etc.)
- how to deal with duplicitely submited data (entry comes from more servers),
- what language should be used on the clients? (something already there, so PHP, python or perl?)
- how to deal with the expiration of entries? On central server we should have clear algorithm how we expire entries in all lists,
- how to deal with wrong entries? You know, the delisting requests, etc.

I can contribute if you're interested.

We have to keep the trusted sources really trustful. So it cannot happen spammer will be able to submit IPs which will get into the public lists.

My opinion: even really few trusted servers with significant traffic and good admin can make life of the whole iRM community much more easier.

I can write some PHP to handle this, if Zhang would be up for it, wouldn't it best be fit into iRedAdmin or iRedAPD? You were saying you wanted to get rid of Cluebringer and fit Greylisting into iRedAPD, you could add this at the same time.

Agree. We can even query other DNSBL services to improve the effect.

Personally, i think we can discuss deep technical details later, just keep improving it on client-side (each iRedMail server).

I have a better idea:

*) we create a web interface to allow mail server admins to register an account
*) admins register account and list the IP address(es) of their mail servers there.
*) we do some simple verification to allow contribution from registered mail servers, to make sure it's not spammer.
*) allow requests from registered mail servers (not from servers not registered in web interface)
*) need a way to analyze contributed data, and submit to grey/white/blacklisting and return OK/REJECT/DISCARD/... when mail servers request to verify client IP/sender/...
*) allow registered mail admins to submit grey/white/blacklisting IP addresses, stored in a separate place. we should verify them before submitting them to database in production use.
*) Of course we should allow registered accounts to judge data submitted by other admins, don't be a one-man show.
*) Allow others to request to remove IP address from blacklists.
*) Allow mail admins to manage their own data on this web interface, this data doesn't share to others, but admin has the option to share it. This way, we don't need a way to contribute local data to central server, because they just manage data on central server.

I think this way is better (mentioned above):

*) Allow mail admins to manage their own data on this web interface, this data doesn't share to others, but admin has the option to share it. This way, we don't need a way to contribute local data to central server, because they just manage data on central server..

My idea is mentioned above: admin registers an account on central server, list their IP addresses there, then done.
Central server should drop request from unlisted IP addresses.

Do we have any other option? (A question, not a rhetorical question, don't get me wrong.)

The more times it shows up, the more possible it's a spam/whitelist. right?

The best solution might be: it doesn't require any software installed, like DNSBL service.
If we must have a agent like iRedAPD, i hope it's easy to learn and understand, Python is a good choice. (of course i don't mean we HAVE to use Python.)

I think we can discuss this in the future.

Agree.