Milter-greylist

Hello people,

I've just built and installed milter-greylist, and I have a few
ideas/troubles:

1.
Submissions that pass SPF check are not greylisted.  I think that this
is wrong.  Being SPF-clean does not guarantee that the message is not
spam.  There where even reports in press that there was more SPF-clean
spam mesaured than SPF-clen valid mail.  What SPF does guarantee is
that sender domain was not spoofed.

I think that better approach would be to greylist such messages, but
instead of (sender-IP sender-address recipient-address) tuple use
(sender-domain sender-address recipient-address) or maybe rather
(sender-domain recipient-address).

Maybe there could be also a config option to block (with 5xx)
submissions if SPF check returns 'fail' or 'softwail'.

2.
I find it very a compelling idea to have dynamic greylisting delay,
per sender IP (or sender domain for SPF-verified submissions), growing
if there are many submissioons for non-existent users from the IP.
This would be kinda simple reputation system.

3.
Now and then, I get this pair of messages in the log:

Dec  9 00:19:28 auhost sm-mta[14836]: iB8LJHFq014836: Milter
(milter-greylist):
timeout before data read
Dec  9 00:19:28 auhost sm-mta[14836]: iB8LJHFq014836: Milter
(milter-greylist):
to error state

(and sendmail returns "451 4.3.2 Please try again later" because I
configured the filter as "F=T").

Also, from time to time, there is a message:

Dec  9 00:41:07 auhost milter-greylist: smfi_getsymval failed for
{if_addr}

in the log.

Any comments?

Regards
Eugene

egcrosser <egcrosser@...> wrote:

> 1.
> Submissions that pass SPF check are not greylisted.  I think that this
> is wrong.  Being SPF-clean does not guarantee that the message is not
> spam.  There where even reports in press that there was more SPF-clean
> spam mesaured than SPF-clen valid mail.  What SPF does guarantee is
> that sender domain was not spoofed.
> 
> I think that better approach would be to greylist such messages, but
> instead of (sender-IP sender-address recipient-address) tuple use
> (sender-domain sender-address recipient-address) or maybe rather
> (sender-domain recipient-address).

Well, you don't really win anything. IMO spammers using SPF compliant
servers are not such a problem: they have a real server, so their spam
will get through. Our usage of SPF just means it passes through
immediatly instead of delayed. I don't see any change to that in your
proposal.

Spammers with real mail servers belong to the black list, IMO. Whether
they use SPF or not does not change much of the problem.
 
> I find it very a compelling idea to have dynamic greylisting delay,
> per sender IP (or sender domain for SPF-verified submissions), growing
> if there are many submissioons for non-existent users from the IP.
> This would be kinda simple reputation system.

That's an interesting idea. Don't you fear you could give higer and
higher scores to ISP mail servers? Those are regularly used to realy
spam by their own customers. Usually this is punished as soon as you
send an abuse, but another customer will do it again soon. 
 
> 3.
> Now and then, I get this pair of messages in the log:
> 
> Dec  9 00:19:28 auhost sm-mta[14836]: iB8LJHFq014836: Milter
> (milter-greylist):
> timeout before data read
> Dec  9 00:19:28 auhost sm-mta[14836]: iB8LJHFq014836: Milter
> (milter-greylist):
> to error state
> 
> (and sendmail returns "451 4.3.2 Please try again later" because I
> configured the filter as "F=T").

milter-greylist timed out answering. If you use SPF, that's probably the
DNS request that caused it. Raise the timeout delay in sendmail.cf
 
> Also, from time to time, there is a message:
> 
> Dec  9 00:41:07 auhost milter-greylist: smfi_getsymval failed for
> {if_addr}
> 
> in the log.
> 
> Any comments?

Mail comming from localhost?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

--- In milter-greylist@yahoogroups.com, manu@n... wrote:
> egcrosser <egcrosser@y...> wrote:
> 
> > 1.
> > Submissions that pass SPF check are not greylisted.  I think that
this
> > is wrong.  Being SPF-clean does not guarantee that the message is
not
> > spam.  There where even reports in press that there was more
SPF-clean
> > spam mesaured than SPF-clen valid mail.  What SPF does guarantee
is
> > that sender domain was not spoofed.
> > 
> > I think that better approach would be to greylist such messages,
but
> > instead of (sender-IP sender-address recipient-address) tuple use
> > (sender-domain sender-address recipient-address) or maybe rather
> > (sender-domain recipient-address).
> 
> Well, you don't really win anything. IMO spammers using SPF
compliant
> servers are not such a problem: they have a real server, so their
spam
> will get through.

I'm afraid that's not really the case.  What a spammer can do is
register a (number of) throwaway domain(s) and publish SPF record of
the kind "v=spf1 +all".  Then command his zombie army to use MAIL
FROM:<...@...>.

I agree that (such) bad domains belong to blacklists.  But the trouble
with blacklists (both IP and domain) is that they always lag behind. 
Greylisting come into play right here: it can minimize the harm done
in the window between creation of domain and putting it into
blacklist.

> Our usage of SPF just means it passes through
> immediatly instead of delayed. I don't see any change to that in
your
> proposal.
> 
> Spammers with real mail servers belong to the black list, IMO.
Whether
> they use SPF or not does not change much of the problem.

Really so.  Still the problem with the current approach is that it in
fact gives spammers a "fast track" around the greylist! (as described
above)

> > I find it very a compelling idea to have dynamic greylisting
delay,
> > per sender IP (or sender domain for SPF-verified submissions),
growing
> > if there are many submissioons for non-existent users from the IP.
> > This would be kinda simple reputation system.
> 
> That's an interesting idea. Don't you fear you could give higer and
> higher scores to ISP mail servers?

Possibly the delay can automatically drop down to default value once
"bad behavior" stops?

> > Dec  9 00:19:28 auhost sm-mta[14836]: iB8LJHFq014836: Milter
> > (milter-greylist):
> > timeout before data read

> milter-greylist timed out answering. If you use SPF, that's
probably the
> DNS request that caused it. Raise the timeout delay in sendmail.cf

Ah, thanks.

> > Also, from time to time, there is a message:
> > 
> > Dec  9 00:41:07 auhost milter-greylist: smfi_getsymval failed for
> > {if_addr}
> > 
> > in the log.
> > 
> > Any comments?
> 
> Mail comming from localhost?

Quite possible.  I see "address 127.0.0.1 is in exception list" in the
same second.  The message is alarming, though :-)  (and it also lacks
the ID tag btw).

Thanks
Eugene

egcrosser <egcrosser@...> wrote:

[SPF]
> I'm afraid that's not really the case.  What a spammer can do is
> register a (number of) throwaway domain(s) and publish SPF record of
> the kind "v=spf1 +all".  Then command his zombie army to use MAIL
> FROM:<...@...>.

Well, if that happens, I assume SPF has no point, then. 
I just see a minor point: buying a domain costs money, and if I recall
correctly, the registar must hold the real identity of the domain owner.
 
> Really so.  Still the problem with the current approach is that it in
> fact gives spammers a "fast track" around the greylist! (as described
> above)

But do you get spam with this scenario?
 

[Dynamic greylisting delay, getting higher and higher for bad guys] 
> > That's an interesting idea. Don't you fear you could give higer and
> > higher scores to ISP mail servers? 
> Possibly the delay can automatically drop down to default value once
> "bad behavior" stops?

Could you post a more detailed plan of the way you think this should be
handled? The idea of a reputation system sounds appealing to me, but I
don't see how you would increase or decrease the delays exactly.
 
> > Mail comming from localhost? 
> Quite possible.  I see "address 127.0.0.1 is in exception list" in the
> same second.  The message is alarming, though :-)  (and it also lacks
> the ID tag btw).

The one should be easy to fix. Mail from localhost never set ${if_addr}

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

--- In milter-greylist@yahoogroups.com, manu@n... wrote:
> egcrosser <egcrosser@y...> wrote:
> 
> [SPF]
> > I'm afraid that's not really the case.  What a spammer can do is
> > register a (number of) throwaway domain(s) and publish SPF record
of
> > the kind "v=spf1 +all".  Then command his zombie army to use MAIL
> > FROM:<...@...>.
> 
> Well, if that happens, I assume SPF has no point, then. 
> I just see a minor point: buying a domain costs money, and if I
recall
> correctly, the registar must hold the real identity of the domain
owner.

SPF indeed has less point than it is generally perceived.  What it
does allow is building reputation/certification systems based on
domain names instead of IP addresses.  Which is generally a good
thing.  The "proper" approach to SPF deployment is:

1. block mail that gets SPF "fail".
2. if SPF "pass", collect/check reputation based on domain
3. otherwise, collect/check reputation based on IP address

An easy (imperfect) way to check domain reputation is to run WHOIS
query and see how old it is.

> > Really so.  Still the problem with the current approach is that
it in
> > fact gives spammers a "fast track" around the greylist! (as
described
> > above)
> 
> But do you get spam with this scenario?

Currently no (I think), but it is just because SPF is not deployed
wide enough for spammers to notice.

> [Dynamic greylisting delay, getting higher and higher for bad guys] 
> > > That's an interesting idea. Don't you fear you could give higer
and
> > > higher scores to ISP mail servers? 
> > Possibly the delay can automatically drop down to default value
once
> > "bad behavior" stops?
> 
> Could you post a more detailed plan of the way you think this
should be
> handled? The idea of a reputation system sounds appealing to me,
but I
> don't see how you would increase or decrease the delays exactly.

Have this table:
+--------------------+-----------+--------+
| IP or SPF verified | "Badness" | Last   |
| domain             | index     | update |
+--------------------+-----------+--------+

On incoming mail to non-existent user (or other indication of "bad"
behavior, e.g. DCC positive), increase badness index by
constant_coefficient/(time_now-last_update+1), and set last_update to
current time.  Or maybe just increase it by a constant.

On "good" incoming mail (e.g. that would cause autowhitelisting) reset
badness index to zero.  And set last_update to current time.

On any incoming mail, set
new_delay=default_delay+another_coefficient*(badne
ss_index/(time_now-last_update+1))

Formulae may be more sophisticated, such as logarithmic or
exponential, but you get the idea.

Eugene

This seems not particularly useful to me.  We get very little mail
addressed to non-existent users.  Furthermore, any mail addressed to
non-existent users is already rejected by sendmail anyway,
so I don't see the need for greylisting to deal with it.
A complete reject is preferable to greylisting in this case.
Is there something here I don't understand?

It's not clear to me that tweaking the delay will have that much
of an effect.  If one is going to the trouble of resending mail,
the easiest solution is to be fully compliant, so the mail would
eventually be delivered anyway.  I don't know what spammers are
currently doing in this regard, however, so that's just speculation.

Gary

>  > Could you post a more detailed plan of the way you think this
> should be
>  > handled? The idea of a reputation system sounds appealing to me,
> but I
>  > don't see how you would increase or decrease the delays exactly.
> 
> Have this table:
> +--------------------+-----------+--------+
> | IP or SPF verified | "Badness" | Last   |
> | domain             | index     | update |
> +--------------------+-----------+--------+
> 
> On incoming mail to non-existent user (or other indication of "bad"
> behavior, e.g. DCC positive), increase badness index by
> constant_coefficient/(time_now-last_update+1), and set last_update to
> current time.  Or maybe just increase it by a constant.
> 
> On "good" incoming mail (e.g. that would cause autowhitelisting) reset
> badness index to zero.  And set last_update to current time.
> 
> On any incoming mail, set
> new_delay=default_delay+another_coefficient*(badne
> ss_index/(time_now-last_update+1))
> 
> Formulae may be more sophisticated, such as logarithmic or
> exponential, but you get the idea.

egcrosser <egcrosser@...> wrote:

> On incoming mail to non-existent user (or other indication of "bad"
> behavior, e.g. DCC positive), increase badness index by
> constant_coefficient/(time_now-last_update+1), and set last_update to
> current time.  Or maybe just increase it by a constant.

milter-greylist does not know what addresses are valid, or about DCC.
How do you plan to address that problem?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

--- In milter-greylist@yahoogroups.com, manu@n... wrote:

> > On incoming mail to non-existent user (or other indication of
"bad"
> > behavior, e.g. DCC positive), increase badness index by
> > constant_coefficient/(time_now-last_update+1), and set
last_update to
> > current time.  Or maybe just increase it by a constant.
> 
> milter-greylist does not know what addresses are valid, or about
DCC.
> How do you plan to address that problem?

I have no real-life experience with milter interface, but maybe
xxfi_abort() vs. xxfi_eom() could be used to tell nondeliverable
messages from deliverable?

About DCC, I only mentioned it as a theoretic possability, if somebody
would try to combine greylisting with other antispam technologies (the
way to go, IMHO).

Eugene

Gary Aitken <greylist@...> wrote:

> This seems not particularly useful to me.  We get very little mail
> addressed to non-existent users. 

Lucky you.

> Furthermore, any mail addressed to
> non-existent users is already rejected by sendmail anyway,
> so I don't see the need for greylisting to deal with it.
> A complete reject is preferable to greylisting in this case.
> Is there something here I don't understand?

The idea is to keep track of systems reputations: a system that sends
many broken mails will be delayer for longer, possible raising the delay
enough so that the mail is never accepted.

The idea has some benefits to temporatily (on a day basis) refuse
messages from real MTA used as relays by spammers, but there are issues
that need to be addressed:

- how milter-greylist could know about invalid addresses?
- couldn't we have more ham reject than spam reject with that method?

The first problem can be addressed by honeypots, but in fact it can be
fully jandled outside of milter-greylist. See ftp://ftp.espci.fr/pub/dst
for a real-time distributed spamtrap network. It works with any MTA.

I never pushed it very hard because for now greylisting is enough. DST
will also cause me to blacklist ISP MTA used as relays by spammers. If
someone has an idea on how to handle that...

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

egcrosser <egcrosser@...> wrote:

> I have no real-life experience with milter interface, but maybe
> xxfi_abort() vs. xxfi_eom() could be used to tell nondeliverable
> messages from deliverable?

You might discover that a message was not deliverable (ie: you hit the
rcpt stage but not the body stage), but you won't know is it's because
the recipient does not exist or if the sender stopped there (for a
callback mecanism, for instance).

Moreover, if the message has mulitple recipients (a common thing for
spam), you won't notice some recipient were dropped. 

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

--- In milter-greylist@yahoogroups.com, manu@n... wrote:

> > I have no real-life experience with milter interface, but maybe
> > xxfi_abort() vs. xxfi_eom() could be used to tell nondeliverable
> > messages from deliverable?
> 
> You might discover that a message was not deliverable (ie: you hit the
> rcpt stage but not the body stage), but you won't know is it's because
> the recipient does not exist or if the sender stopped there (for a
> callback mecanism, for instance).
> 
> Moreover, if the message has mulitple recipients (a common thing for
> spam), you won't notice some recipient were dropped. 

Ah, yes, I see...  Maybe milter interface should have had another set
of callback points, where MTA could tell the filter what it is going
to reply to the peer.

Anyway, as this information is used to update peer rating rather than
to make firm decisions, I think this approach still *can* be used: if
the remote regularily tries to send messages that MTA find completely
unacceptable, this is a hint that it may be wrong-doing.

Eugene

On Sat, 11 Dec 2004 10:19:12 +0100
manu@... wrote:

MO> 
MO> egcrosser <egcrosser@...> wrote:
MO> 
MO> > I have no real-life experience with milter interface, but maybe
MO> > xxfi_abort() vs. xxfi_eom() could be used to tell nondeliverable
MO> > messages from deliverable?
MO> 
MO> You might discover that a message was not deliverable (ie: you hit
MO> the rcpt stage but not the body stage), but you won't know is it's
MO> because the recipient does not exist or if the sender stopped there
MO> (for a callback mecanism, for instance).
MO> 
MO> Moreover, if the message has mulitple recipients (a common thing for
MO> spam), you won't notice some recipient were dropped. 

I have a rule in my sendmail.cf to control the number of recipients
tried in each connection, and with this I can control a per IP or
authenticated user maximum number of recipients. This thing can be used
to detect how many recipients was refused, If the counter has X and
milter received Y calls to rcpt the number of refused recipients will be
(X - Y).


--

egcrosser <egcrosser@...> wrote:

> Anyway, as this information is used to update peer rating rather than
> to make firm decisions, I think this approach still *can* be used: if
> the remote regularily tries to send messages that MTA find completely
> unacceptable, this is a hint that it may be wrong-doing.

In my opinion the easiest way to catch spammer is to use honeypot
addresses. Publish such an address in an HTML comment on your website,
and you'll get spam in it within 3 days.

So you can discover which IP sends you spam. With DST
(ftp://ftp.espci.fr/pub/dst), you can exchange this information with
other sites in real time, and you can feed a DNSRBL with it. For now the
DNSRBL only gets the IP, but we can immagine storing the number of bad
mails or other informations.

Once you have the info in the DNSRBL, then we can start thinking about
funny applications. The information is easy to access. Your idea would
be to increase the greylist delay? But the spam will always finnally hit
your machine, won't it?
 
-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

manu@... wrote:

> The first problem can be addressed by honeypots, but in fact it can be
> fully jandled outside of milter-greylist. See ftp://ftp.espci.fr/pub/dst
> for a real-time distributed spamtrap network. It works with any MTA.

Hmmm, when I look at that and do an "ls" I get
   "Can't build data connection: Operation timed out
Do I need more info to go deeper or determine what to look at?



Gary

Gary Aitken <greylist@...> wrote:

> > The first problem can be addressed by honeypots, but in fact it can be
> > fully jandled outside of milter-greylist. See ftp://ftp.espci.fr/pub/dst
> > for a real-time distributed spamtrap network. It works with any MTA.
> 
> Hmmm, when I look at that and do an "ls" I get
>    "Can't build data connection: Operation timed out
> Do I need more info to go deeper or determine what to look at?

Try http://ftp.espci.fr/pub/dst 

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

On Wed, Dec 08, 2004 at 10:37:43PM -0000, egcrosser wrote:
> 2.
> I find it very a compelling idea to have dynamic greylisting delay,
> per sender IP (or sender domain for SPF-verified submissions), growing
> if there are many submissioons for non-existent users from the IP.
> This would be kinda simple reputation system.

The basic problem with that idea is that you will only hurt real mail
servers with this scheme. My e-mail server has received over 1400 mails
to non existing addresses in the last 18 hours. As far as I can see there
is not a single spam e-mail between those. All those message are bounces
caused by spammers. By rejecting the mail server trying to deliver that
bounce you will only make that class of problems worse.

I'm sorry but your idea is broken by design.

	Kind regards

-- 
Matthias Scheler                                  http://scheler.de/~matthias/

I disagree, I think...

1.  Presumably, a reputation system would be tunable by the sysadmin
for the site where it is being applied.  In your case, you could tune
it by turning off totally any reputation aspect attributable to the
source sending email to non-existent user ids.

2.  The fact that a source is sending a high volume of email to
non-existing users means that source is pretty unreliable in terms
of its ability to police its users, and therefore control its spam
output.  As stated earlier, one intent of the reputation system is
to encourage sources to police their systems better.  One could
presumably use a high bounced mail reputation to inform the senders
of valid mail from that system, and the postmaster, that their mail
is being purposefully delayed because of the high spam output.  This
would encourage users to seek other providers, and the postmaster
to do a better policing job.  All of this could be done automatically,
obviously.  It's true that a provider could block mail informing
their users of this fact, although low-volume mail to specific
users might well get through.

Gary

Matthias Scheler wrote:

> On Wed, Dec 08, 2004 at 10:37:43PM -0000, egcrosser wrote:
>  > 2.
>  > I find it very a compelling idea to have dynamic greylisting delay,
>  > per sender IP (or sender domain for SPF-verified submissions), growing
>  > if there are many submissioons for non-existent users from the IP.
>  > This would be kinda simple reputation system.
> 
> The basic problem with that idea is that you will only hurt real mail
> servers with this scheme. My e-mail server has received over 1400 mails
> to non existing addresses in the last 18 hours. As far as I can see there
> is not a single spam e-mail between those. All those message are bounces
> caused by spammers. By rejecting the mail server trying to deliver that
> bounce you will only make that class of problems worse.
> 
> I'm sorry but your idea is broken by design.