Mailing List Archive

On Fri, Jul 15, 2005 at 10:46:10PM -0500, Damian Menscher wrote:
> A bit OT, but SPF seems doomed to failure.

Quite right. More importantly, as an anti-spam measure it is also doomed to
failure, even if the whole world adopted SPF. That's because SPF policy is
public; it's trivial for spammers to select sender addresses which pass SPF
policy for the machine they're sending from or relaying via, simply by
pre-filtering their existing lists of E-mail addresses against SPF.

> I'm curious what the advantages to SRS are,
> considering that SPF can't possibly work.

You can use SRS by itself, to sign all your outgoing mail - then you can
reject bounces to messages which were not sent by you in the first place.
This protects you against 'joe jobs'. If you do this, then anyone who does
SMTP callback verification of senders will be able to show whether your
address is being spoofed or not - solving the same problem as SPF was
supposed to solve, but much more simply, and without the nasty side-effects.

There are other similar proposals in the pipeline, e.g. BATV, SES.

Brian.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Fri, 2005-07-15 at 22:46 -0500, Damian Menscher wrote:
> Also, I'm curious how this works with greylisting. Does SRS update the
> timestamp for each delivery attempt, or only for each message?

That's implementation-dependent. Mine did it on each attempt, which is
why I had to take the more precise timestamps out of the debugging info
in the domain part of the generated address.

Mine's only really used for BATV/SES, because my 'spf-afflicted-domains'
list has remained basically empty -- but the principle is the same.

> If it updates for each delivery attempt, that would cause the same
> message to be greylisted twice if it happened to be sent shortly
> before the midnight hour (which might be business hours, if unix_time
> is in GMT and your business is elsewhere).

That's possible, yes. But relatively unlikely and the 'failure mode' is
only a slightly longer delay than greylisting would normally cause.

> Even if it only updates the timestamp once, this will still cause
> daily greylisting slowdowns, but I guess that can't be avoided.

Only if the greylister's 'whitelist' is by sender address, which would
be silly. The point about greylisting is that you suspect that the
sending host might be a spambot and not a real mail host. If the _host_
is one that is known to queue and retry, there's really no point in
greylisting mail from it.

You use the sender and recipient addresses in order to _detect_ the a
given mail is the same as the one you were offered five minutes ago,
purely as an implementation detail -- but when it comes to whitelisting
certain senders which you now think are genuine, it doesn't make much
sense to keep using the sender address -- you might as well do your
whitelist by the IP address of the sending host instead.

Consider these cases...

Firstly... you are offered a mail from user@domain1.org from a certain
mail host. You greylist, and a few minutes later the same host offers
the same mail again. It's accepted.

The next day, you are offered a mail from user@domain2.org from the
_same_ mail host as before. Do you gain anything by greylisting? What
are the odds that you'll just cause a delay to valid mail, vs. the odds
of actually preventing a spambot from injecting its mail?

The next day you are also offered a mail from user@domain1.org from some
_other_ host. Do you gain anything by greylisting it _this_ time? Again,
what are the odds?

--
dwmw2


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Le Samedi 16 Juillet 2005 10:03, David Woodhouse a écrit :
>
> Consider these cases...
>
> Firstly... you are offered a mail from user@domain1.org from a certain
> mail host. You greylist, and a few minutes later the same host offers
> the same mail again. It's accepted.
>
> The next day, you are offered a mail from user@domain2.org from the
> _same_ mail host as before. Do you gain anything by greylisting?

You're not sure that you receive it from the same _host_. You receive it from
the same _IP_.

This IP can host a legit enterprise email server, and a whole LAN natted on
the same IP thru its gateway, with tons of zombie/virussed Windows machines
that send direct-to-MX crap.

So yes, you definitely gain in keeping greylisting this IP for mails that
would come from a different domain as the usual legitimate domain(s) that get
out of the legit server...

--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Sat, 2005-07-16 at 10:39 +0200, Michel Bouissou wrote:
> You're not sure that you receive it from the same _host_. You receive it from
> the same _IP_.
>
> This IP can host a legit enterprise email server, and a whole LAN natted on
> the same IP thru its gateway, with tons of zombie/virussed Windows machines
> that send direct-to-MX crap.

This is true, although thankfully it'll sometimes be the case that there
will be a firewall preventing them from directly accessing the outside
world if they choose to do so instead of using their local mail server.

I should look into using the HELO greeting in addition to the name for
whitelisting. That should catch a reasonable proportion of such cases,
and also of cases where dynamic IP addresses are reassigned.

> So yes, you definitely gain in keeping greylisting this IP for mails that
> would come from a different domain as the usual legitimate domain(s) that get
> out of the legit server...

Potentially, yes. It depends how much you care about delaying genuine
mail.

You could also argue that you gain in keeping greylisting for _all_
mail, and never whitelisting at all. After all, that army of zombie
Windows machines of which you speak may be sending mail with the same
HELO and MAIL FROM as the enterprise email server does. So you could
benefit by delaying _every_ valid mail you ever receive.

The only _real_ solution in the situation you give (other than that they
stop exposing using Windows machines connected to the Internet) is to
use one of the crypto-based techniques such as BATV/SES/DKIM so that the
zombies _can't_ create their fakes.

As you rightly point out, the IP address alone isn't enough -- although
it's not _such_ a bad heuristic for greylisting purposes.

--
dwmw2


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Jewelry Displays www.terrificitems.com






-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Jewelry Displays www.terrificitems.com






-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com