Mandag den 19. april 2004 19:28 skrev Seth Goodman:
- Being able to e-mail with friends. SPF and Autowhitelisting in
spamassassin makes this easy.
This is all post-SMTP.
I will only be deploying SPF filtering post-SMTP for a start, that's
correct.
Since most domains haven't adopted SPF, yet, there's not much savings
in deploying SPF at the SMTP transaction level, yet - but as SPF
catches on, SPF at the SMTP port will become more important. But
here, you still have to analyze the different kinds of e-mails:
- E-mail addresses can be whitelisted using SPF right now.
- As SPF usage increases, a larger part of the current spam/virus
e-mail types can be rejected using SPF.
- Some spam/virus can be rejected based on blacklists/SPF.
You can never kill all spam at the SMTP level, because people define
"spam" differently. You can, however, reduce the number of e-mails
going into the system, and thereby reduce the load on spamassassin or
other tools (like the bayesian filters in Outlook, POPfile, Mozilla
etc.).
Doing SPF checks after accepting the whole message is better than
not doing them at all, but it throws away two very important
benefits: reducing the load on the MTA and reducing the number of
forgeries passed on to the user.
It does not reduce the number of forgeries if you set up your
mailsystem right. Doing an SPF check before or after receiving the
message body can give exactly the same result.
From the MTA's standpoint, once you accept a message, you have to
deliver it or send a DSN.
The complete mailsystem doesn't have to do that. Many e-mail systems
are silently removing worms and spam today, if not most e-mail
systems.
By the way - who says that spamassassin and the MTA cannot cooperate,
making spamassassin provide an autoblacklist/autowhitelist to the
MTA? Remember, that SPF is still in its infancy, and that many
mechanisms will be built on top of SPF.
It was meant to bring some level of
accountability to email senders and thus make it harder for
spammers to make a living.
Interesting - I didn't know that anyone cared about spammer's living
standards. Personally, I just care about bandwidth usage, server load
and amount of spam e-mails floating around in my systems :-)
appreciate the fact that you don't think SES should be discussed on
this list, but it is really a discussion of flaws in SPF+SRS and a
search for possible solutions.
I don't see the flaw? I normally define flaws/errors as something,
that does not behave according to the specification. Please give
details about, what in SPF+SRS that doesn't behave according to how
it was intended to behave, or please define "flaw".
Well, a lot of people do see SRS as extreme and it is probably the
single biggest impediment to widespread SPF adoption.
Not many people are forwarding e-mails. Most ISPs deliver a mailbox,
which is emptied using POP3. Most e-mail clients can empty multiple
mailboxes today, and frankly, I don't know anybody besides myself,
who has a forward on an e-mail that they can't handle this way.
Then there are e-mail lists, but:
- Most people aren't on an e-mail list... yes, that's true!
- For a start, most SPF checkers will probably be the one in
spamassassin, which will not junk e-mails with incorrect SPF records,
but only uses it as another check for spam points
- Most e-mail lists are based on providers, who have the knowledge to
implement SRS, or are run by nerds, who also have the knowledge to
put in SRS when asked to do so by the list members
Did you know, that Active Spam Killer kills spam just by whitelisting
sender e-mail addresses? It assumes, that the spammers cannot figure
out, which people I have whitelisted. E-mails from other people using
the same domain name are handled using cookies inside the e-mails.
And it works, which might seem very impressive to some people. This
method can also be used to whitelist mailing lists for a start.
Frankly, I don't need SRS for my own personal mail. I can benefit very
much from SPF without anyone implementing SRS, and later, when SPF
adoption has grown, and it makes sense to use pre-SMTP SPF filtering
to save bandwidth and load, SRS will be widespread, too. SRS is not a
roadblock; consider it to be the small plastic cap you put on the
screws in your furniture to make things look nicer (in case you ever
bought something from IKEA).
In fact, the SPF model depends on
_every_ MTA in the message path to do an SPF check on the incoming
message.
I'm not sure what SPF model you mean, but most forwarding system that
I've seen, are like this:
- One or more e-mail servers are MX for a domain
- They all forward to an Exchange server or something like that inside
in a company
- The exchange server is firewalled so that it can only receive
e-mails from those outside e-mail servers
There is no reason to make the Exchange server check anything, since
it only receives e-mail that was already checked by the servers
outside on the internet.
An SPF fail result says that the
message source does not meet the domain owners published policy for
designated senders for their domain.
Which means that:
- The owner has an incorrect SPF record or
- The owner forgot about his SPF record or
- The from-address is forged
And it's not always a good solution to wait until the owner got a
bounce back and then resends the e-mail. SPF is nice, but if it
breaks the flow of important e-mails in a critical situation, the
boss gets very angry. Therefore, a fail should not mean total
rejected at this early stage of SPF adoption - otherwise a lot of
bosses can get very angry. That's one of the reasons why I see
spamassassin to be one of the most important tools for SPF adoption -
if an e-mail fails, there is more than one reason, and the boss won't
demand removal of that SPF filter thingy. Later, when SPF adoption is
much better, more people will start to block on SPF fails.
You probably won't see Meng say something like I said here, because he
must tell people how the ideal SPF world looks like, so that they
understand the principles, but reality is, that SPF won't conquer the
world by june 2004.
That's certainly what this is all about. Part of the notion of
"email working well" is receiving fewer forgeries in your inbox.
Huh? Personally I don't care if an e-mail contains a forgery in sender
e-mail address, as long as I want to read that e-mail. SPF doesn't
change that, since a forgery is as simple as borrowing another
person's computer. I think we agree, that you mean "fewer unwanted
e-mails", but be careful about your choice of words if you want to
apply deduction to your statements :-)
Another part of it is keeping the cost of email services down.
While the end user may have no interest in how these are
accomplished, they are necessary to keep the end users satisfied.
I totally agree. The largest e-mail server I administrate, receives
approximately 100,000-500,000 e-mails a day (most are not spam), and
we can't enable all spamassassin checks, because that would overload
the server. But as long as I cannot squeeze 5-10% extra performance
out of the server by putting SPF filtering into the SMTP session,
it's not worth spending time on it. It would be much easier to put an
extra CPU into the machine - at least I would then know for sure, how
much downtime the server would have during the operation ;-)
Lars.
--
Mobil: 20331241
Evt.: 70201241
Fax.: 70201242