I'm agree with Sam solution, that's the way to do a nice database,you can check which domains sends emails to your domain, then add to the graylist file or directory, after two weeks or 4 weeks will be better, then you turn on graylist.
Users will see a nice service of mail, server will work better because graylisting it's a cool utility. David pienso que esa es la manera de hacerlo, pero sobre todo no puedes activar el graylisting con tan poco tiempo porque eso no seria graylisting. Revisa cada semana el log y vas añadiendo los distintos dominios de los que recibes email, o los añades al directorio de graylisting o en una lista whitelist para evitar chequeos. Despues de un mes, activas el graylisting y seguro que tus usuarios lo notaran. Pero debes de tener en cuenta que todo no puede ser, o una cosa o la otra, no ambas a la vez porque te va a dar problemas. Por ejemplo yo lo monte con el dominio ibm.com pero resulta que ibm usa subdominios... asi que tienes que tenerlo en cuenta porque un usuario puede recibir correos de es.ibm.com o uk.ibm.com, ie.ibm.com,etc... Suerte 2009/4/24 Sam Clippinger <[email protected]>: > I understand now. Basically, you want to add some addresses to the > graylist filter but since you don't know which addresses to use, you're > trying to use the graylist filter to collect that information. > > I have a different idea that will probably work better. Instead of > finding a way to partially enable the graylist filter, just leave it > turned off for a while. Run spamdyke so that it will log messages about > incoming and outgoing email. Then, after a week or two, use the logs to > discover which remote addresses are sending to your users and > vice-versa. That will give better information anyway, since it will > show which addresses your users are sending _to_ and how often. Those > are the ones that most likely need to be added to the graylist filter. > > -- Sam Clippinger > > David Sánchez Martín wrote: >> >> >>> David, >>> >>> That sounds like a neat idea, but I don't think it'd work. If >>> you simply >>> allow the session to complete and create a greylist entry for >>> everything, you will have effectively whitelisted every incoming >>> message, including the bad ones. Greylisting works because >>> some spammers >>> don't retry when a session fails. If everything passes, >>> you've no way of >>> knowing which ones would or would not have retried. The greylist >>> database would be useless. >>> >>> >> >> Let me think about it. >> >> If greylisting is enabled as usual: >> >> When a "foreign" user sends a message to a local user is greylisted, then: >> >> 1.- It's created an entry in the greylisting database. >> 2.- It's blocked and each retry is blocked also at least for >> graylist-min-secs seconds. >> 3.- No further tests are passed. Session is closed. >> >> When graylist-min-secs time passes: >> >> 1.- The message passes greylist filter and touches the file. >> 2.- The message is tested against other filters. >> >> >> Ok, >> >> What i'm trying to accomplish: >> >> When a user "foreign" a message to a local then: >> >> 1.- The message passes greylist filter and touches the file. >> 2.- The message is tested against other filters. >> >> >> That will populate the database, that is what i want before putting graylist >> at work. >> >> Sorry, perhaps I'm missing something. >> >> Best regards. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
