lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed Jun 7 20:14:16 2006 From: ademar.gonzalez at gmail.com (Ademar Gonzalez) Subject: Strange Emails -- What are they? On 6/7/06, Pam Patterson <ppatters@...co.com> wrote: > Ademar Gonzalez wrote: > > On 6/7/06, Simon Smith <simon@...soft.com> wrote: > >> ok, that makes sense... will greylisting counter this? > > > > don't think graylisting will have much effect, each bot sending a few > > mails. > > Greylisting works by temporarily rejecting the first email from a sender > at an ip address to a recipient, and then waiting the see if the sending > mail server tries again as it should. If the server retries, the > ip:sender:recipient tuple is added to a database and not delayed ever again. > > Most spam-sending programs never retry, even with a temporary error. So > greylisting would probably help in this case. ok, i had a different greylisting in mind, will send the ip to the database if the recipient doesn't exists (works amazing against dictionary attacks). don't see too much sense in delaying the reception of a message addressed to an existing account given the volume of email we handle and given the fact that nothing stops the spammer from sending/relaying through a real MTA. they have already learned to queue. > What would really help is SPF, if you can manage it. That way you can > reject mail that claims to come from your domain but does not come from > your mail servers. But this is all a bit OT, not really full disclosure. > > -- > Pam yeah SPF is a good idea but incomplete, there is still the forwarders problem. also you need to provide the means to your clients to edit their SPF records (so they can add their ISP's mail server ips) and then it becomes a support nigthmare from the clients that don't have the knowledge to manage this. been there done that, too complicated. regards. ademar
Powered by blists - more mailing lists