Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

Interesting Idea...

Interesting Idea...

2007-04-19 by Da Beave

Hello All! We ve been using milter-greylist for the past 8 months and it s really worked out well.   Recently,  a friend of mine brought up a interesting idea

Re: [milter-greylist] Interesting Idea...

2007-04-19 by Matt Kettler

Da Beave wrote:

> 
> 	I friend of mine brought up a interesting idea.   Basically, 
> "autowhitelisting" via Subject: .   Basically,  if the subject contains
> a "certain string" in the Subject: line,   it'll automatically be 
> autowhitelisted.   This way,  for those 10% of people in our case,  they
> would request that when people e-mail them to put a special "secret" 
> string in the Subject: which would "autowhitelist" the inbound mail.
> 
> 	Something like a "acl whitelist subject",  then you could 
> put in the regexp you wish (your secret, for example).

Problem.. at the point the greylist-or-not decision is made, there is no subject
yet. In fact, there aren't any headers at all, only the connection and the
envelope information.

You only get the subject line (and any other message headers) as a part of the
DATA phase, and you have to wait for it ALL to be transfered.

At that point, greylisting the message could be really detrimental to your
network utilization, especially if the message is large and/or the sender has a
fast retry rate on 4xx errors.

The only things available are:
 1) the connecting IP
 2) the RDNS lookup of that IP (if any)
 3) the HELO string (if any)
 4) the MAIL FROM: (envelope sender)
 5) the RCPT TO: (envelope recipient(s)).

Re: [milter-greylist] Interesting Idea...

2007-04-19 by Da Beave

... A-ha.  I had a feeling there might be some sort of issue with this idea.    I didn t think about the Subject: being within the DATA side, or I could have

Re: [milter-greylist] Interesting Idea...

2007-04-20 by Seth Mos

>
> 	Hello All!

> 	I friend of mine brought up a interesting idea.   Basically,
> "autowhitelisting" via Subject: .   Basically,  if the subject contains
> a "certain string" in the Subject: line,   it'll automatically be
> autowhitelisted.   This way,  for those 10% of people in our case,  they
> would request that when people e-mail them to put a special "secret"
> string in the Subject: which would "autowhitelist" the inbound mail.
>
> 	Something like a "acl whitelist subject",  then you could
> put in the regexp you wish (your secret, for example).

I think you can do this with the urlcheck feature.

Cheers,

Seth

Re: [milter-greylist] Interesting Idea...

2007-04-20 by Seth Mos

> 	A-ha.  I had a feeling there might be some sort of issue with this
> idea.    I didn't think about the Subject: being within the DATA side,
> or I could have probably come up with that myself.   Anyways,  thanks for
> the information.

Would you be interested in the urlcheck feature I made and see if that
works for you?

It's the one I posted a few days back.

Kind regards,

Seth

Re: [milter-greylist] Interesting Idea...

2007-04-20 by Jacques Beigbeder

Hello,

>> 	Something like a "acl whitelist subject",  then you could 
>> put in the regexp you wish (your secret, for example).

Another idea: to send an e-mail without delay,
just send to
	<Jacques.Beigbeder=SomeSecret@ens.fr>

With sendmail, the rule:
	R$*=SomeSecret@$*       $1@$2
suppresses the secret, and the mail is correctly delivered.

With greylist:
	acl whitelist rcpt /=SomeSecret/

This works if all users in the destination domain
shares the same '=SomeSecret'.

--
Jacques Beigbeder                    |  Jacques.Beigbeder@...
Service de Prestations Informatiques |     http://www.spi.ens.fr
Ecole normale supérieure             |
45 rue d'Ulm                         |Tel : (+33 1)1 44 32 37 96
F75230 Paris cedex 05                |Fax : (+33 1)1 44 32 20 75

Re: [milter-greylist] Interesting Idea...

2007-04-20 by manu@netbsd.org

Jacques Beigbeder <jacques.beigbeder@...> wrote:

> With greylist:
>       acl whitelist rcpt /=SomeSecret/

This can even be implemented with a per-user daily secret, using the
urlcheck feature...

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] Interesting Idea...

2007-04-20 by Da Beave

... Right now,  milter-greylist is disabled for these users because they complain about the delay on certain (important) e-mails. That _truely_ does defect

Re: [milter-greylist] Interesting Idea...

2007-04-21 by Seth Mos

> On Fri, Apr 20, 2007 at 01:25:14PM -0400, vn wrote:
>> Still, imho, it defeats the purpose of greylisting...what if someone
>> leaks
>> this secret?  or even the logic of the daily secret change...
>
> 	Right now,  milter-greylist is disabled for these users because
> they complain about the "delay" on "certain" (important) e-mails.
> That _truely_ does defect the purpose.   With the "secret" or "daily
> secret",
> at least greylisting is still inplace.

That seems like a poor way of whitelisting emails. And a bit odd.

> 	Besides,  if a spammer/person really wants to bypass greylisting,
> it's not that hard.    :)  I'm still looking into the urlcheck feature.
> How bout this,  I'm implement it (or something similar) and report back.

If you want to use the same whitelist algorithm on your site it's really
easy. You can just us the urlcheck from my site since it's a public page.

That should do fine for testing.

Make sure to compile a current CVS or 4.0a2.

Then put into your greylist.conf
-----
# Use Url check to accept mail from valid MX hosts without delay
urlcheck "mxhostcheck"
"https://webmail.coltex.nl/spam/mxhostcheck.php?domain=%sf&ip=%i&fuzz=22&delay=900"
5
acl whitelist urlcheck "mxhostcheck"
-----

If you put that in, all mail from valid mail configurations will be
accepted. Then trawl the /var/log/mail/mail.log for "X-Greylist: URL check
passed" and check if the domains you require are matched by the page.

To give you an idea of what it does, this graph might explain it a bit.
http://localtoast.coltex.nl/spam/index.php

Cheers,

Seth

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.