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
