Mailing List Archive

Re: Updates on SRS crypto
On Fri, Feb 20, 2004 at 02:20:16PM -0600, Seth Goodman wrote:
> > [Brian Candler]
> > Well, I don't really care about that, see above.
>
> I care about that. Forged addresses are an excellent spam detector

Today maybe, but not for long if SPF is widely implemented.

> While SPF does not prevent spamming, it forces spammers
> to do so with their addresses exposed, which makes tracking and blacklisting
> more effective. Just as this will put ISP's feet to the fire with regard to
> risking their outgoing mail connectivity if they don't act aggressively, it
> also puts registrars feet to the fire in terms of who they register a domain
> for.

Not really. What about if the spammer has connectivity through "fooisp.net"?
She can send out mail with anything@fooisp.net as the return address. She
doesn't even have to use one of her own domains. All you have learned is
that they sent via fooisp.net, which is *exactly* the same information as
you would get by looking at their IP address. An IP blacklist approach will
continue to work if you want to hurt fooisp for harbouring spammers, and SPF
has gained you exactly nothing.

> > And unless SPF is implemented 100%, we will still have to deal with
> > the fallout from joe jobs.
>
> Not necessarily. You can choose how to deal with SPF softfail or SPF
> unknown yourself. At any point, you can decide to reject anything that does
> not give an explicit SPF pass. Your mailer, your rules.

Sure - you can have a policy which says "if you choose not to implement SPF,
then I choose not to talk to you". But to be useful, you are assuming that
SPF becomes the de-facto norm / best practice. I would argue that since SPF
adds complexity and breaks legitimate users for a small or negligible
long-term benefit, I think it's far from certain that the whole world will
share your view.

Of course, I risk my life by stating such views on a list composed of people
who are almost by definition pro-SPF :-)

> Assuming that you
> do the rejections before DATA, the senders will receive DSN's and will know
> exactly what happened. If they absolutely can't get SPF implemented on
> their domain, you can always whitelist them.

Yes that's true, as with any other aggressive policy which restricts your
E-mail connectivity.

Personally, I like E-mail to just work, and I have not joined in the
anti-spam arms race except for IP-based blacklists. More importantly for me,
even simple whitelists do not scale well to the ISP environment (notice that
pobox.com don't let users manage their own whitelists, for exactly this
reason).

Regards,

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
RE: Updates on SRS crypto [ In reply to ]
> [Brian Candler]
> On Fri, Feb 20, 2004 at 02:20:16PM -0600, Seth Goodman wrote:
> > > [Brian Candler]
> > > Well, I don't really care about that, see above.
> >
> > I care about that. Forged addresses are an excellent spam detector
>
> Today maybe, but not for long if SPF is widely implemented.

True, but you chopped off the more important part of the sentence. Here
is the full sentence:

"Forged addresses are an excellent spam detector,
but regardless of what it is, if it has a forged
envelope-sender address, I don't want it."

I have no desire to communicate with anyone who masquerades as someone
else. That's one reason I like SPF.


> Not really. What about if the spammer has connectivity
> through "fooisp.net"?
> She can send out mail with anything@fooisp.net as the return
> address. She
> doesn't even have to use one of her own domains. All you have
> learned is
> that they sent via fooisp.net, which is *exactly* the same
> information as
> you would get by looking at their IP address. An IP blacklist
> approach will
> continue to work if you want to hurt fooisp for harbouring
> spammers, and SPF
> has gained you exactly nothing.

I wouldn't say nothing. It saves me the trouble of parsing the headers
to figure out where the dang thing came from, depending on the SPF
result. I am guessing it could also save ISP abuse desk folks some
time, since if a message got an explicit SPF pass, it very likely came
from where it says it did. But that's more in your bailiwick than mine,
so what do you think?

> Sure - you can have a policy which says "if you choose not to
> implement SPF,
> then I choose not to talk to you". But to be useful, you are
> assuming that
> SPF becomes the de-facto norm / best practice. I would argue
> that since SPF
> adds complexity and breaks legitimate users for a small or negligible
> long-term benefit, I think it's far from certain that the
> whole world will
> share your view.

I can say with certainty the whole world doesn't share my view, but the
question really is, do enough people share that view to make it viable?
I don't know, but I'm betting that they do. I say that because I think
that stopping forgeries is a necessary, though not sufficient, step in
stopping spam. I may be foolish in believing that it's ultimately
possible, but that's my belief. It will take a lot of other steps, but
I believe this one is necessary for any practical solution.

>
> Of course, I risk my life by stating such views on a list
> composed of people
> who are almost by definition pro-SPF :-)

Your opinion has the same value as anyone else's here, as far as I'm
concerned. When that's no longer the case, I'm out of here.

> Personally, I like E-mail to just work, and I have not joined in the
> anti-spam arms race except for IP-based blacklists. More
> importantly for me,
> even simple whitelists do not scale well to the ISP
> environment (notice that
> pobox.com don't let users manage their own whitelists, for
> exactly this
> reason).

I can't argue with your experience here as I have none in that
environment. Maybe someone else with ISP experience can comment on
this.

I do see per-user whitelists as practical (and even necessary) for a
moderate-sized commercial enterprise with hundreds of users per site.
The nature of the user is different, as well. For a business network,
keeping spam out without lots of user time wasted is more than a nicety.
Time spent perusing filtered spam folders for false positives, or
dealing with false negatives, lowers productivity. That makes it more
likely that our competitors will eat our lunch or our jobs will migrate
to a different continent. Many ISP's think they have solved the spam
problem by filtering. That may be true for the residential user, but
for my needs, going through an overstuffed spam folder every day is not
a reasonable use of my time. While I also would like email to just
work, the spam problem has derailed that, for the time being. To make
email practical for business use, you need to do a lot more than just IP
blacklists, and engineering those recipes costs real money which could
be better spent elsewhere. I think of SPF as a tool that will start to
lower the cost of ownership of a spam-free inbox. To me, joe-job
prevention alone is worth the price of admission.

--

Seth Goodman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
Re: Updates on SRS crypto [ In reply to ]
On Sat, Feb 21, 2004 at 07:13:32PM -0600, Seth Goodman wrote:
> True, but you chopped off the more important part of the sentence. Here
> is the full sentence:
>
> "Forged addresses are an excellent spam detector,
> but regardless of what it is, if it has a forged
> envelope-sender address, I don't want it."
>
> I have no desire to communicate with anyone who masquerades as someone
> else. That's one reason I like SPF.

Yes but in general you are talking about spammers. If/when SPF is widely
implemented, they will simply forge their envelope sender in a way which is
not detectable by SPF:

- they will use randomuser@theirisp.net
- they will use randomuser@some-domain-they-own.com
- they will use null envelope sender (like a bounce)

I predict you will get no fewer E-mails from forged or undesirable
addresses, but they will all pass SPF. So why did we bother?

> > All you have
> > learned is
> > that they sent via fooisp.net, which is *exactly* the same
> > information as
> > you would get by looking at their IP address. An IP blacklist
> > approach will
> > continue to work if you want to hurt fooisp for harbouring
> > spammers, and SPF
> > has gained you exactly nothing.
>
> I wouldn't say nothing. It saves me the trouble of parsing the headers
> to figure out where the dang thing came from, depending on the SPF
> result. I am guessing it could also save ISP abuse desk folks some
> time, since if a message got an explicit SPF pass, it very likely came
> from where it says it did. But that's more in your bailiwick than mine,
> so what do you think?

Abuse desks *have* to work from IP address information. If the address was
randomuser@myisp.com, I cannot blame this on randomuser, because the
local-part is probably forged. So I still have to parse the headers to find
the IP address.

Will it reduce misdirected spam complaints which my ISP has to deal with, if
the rest of the world implements SPF? I doubt it. It still relies on users
looking at the Return-Path: header, which they rarely see. Automated tools
for reporting know how to read the rest of the headers properly anyway.

SPF does not address From: header forgery, which I believe is a bigger
problem.

> I do see per-user whitelists as practical (and even necessary) for a
> moderate-sized commercial enterprise with hundreds of users per site.
...
> Time spent perusing filtered spam folders for false positives, or
> dealing with false negatives, lowers productivity.

Hear hear. But if your anti-spam filtering is so stringent that legitimate
users must be whitelisted to communicate with you (and they then must
contact you via some other mechanism, e.g. phone, and get to you configure
their address manually) then that's a waste of time too.

I have heard it said many times that the vast majority of spam comes from
just a few hundred professional spammers, and I believe that is true. Until
recently my pobox.com account was completely unfiltered (too many false
positives from pobox's content-based filtering system), and I was getting
200+ spams per day. Having now enabled their IP-RBL based system, this is
down to perhaps a few tens, of which quite a few are viruses and joe-job
bounces. So cutting off the spammers' netblocks and the open relays/proxies
they abuse is a pretty effective solution.

Admittedly I have configured pobox to block all mail from Korea and Taiwan
(but not Nigeria, as I have connections with African networking groups)

> Many ISP's think they have solved the spam
> problem by filtering. That may be true for the residential user, but
> for my needs, going through an overstuffed spam folder every day is not
> a reasonable use of my time.

Hear hear to that too. That is why I will not use any spam filtering system
which does not simply *bounce* the mail back. IP RBLs are great for that,
because you can 550 them at RCPT TO time; if it's a legitimate mail the user
will know and can take action, and if it's a spam then we don't care.

This is one reason it's very, very important that we don't break bounces in
the rush to implement schemes such as SPF. Silent deletion of E-mails tagged
as spam is evil.

> I think of SPF as a tool that will start to
> lower the cost of ownership of a spam-free inbox. To me, joe-job
> prevention alone is worth the price of admission.

OK, but at the risk of repeating myself, I don't think you'll get fewer
joe-job bounces until the whole internet implements SPF; SPF requires SRS
for forwarding to work; but SRS *by itself* solves the joe-job problem
quickly and easily. So if that's the main reason you want SPF, there are
better solutions.

Regards.

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
Re: Updates on SRS crypto [ In reply to ]
On Fri, Feb 20, 2004 at 04:52:28PM -0600, Dustin D. Trammell wrote:
> mw-list-spf-discuss-VLgz+x3aYQ8@public.gmane.org wrote:
> > Under qmail, the local delivery agent is qmail-local. It is the one
> > handling aliases (.qmail aka .forward files). It is run as the user
> > whose email it delivers. How is it going to see the server's secret?
>
> I'm not developing a qmail SRS implementation, but I do use qmail, so
> perhaps I can try to shed some light on this. From what I understand of
> SRS, I would think that it would be handled somewhere around
> qmail-queue, not qmail-local.

qmail-queue has no idea if the message is remote or not; it is
qmail-send which decides if the message is remote or local. I guess
making the secret file readable to the qmails user only (qmail-send is
run as qmails), one could modify qmail-send to do srs. In fact, it
seems the only way to handle srs would be by qmail-send, since
qmail-send prepends every message to a virtualdomain by a
string---destroying srs bounces that are supposed to start with the
string SRS.

Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html