LWN: Comments on "Debian rejects Sender ID"

Why no network of trust?

forthy — 2004-09-07T14:53:15+00:00

It is not obvious for me that you can't add a network of trust to a
SPF-like framework. Like S/MIME or PGP, SPF records would need a signature
(or several signatures, if you like). If you create your domain, the NIC
usually would also sign your SPF record; done. Since domain creation is a
hierarchical situation, tracing signatures back to some known good "root"
signature is not really difficult.

In the end, this does not help bot-based spam networks and worm floods.
Even if you require the user to enter a passphrase for every outgoing
mail, an infected PC could grab that passphrase and send spam and worms
under the name of the victim. However: It is now possible to help the
victim, since you can identify her (or him). Part of the success of
captured computers is that the user doesn't know about it.

That much trouble?

arafel — 2004-09-07T12:19:15+00:00

>Argh. Of course receiving servers do not need to verify PGP signature - they
>do not even need to check if it's there or not. End-user mail agent will do
>it.

Then it doesn't accomplish what SPF is trying to do. A spammer I've annoyed before has used my domain as the 'source' for one of his spam floods. If SPF had been deployed, I wouldn't have received the 100,000 bounces or so that I got.

How do you propose that PGP signing of email would help with that? Because I can't see how it would make any real difference.

Bear in mind that the aim is to drop the mail before it even really enters the system, not to post process it. We can already do that.

>And as for "simple PGP signed (by unknown key) mail" being not better then
>normal mail - it's not. It's harder to create and you can not generate
>1'000'000 different PGP keys with ease. Plus if you can not find key on
>public keyserver - it's reason enough to reject mail.

So all the spammers will do is use their zombie machines to generate keys and submit them to keyservers. Congratulations, we now have another wrecked resource.

Debian rejects Sender ID - SMTP Authentification.

philips — 2004-09-07T09:06:53+00:00

Posting off thread.

I want to stress why authentication is important and sufficient.

Spammers do pretend to send you something you do not want to receive. And you with you internet bandwidth do pay for spam. SMTP and Internet are designed so: we cannot use principle of post offices who charge sender for both sending and receiving.

As I do understand current legal situation, someone cannot send me unsolicited e-mail. And the real problem that we cannot trace him - SMTP header is generally not authoritative and From: in particular. We cannot be sure who is responsible for sending given pile of crap. Have we authentication measures in - spammers will get "real names" on their e-mails. Police/whoever will be able to locate them and fix their brains. At moment - finding spammers by their IP addresses proved to be very difficult and burdensome process. As long as easy ways to access Internet are present (and actually we want more of them - like wi-fi) spammers will be able to change IP addresses even faster then before - making it even harder to trace them. Just because they can forge from: field.

I'm ready to upgrade all my software to get rid off of spam. I'm not admin know - but in my times, when I was responsible for three domains and their mail, I absolutely sure that I will make a case to management to upgrade us to anti-spam loaded MTA. For our business partners we can make a sort of white-list - and ask them to upgrade. As business user, I have to publish my e-mail. I have to make it open - I cannot make white list - I have to receive e-mails from new partners I do not know about yet. We need a way to tell that guy who send this e-mail is the really who he claims to be.

SMTP Authentication/SFP will not stop spam - but it will help hold spammers liable.

Umm... I hate to take away your taking away of the last example

Ross — 2004-09-07T01:10:02+00:00

I basically agree with your first paragraph. SMTP authentication doesn't
prevent receipt of spam, but it does prevent anonymous sending of spam.

You lose me in your second paragraph. Spammer's don't need to run SMTP
an server to send spam. As you say, an SMTP client can pump out messages as
quickly as it's network connection will allow. If you meant that people
accidently setup open SMTP relays which allow spammers to hijack their
servers then I agree, but it's an obvious problem with an obvious solution.

That much trouble?

rdowner — 2004-09-06T20:30:13+00:00

A few months ago I was "joe-jobbed". A spammer, for several weeks, was sending out spams forged to appear from my domain. The invalid email addresses were, of course, bounced back to *me* -- several hundred *a day*. If those mails servers processing the received mail support SPF (and if I had an SPF record on my domain), I would not have bombarbed with the "shrapnel" -- the receiving mail servers would have realised that it wasn't me sending the e-mail and would not have even accepted them for delivery. This would have saved me the problem of suddenly getting hundreds of messages in a short period of time, desperately reconfiguring my mail setup trying to stem the flow of bounces, and inevitably losing some of my valid mail in the process

No, SPF will not solve the spam problem, cure all disease or bring about world peace. But it will solve *some* problems, such as the problem I've just described. There is money to be made in spam and there is no doubt that the professional spammers will find new ways to get the spam delivered. However, today, I believe there is value in SPF - it will stop a class of spam attack (assuming SPF is widely adopted). It doesn't add "hoops" for the vast majority of people, as ISPs will simply need to update their DNS records with info on their mail servers and their end users need take no action (it has been remarked that "mobile" users may have some issues but there are workable solutions to that too.)

regards,
Richard Downer

That much trouble?

paulj — 2004-09-06T19:42:17+00:00

But you can protect against bounces with outbound-envelope-cookie schemes like SRS. Further, with SRS, you protect *yourself*, you dont rely on other people to check SPF first before sending a bounce to you.

Unlike SPF, outbound-cookies dont break, the very common, use of SMTP forwards.

SPF! It "authenticates" (cough) mail from my domain, Yay for SPF!

/me uninstalls gnupg

"It's not a bug ... it's a feature"

freemars — 2004-09-06T18:42:38+00:00

pgp-mail requires you to receive the entire email before making a decision. SPF does not. That saves bandwidth.

The bandwidth costs the spammer (or the major ISP which doesn't block mail from zombied computers) as much as it costs you. You can do your part to drive the cost of spam up.

Think of it as a tarpit.

Further downthread people are saying how PGP'd spam would do more to hurt encryption than spam; they're probably right (imho).

That much trouble?

marble — 2004-09-06T18:10:41+00:00

You wouldn't say that when you're treated to thousands of bounces, hatemails
etc, cos some spammer has decided to send email from your address. This
happens, SPF offers a solution. SpamAssassin already does a fairly decent
job of filing spam away in the bit bucket so with widespread adoption of
SPF, I'd be happy. (Yes, it has happened to me.)

Umm... I hate to take away your taking away of the last example

gwolf — 2004-09-06T16:55:18+00:00

It does not solve the problem. SMTP authentication makes it necessary for you to authenticate with a server in order for it to accept your mail and relay it. It does not, however, require anything from you in order to deliver you a message created somewhere else for a local user.
The problem with spam is that it is too easy to set up a simple SMTP server. It is so easy that hundreds of people do it even without knowing. It is also an important problem with viruses/worms: You might not even know you have a SMTP client in your machine happily sending mail everywhere it can!

That much trouble?

TwoTimeGrime — 2004-09-06T16:03:44+00:00

> Easy: it's try to reject mail from someone who's pretending he/she
> is now what he/she is. pgp-mail does is way better then any
> patented scheme.

pgp-mail requires you to receive the entire email before making a decision. SPF does not. That saves bandwidth.

SPF isn't covered by a patent. You can use it. It's working now to stop joe-jobs. See this link for a good overview: http://yro.slashdot.org/comments.pl?sid=119211&cid=10...

> Yes, it needs some changes in end-user agents, but SPF/SenderID
> needs these changes as well!

SPF does not require a change in end-user agents. It can and does work at the MTA level.

That much trouble?

khim — 2004-09-06T15:26:00+00:00

I do not ask you "is it forgery from SPF point of view". I ask you "is it forgery or not". I know what SPF does. It's just what SPF does is useless: it adds new hoops for "honest" people and adds very small protection against type of forgery used by spammers.

That much trouble?

jamesh — 2004-09-06T15:20:37+00:00

Hmm. Are you sure ? If mail is sent from domain where are no real users at all are registered (just SPF records and some cracked SMTP server) it's forgery or not ?

I wouldn't call that a forgery. The SPF records tell you that the message was sent from a server authorised by the domain name holder. It doesn't tell you whether you can trust the domain name holder though (and has never claimed to).

That much trouble?

jamesh — 2004-09-06T15:16:13+00:00

None of the mail I receive is signed with my key either, I rarely correspond with myself. ;-) But more seriously, GPG/PGP's functionality indeed would not suffer at all if spammers used it, I'd still be able verify the authenticity of mail signed with a key which I have trustpath to.

This is the point that I was trying to get across in my previous message :). A valid PGP signature on its own doesn't prove that a message is legitimate. All it does is prove that whoever sent the message holds the private key. You need something extra to prove that (the web of trust in the case of PGP).

Similarly for SPF, a pass only proves that the mail came from a server approved by the domain holder. You would need to combine that fact with other information to determine if a message is legitimate.

Both PGP and SPF help prevent third parties sending mail that claims to come from you though, which is their primary purpose (in PGP's case, one of its primary purposes). If you expect either to get rid of spam on their own, you will be disappointed.

That much trouble?

khim — 2004-09-06T13:52:11+00:00

Argh. Of course receiving servers do not need to verify PGP signature - they do not even need to check if it's there or not. End-user mail agent will do it.

And as for "simple PGP signed (by unknown key) mail" being not better then normal mail - it's not. It's harder to create and you can not generate 1'000'000 different PGP keys with ease. Plus if you can not find key on public keyserver - it's reason enough to reject mail. If it's there - you can see about who'll signed it. Read PGP documentation - there are a lot of information about trustpath and such.

The fact is: with PGP you can change policy easily and you need only deal with 10-20 public signers while in case of SPF you're forced to trust god knows whom.

That much trouble?

khim — 2004-09-06T13:44:09+00:00

I think your understanding of "forgery" must be different to mine.

Hmm. Are you sure ? If mail is sent from domain where are no real users at all are registered (just SPF records and some cracked SMTP server) it's forgery or not ?

I mean "sending mail claiming to be from the address of some person, but not really being sent by that person".

Hmm... What about "mail sent from god knows where and by god knows whom" ? That's the real problem with spam, right ?

It just matters whether I can tell if a mail item is a forgery or not. That is the point of SPF and it does a very adequate job.

No, it does not. If I'm concerned about my regular correspondents PGP does much more adequate job. And when I'm concerned about others it does not make much difference to me if it's mail from joe@somewhere.com or joe@someplace.com if both joe@someplace.com and joe@someplace.com can not be traced back to physical person. Domain names are meaningless - you need to stop real physical person or you'll fight windmills forever.

That much trouble?

arafel — 2004-09-06T13:29:52+00:00

If receiving servers are expected to verify that a PGP signature is valid, that's quite a lot of work added to the machine. If they're not expected to verify it as valid, then what do you gain? You've still received the spam.

Basically, I don't think I understand your point. A mail being PGP signed proves absolutely nothing except that the sender had a copy of PGP. (Or GPG, if you're being picky :)

So why not use a callback instead?

sdalley — 2004-09-06T10:58:07+00:00

If by a fictitious domain you mean a domain that does not exist, then DNS lookup would not be able to obtain DNS records of any sort. Or do you actually mean something different?

That much trouble?

khim — 2004-09-06T10:41:37+00:00

The fact is: with PGP you know who to trust and wuth SPF you do not. You trust some random DNS server - and there are literally thousands of points where you can add your server without much checking. SPF is designed with the stupid idea in mind: you should trust any server with valid SPF information. That's absurd. PGP, on the other hand is designed to live in hostile environment: it's not enough to have valid PGP signature in mail. You somehow should be in trustpath.

Plus you need to sign each and every outgoing mail - just add requirement to sign From: and To: lines as well and voila - great strain for initial sender (==spammer). Relay do not change signature at all so they are not affected.

That much trouble?

neilbrown — 2004-09-06T10:35:51+00:00

I think your understanding of "forgery" must be different to mine.

I mean "sending mail claiming to be from the address of some person, but not really being sent by that person".

It doesn't matter how many new domains there are every day.

It also doesn't matter whether I can track down who actually sent the forgery or not.

It just matters whether I can tell if a mail item is a forgery or not. That is the point of SPF and it does a very adequate job.

So why not use a callback instead?

neilbrown — 2004-09-06T10:25:31+00:00

This is often referred to as "CBV" - call-back-verification.

The "from" address that is normally used is "<>". For other addresses it is possible to get false rejects.

The problem with this is that it allows an untraceable DOS attack. If some malcontent sent spam from thousands of "owned" machines all claiming to be from <axxx@my.domain>, then if all the recipients of that spam did CBV to my mailserver, it might be a very serious hit coming from genuine mail servers.

This may be a spectre rather than a real problem, and I'm seriously considering implementing it. However it doesn't really help stopped fakes or unwanted mail, at least not in the long run. It would server to keep the queue of outgoing bounces short though.

That much trouble?

ikm — 2004-09-06T10:23:04+00:00

The truth is, people WANT to live with spam. Because they tend to accept the offers from the spam letters. No one would ever send a spam otherwise, because it just would not help advertising.

So, it is actually a possible scenario, where people can both 1) have a possibility to send the spam and 2) never receive any spam at the same time... but not on that planet, or at least not today or tomorrow. The possible social solution against the spam in that manner would be for the mail filters to get each detected spam message through, but with the banner attached to each message explaining why all the spam should be ignored regardless of the offering in it. But it is really hard to change people that way.

That much trouble?

ametlwn — 2004-09-06T10:08:37+00:00

I bet that if such a filter was developed, spammers would start generating PGP keys and signing all their spam. If this happened, would you consider PGP to be useless?

I would consider pgp to be useless as anti-spam measure. The same way many people consider SPF to be useless as anti-spam measure (except for very short term).

I wouldn't, since none of the spams would be signed with my key.

None of the mail I receive is signed with my key either, I rarely correspond with myself. ;-) But more seriously, GPG/PGP's functionality indeed would not suffer at all if spammers used it, I'd still be able verify the authenticity of mail signed with a key which I have trustpath to.

So why not use a callback instead?

frankie — 2004-09-06T10:02:10+00:00

SPF-like protocols are not universal panacea. SPF just blocks forged addresses, like those used by a few spammers and worms.
Many other spammers use fictious domains (with good SPF records)
and pass anyway. The same thing could be done by worms potentially.
So SPF complicates life of normal users (who cannot use regular forwarding)
and have very little impact on true spammers who have methods to by pass it.
I see no evidence that Sended-Id is better...

So why not use a callback instead?

lolando — 2004-09-06T09:13:14+00:00

Assume I'm a spammer. Like my fellow spammers, I don't send e-mail from my own hosts but from open relays. I therefore register the whatever.com domain, host its name servers, and make its A/MX records point to some poor sod's open relay (that would be B by your notation, if I understood it correctly). Your A receives an email from my B (appearing to be from foo@whatever.com), double-checks everything, and proceeds to deliver it, or not (that will depend on how B is set up, I suppose). In any case, I have used very little of my own bandwidth.

Maybe I missed something.

That much trouble?

jamesh — 2004-09-06T09:08:38+00:00

The mail forwarding issue is known to the SPF developers, and they have a solution (SRS and whitelists). Getting the solution implemented is part of the problem of getting the system adopted.

As for the article you linked to, it is about the same survey as the one I linked to. The results are not that surprising either. If you expect an SPF pass to mean that a message is not spam, then you will be disappointed. One thing that the survey didn't touch on is whether any of the spams received claimed to come from their customers and passed the SPF checks. I'd guess that the answer would be no.

As a comparison, would you deploy a spam filter that let through all messages that had a valid PGP signature? I bet that if such a filter was developed, spammers would start generating PGP keys and signing all their spam. If this happened, would you consider PGP to be useless? I wouldn't, since none of the spams would be signed with my key.

That much trouble?

khim — 2004-09-06T07:50:59+00:00

It addresses forgery. Yeah, right. There are 3 millions .com domains. God knows how many in .XX for different countries and so on. More then thousand of new domains are created each day in .com. And I'm not even talking about domains of 3-4-5 level.

And the only way to track someone with SPF is to ask domain owner (often - not real person as well). The sad truth is that you can not trace sender with SPF: it's too weak to be used as court argument, for example. Any scheme where you can easily track physical sender will be rejected by masses (we already had one for more then 10 years - PGPmail or S/MIME) and if you can not do it then it'll be useless against spammers. Just like SPF is useless and will become even more useless if the future.

So why not use a callback instead?

leonbrooks — 2004-09-06T07:10:17+00:00

email arrives at your server (A) by the normal process of connect, HELO, MAIL FROM, RCPT TO - and we halt the process at this point;
A looks up the MAIL FROM address as if it was going to send email there; if there is no appropriate server records, this is spam - return a permanent error (555 sender email domain does not exist?), goodbye, and maybe mark the sender IP as a possible spammer;
A now connects to the nominated server(s) (at B); if it gets a temporary error, it also returns a temporary error (333 sender SMTP server unable to verify address?), and if it gets a permanent error it returns one (555 you don't exist so we're sending your details to the FBI);
A now walks through the process of sending mail to B, from a special address or range of addresses which "know" about callback, and if B refuses to accept it, returns a permanent error (555 originating email address is refusing a response?);
If B accepts everything up to and including DATA, we drop the connection, casuing B to discard the message;
If while faux-sending to B, A sees inbound email from B to a special address, it ACKs the incoming mail and discards it; if the sender actually delivers a message then both it and the original message are rejected (555 callback elicited excessive response?) instead.

Spammers can still set up fake inbound servers to "accept" callback checks, but it gives anti-spam software an extra address to correlate against and/or block, and represents additional discouraging work for the spammer.

Also, if the spammer is using an internet connection which bills them for traffic recieved, this starts to cost them. Especially if you're not charged for outbound traffic, and elect to respond to spam by portscanning the originating IP and sending back (say, for a DSL connection) 10000 copies of a 100kB randomised do-not-spam-me message for each inbound connection attempt from the spammer.

If 1% of mail servers did this, the spammer would get back 100x the traffic that they send and would have no idea whether any of the portscans are for real. Since some spamming software chops the internet link when it sees an incoming portscan it will slow down their work tremendously and possibly increase the outlay too, and if they're running an auto-IP-blocking firewall the portscan causes the spammer's own firewall to protect you against them - and if they're not, your email server can tell you that, too.

That much trouble?

neilbrown — 2004-09-06T06:33:52+00:00

This is a common misunderstanding of SPF.

SPF doesn't break anything and is not expected to prevent spam.

SPF simply provides a score - PASS, FAIL, UNKNOWN, ERROR (or something like that). What you do with that score is up to you.

This score is *not* a measure of how likely it is spam (though there is a correlation today, it is dropping). But that is not how you use the score.

I currently use the score like this: If it isn't PASS, and the mail contains a potentially executable attachment, drop the mail. This kills all mass-mailer viruses at very little cost.

If I ever implement a challenge-response system, it would use the score to say "Only send a challenge if the score is PASS", otherwise you might be spamming innocent people with your challenges. If the score is not PASS, and the address isn't on my white list, then I probably don't read the mail, though a very, very low spam assassin score might let it get through to me.

SPF doesn't address spam *at*all*. It addresses forgery. Once you have eliminated forgery, then other anti-spam measures like challenge-response and white-lists become must more useful.

The "breaks forwarding" is a very common misconception. Rejecting all SPF-fail messages would break forwarding, but such behaviour is not rational. Presumably you know everone who you expect to forward mail you. These sites can be whitelisted (if you trust them) or discontinued (if you don't).

The expectation of anonymity issue

eru — 2004-09-06T05:33:52+00:00

Why so ? Easy. Problem is with users, not with SMTP. What mail users demand is the following:
1. I do no want to get spam (== mail from unknown anonymous recepients).
2. I must be able to send spam (== anonymous mail via unregistered ISP).

I'm certain most users would be very happy to compromise on 2 if it would ensure 1. Until some years ago, most ordinary users actually assumed that "from" e-mail addresses are reliable and messages are traceable. It did not deter them from using e-mail. Only the spam catastrophe has made people more widely aware that the "from" field is just an arbitrary text that may have no relation to reality.

Set up an alternate e-mail system that has no anonymity, but no spam or viruses either, and I think a lot of users would be interested.

That much trouble?

paulj — 2004-09-06T02:59:19+00:00

SPF in providing a check that a mail comes from an MTA which is authorised to send for that domain, breaks many common email setups, forwarded SMTP accounts being the big one. Do i have to go configure my MUA to connect to different SMTP servers for each address I have hosted at different places? What if my ISP blocks SMTP? Ah, use MSA.. what about when ISPs start blocking that?), while doing absolutely *nothing* to solve spam. Indeed, Spammers have enthusiastically adopted SPF and at present the majority of email with valid SPF is spam!

SPF: breaks many valid and common SMTP uses and has 0 effect on spam. Yay for SPF!

POP and IMAP

Ross — 2004-09-06T02:16:20+00:00

One thing I never understood is why POP and IMAP never supporting sending
email, only receiving it. If they had implemented a single protocol to
handle both, which included user authentication, then most people wouldn't
need an open SMTP server at their ISP to send email. This would have allowed
more places to turn off unathenticated SMTP and we wouldn't have as much of
a problem with SPAM from home user's systems (we would at least be able to
track it down to the correct account).

That much trouble?

jamesh — 2004-09-06T01:38:23+00:00

I cannot get it: piece of software proved to be ineffective causes that much trouble?

What makes you say that SPF and/or SenderID are ineffective? If you are referring to things like the recent Register article, then you are missing the point. SPF is about authenticating that a piece of mail came from where it says it came from.

The fact that you can authenticate that a message comes from the sender does not mean that it is not spam. However it might prove that the spam came from a domain owned by a known spammer, which might be useful to your spam filter. Authentication will also mean that if you get a message from your bank, it will have come from your bank rather than a phisher. And it should virtually stop the spread of mass mailing email viruses that forge the sender address (something that should please people not using Windows ...).

Of course to be effective, any of these protocols need wide adoption. The Microsoft patent could very well make Sender ID ineffective, which is what this article is about. However, it looks like SPF does not have this problem.

That much trouble?

khim — 2004-09-06T01:36:41+00:00

Right, but... Try to think about it again. When I talk about 2) I do not talk about professional spammers! I talk about normal lawful internet citiziens. They do want to send anonymous mail to this or that website and/or to this or that mailing list. All the time. It's not some obscure twist - a lot of peoples become very nervous if you'll suggest some theme when mail can be easily tracked to physical person.

This is good and all, but... if you can not trace back "normal" sender (who never even seriusly attempted to to cover tracks!) how the hell can you ever hope to trace back professional spammer ?

This is what I meant above: people somehow think magic SenderID or something can make spammers easily trackeable but still will not affect anonymity of "lawful citiziens". It's impossible.

And if you'll trink about it pgp-mail does exactly what you're proposing. It was around for more the 10 years. It's still not widely used. Why ? Since pgp-mail (once you'll demand correct signatures with keys registered on few well-controlled key-servers) will "greatly affect privacy - and we do not want it". But if you got privacy then why can not spammers get privacy the same way (no matter what authentification scheme is in use) ?

Think about it...

Umm... I hate to take away your last example

Ross — 2004-09-06T01:26:14+00:00

But please google for SMTP authentication. SMTP auth exists and is supported
in all the major MTAs. Getting people to use it is another issue.

Debian rejects Sender ID

copsewood — 2004-09-05T23:48:30+00:00

Fine. Stick with classic SPF which has no such patent problem. M$ SenderID adds no value to this - it takes value away by bloating the SPF format with unneccessary XML, increasing the risk of exceeding the 500 byte DNS record threshold where you have to transition from UDP to TCP DNS lookup - making the whole thing unworkable. The reason some SPF developers have agreed to include SenderID in the proposed RFC is political, not technical, as this multiplies the clients likely to implement SPF/SenderID soon by a factor of 10. If my reading of the SPF list is correct, in practice, I think this standard proposal is likely to include classic SPF as the base implementation, and this is what will be used in practice as opposed to theory.

That much trouble?

Russell — 2004-09-05T23:02:20+00:00

It may be possible to satisfy both 1 and 2.

1. Satisfied by only accepting mail from a list of authorised. Use signatures to do this. We then need only protect the keys from viruses. That is a problem programmers can solve ( not a social issue ).

2. Allow people to send spam. ( Nobody will be listening anymore )

That much trouble?

khim — 2004-09-05T22:36:27+00:00

And what SPF/SenderID is ? Easy: it's try to reject mail from someone who's pretending he/she is now what he/she is. pgp-mail does is way better then any patented scheme. Yes, it needs some changes in end-user agents, but SPF/SenderID needs these changes as well! Of you can add proxy in the process. The same as with pgp.

If you say: "SenderID is different solution" I'll agree. If you say: "SenderID is better solution" then I want clarifications. It's pretty easy to add "reject non-pgp signed mail" rule to senmail or other MTA - it's just deemed "too intrusive". Thus instead of good and tested solution we're stuck with bunch of half-backed "extensions" and stupid "authentification schemes".

That much trouble?

neilbrown — 2004-09-05T22:25:35+00:00

Why cannot open source developers try to come up with some simple protocol? - and implement it for exim/postfix/sendmail. After all, this packages route crucial amount of post on internet - and all of them are open source.

They did. It's called "SPF". Lots of people have said how flawed it is, but as long as you have your expectation set right, it does a completely adequate job.

By "expectation", I mean it doesn't defeat spam, and it doesn't defeat phishing, but then it cannot as those are both very much human-factors problems. It can defeat forging, and this is an essential input to any automatic tool which could help attack spam and phishing.

As far as I could see, SPF was pretty much on track right up until IETF got involved....

That much trouble?

doogie — 2004-09-05T22:17:49+00:00

pgp-mime has nothing to with allowing one to send mail. It's only for making sure it isn't modified in transit, can't be read by unknown third parties, and that the sender is who they say they are. It has no bearing on mail routers in the middle, nor the mail routers on each end point.

That much trouble?

khim — 2004-09-05T21:32:21+00:00

ssh did not need years to come up with ways to detect identity forgery - why it takes that much time to implement it for e-mail?

Hmm... Good question... Especially since we had a solution for this problem for almost 10 years: RFC1847, RFC2015, etc. Way before spam become real problem. Yet... there are still this nasty spam problem and nothing is solved.

Why so ? Easy. Problem is with users, not with SMTP. What mail users demand is the following:
1. I do no want to get spam (== mail from unknown anonymous recepients).
2. I must be able to send spam (== anonymous mail via unregistered ISP).

That's all. Since there are no sane way to implement both 1. and 2. simultaneously we end up with all this mess like SenderID and such. That's all.

As usual there are no technical solution for social problems: people should either accept spam and live with it or they should accept lack of anonymity. You can not have both.