Re: [gentoo-user] Greylisting idea
On 8/28/06, Grant <[EMAIL PROTECTED]> wrote: Greylisting seems to be the most effective way of eliminating unwanted email. The problem is that it also has the potential to eliminate a legitimate email. Couldn't a feature be added to greylisting software that dispatches an email to the sender of any email that is temporarily rejected and doesn't retry within a certain amount of time? The email could say something like, "Your message of {date} was rejected as possible spam. Please call us at {phone_number}." att.biz accounts do something like this. It isn't a phone call, but "go to $website and enter $code to unblock your mail to $recepient." -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
On Mon, Aug 28, 2006 at 05:38:37PM -0700, Richard Fish wrote: > On 8/28/06, Grant <[EMAIL PROTECTED]> wrote: > >Greylisting seems to be the most effective way of eliminating unwanted > >email. The problem is that it also has the potential to eliminate a > >legitimate email. Couldn't a feature be added to greylisting software > >that dispatches an email to the sender of any email that is > >temporarily rejected and doesn't retry within a certain amount of > >time? The email could say something like, "Your message of {date} was > >rejected as possible spam. Please call us at {phone_number}." > > att.biz accounts do something like this. It isn't a phone call, but > "go to $website and enter $code to unblock your mail to $recepient." TMDA (in portage) could be set up to do something like this, I believe. Toby -- PhD Student Quantum Information Theory group Max Planck Institute for Quantum Optics Garching, Germany email: [EMAIL PROTECTED] web: www.dr-qubit.org -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
> >Greylisting seems to be the most effective way of eliminating unwanted > >email. The problem is that it also has the potential to eliminate a > >legitimate email. Couldn't a feature be added to greylisting software > >that dispatches an email to the sender of any email that is > >temporarily rejected and doesn't retry within a certain amount of > >time? The email could say something like, "Your message of {date} was > >rejected as possible spam. Please call us at {phone_number}." > > att.biz accounts do something like this. It isn't a phone call, but > "go to $website and enter $code to unblock your mail to $recepient." TMDA (in portage) could be set up to do something like this, I believe. I'm going to go ahead and try greylisting. It sounds like regular postfix checks can reject legitimate email just like greylisting can end up doing, but postfix checks are cutting spam in half and it sounds like greylisting will do a lot better. I'm going to replace the following postix config: smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit smtpd_data_restrictions = reject_unauth_pipelining, permit with this: smtpd_recipient_restrictions = permit_mynetworks, check_policy_service inet:127.0.0.1:10030 reject_unauth_destination, permit How does that look? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
On Mon, 28 Aug 2006 17:30:48 -0700 Grant <[EMAIL PROTECTED]> wrote: > Greylisting seems to be the most effective way of eliminating unwanted > email. The problem is that it also has the potential to eliminate a > legitimate email. Couldn't a feature be added to greylisting software > that dispatches an email to the sender of any email that is > temporarily rejected and doesn't retry within a certain amount of > time? The email could say something like, "Your message of {date} was > rejected as possible spam. Please call us at {phone_number}." > > - Grant No, thats just silly. That would send a reply to every email that is a spam. Most spam has non-existent (or forged) "from" address, which means the mail will just bounce or go to someone whose address has been forged. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
On Tue, 29 Aug 2006 17:04:40 +1200, Nick Rout wrote: > No, thats just silly. That would send a reply to every email that is a > spam. Most spam has non-existent (or forged) "from" address, which > means the mail will just bounce or go to someone whose address has been > forged. And the rest will confirm to the spammer that they have a valid address, along with instructions for having their spam accepted. -- Neil Bothwick I am Barry Norman of the Borg - you will be assimilated - and why not? signature.asc Description: PGP signature
Re: [gentoo-user] Greylisting idea
> No, thats just silly. That would send a reply to every email that is a > spam. Most spam has non-existent (or forged) "from" address, which > means the mail will just bounce or go to someone whose address has been > forged. And the rest will confirm to the spammer that they have a valid address, along with instructions for having their spam accepted. The bounced messages would be easy to avoid and it's not necessary to include instructions about how to get the spam accepted. Forged addresses could be a problem though. Is there any way to verify that the sender address is legitimate without sending an email there? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
Grant wrote: Greylisting seems to be the most effective way of eliminating unwanted email. The problem is that it also has the potential to eliminate a legitimate email. Couldn't a feature be added to greylisting software that dispatches an email to the sender of any email that is temporarily rejected and doesn't retry within a certain amount of time? The email could say something like, "Your message of {date} was rejected as possible spam. Please call us at {phone_number}." - Grant I'd just configure a retry time of something large if you're worried about it. IIRC the default is one day and you could raise it to two days on a slow system without worrying that the db is getting too large. On the other hand it might be interesting to return an email like this: "Hi I'm the greylisting policy server. It took your mail system 36 hours to retry. Is your email admin insane? Almost every email server in existence has reasonable defaults that your idiot decided to mess with. I highly recommend someone take a walk down to his cube and give them a good smack in the back of the head." kashani -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
On Tue, 29 Aug 2006 07:55:45 -0700, Grant wrote: > Forged > addresses could be a problem though. Is there any way to verify that > the sender address is legitimate without sending an email there? The real problem is that the forged addresses are often real. I get enough spam without adding to it by getting one of these for each spam that is sent out with my address in the From: header. -- Neil Bothwick Did you know that eskimos have 17 different words for linguist? signature.asc Description: PGP signature
Re: [gentoo-user] Greylisting idea
> Greylisting seems to be the most effective way of eliminating unwanted > email. The problem is that it also has the potential to eliminate a > legitimate email. Couldn't a feature be added to greylisting software > that dispatches an email to the sender of any email that is > temporarily rejected and doesn't retry within a certain amount of > time? The email could say something like, "Your message of {date} was > rejected as possible spam. Please call us at {phone_number}." > > - Grant I'd just configure a retry time of something large if you're worried about it. IIRC the default is one day and you could raise it to two days on a slow system without worrying that the db is getting too large. How exactly are legitimate messages lost through greylisting? I've come up with these: 1. legitimate messages that don't retry (someone mentioned Amazon newsletters) 2. legitimate messages that take longer than the maximum specified retry period to retry (has anyone run into a mail server that takes longer than a day to retry?) 3. legitimate messages that retry from a different server each time they retry (someone mentioned that they have seen this) - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
> How exactly are legitimate messages lost through greylisting? I've > come up with these: > > 1. legitimate messages that don't retry (someone mentioned Amazon > newsletters) The postgrey whitelist included in the build covers some of the major ones. I'd question these being legitimate emails and I'd question this being a legitimate way to run your mail system, but this is where you'd likely see mail lost. Nice. I didn't know postgrey had a default whitelist. > 2. legitimate messages that take longer than the maximum specified > retry period to retry (has anyone run into a mail server that takes > longer than a day to retry?) No. Most I've seen is 12 hours at a small DSL provider in LA. The fastest is Hotmail at 30 seconds. Good news. > 3. legitimate messages that retry from a different server each time > they retry (someone mentioned that they have seen this) I've seen Dreamhost do this and I still can't fathom the idea behind it. unless webserver outgoing connections are originating from a NAT DHCP pool or something weird. However setting the IP check to be the first 24 bits, aka match on the class C, makes this go away in every case I'm aware of. Any drawbacks to that? Is this what you mean: # --lookup-by-subnet strip the last 8 bits from IP addresses (default) or this: # --lookup-by-host do not strip the last 8 bits from IP addresses or something else? In cases 2 and 3 the original mail sender would get their email returned after the standard four day timeout whereas the mail goes completely into the ether in case 1. Why wouldn't the email be returned to the sender in case 1? By the way, I've been greylisting for about 24 hours and spam has been reduced by about 99.5%. - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
Grant wrote: Any drawbacks to that? Is this what you mean: # --lookup-by-subnet strip the last 8 bits from IP addresses (default) Yep this one and no drawbacks I can think of. Why wouldn't the email be returned to the sender in case 1? Because number 1 is entirely composed of newsletters, automated responses, etc. Someone at Amazon sat down one day and realized that their mail queues were full of crap email. So rather than have a twenty server farm to send email, they took a short cut. The email is generated on the fly and piped directly to the socket for immediately delivery. I'm totally guessing here, but that's roughly how I'd do it. If the mail fails, the entire thing is dropped on the floor and maybe a db gets updated to reflect that it was never sent. You can send a ton of email this way because you never take the I/O hit of running the email through outbound MTA queues on the originating side. Because it never enters a "real" MTA it never gets retried when it fails. kashani -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Greylisting idea
> Any drawbacks to that? Is this what you mean: > > # --lookup-by-subnet strip the last 8 bits from IP addresses (default) Yep this one and no drawbacks I can think of. Cool, it's the default anyway. > Why wouldn't the email be returned to the sender in case 1? Because number 1 is entirely composed of newsletters, automated responses, etc. Someone at Amazon sat down one day and realized that their mail queues were full of crap email. So rather than have a twenty server farm to send email, they took a short cut. The email is generated on the fly and piped directly to the socket for immediately delivery. I'm totally guessing here, but that's roughly how I'd do it. If the mail fails, the entire thing is dropped on the floor and maybe a db gets updated to reflect that it was never sent. You can send a ton of email this way because you never take the I/O hit of running the email through outbound MTA queues on the originating side. Because it never enters a "real" MTA it never gets retried when it fails. That makes sense. I was thinking the messages in case 1 were sent from a normal mail server that was configured to not retry, but it sounds like you're talking about mail that goes through a totally different sending process. - Grant -- gentoo-user@gentoo.org mailing list