Yahoo Groups archive

Milter-greylist

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

Message

Some features for future releases...

2008-01-18 by ondrej_v0

Hi all,
Ok, first of all many thanks to everyone who helped to develop this
great piece of opensource product. We are seriously considering it for
a company who originally intended to purchase a commercial product
10.000 Euro worth.

Regarding the features for future releases, I agree with Benoit that
the concept of the "poor man SPF record" and "ala sendmail's
Feature('badMX')" would help to whitelist some "promissing" senders.

I could also see a further improvement in multi-MX scenario:
What usually happens is that when a sender wants to send a mail to say
joe@... where:
MX 10 mx1.example.com
MX 50 mx2.example.com
.. then mx1.example.com is contacted first. Now if that machine is
running milter-greylist, it receives 451 temp error and vast majority
of senders go immediately (say in 1 minute) to mx2.example.com.
If mx2 is also running milter-greylist, we could (possibly) whitelist
those senders on mx2 as I would not expect spammers to try mx2 after
being rejected at mx1.
Also, similarly, senders trying immediately mx2 (without trying mx1
first) are highly suspicious.

Other suggestion:
Limit the greylist delay period. Example: I want to set greylist delay
to 15 minutes and, but I also want to set the maximum retry delay to 1
day and while-list to 7 days. This means a sender will be forced to
wait at least 15 minutes, but also is expected retry in at least 24
hours. Those who pass would be whitelisted for 7 days.
I am not sure whether this is possible at the moment.

Thanks a lot again.
Ondrej


--- In milter-greylist@yahoogroups.com, Benoit Branciard
<benoit.branciard@...> wrote:
>
> here are some features I think would be nice to add one day in a
release 
> of milter-greylist:
> 
> - sender MX validity : the idea is to able to identify sender domains 
> whose MX is "bad", ie points to at least one IP pertaining to an 
> IANA-reserved block : loopback, private use, multicast, broadcast, 
> testing, link-local, and so on (see
http://www.faqs.org/rfcs/rfc3330.html).
> Care should be taken to account for CNAME nesting (with max recursion 
> counter and loop detection), DNS temporary failures, and IPv6
counterparts.
> Sendmail 8.14 introduced such feature, but adding it to milter-greylist 
> is still interesting because of integration in ACL system.
> 
> example of use :
> 
> 	racl blacklist mx bad msg "invalid sender MX"
> 
> 
> - sender MX client matching : the idea is to setup a poor man's SPF 
> check for domains who don't publish SPF records, and have the same 
> servers for inbound and outbound traffic (a quite common case): if a 
> mail from domain foo.bar comes from an IP which is listed as MX for 
> foo.bar, then we can quite trust it and skip greylisting. An example of 
> use :
> 
> 	racl whitelist mx match
> 
> 
> Of course above examples are only suggestions, the actual syntax may
differ.
> 
> -- 
> Ce message a ete verifie par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a ete trouve.
>

Attachments

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.