Slashdot Mirror

I have one address that I have paid for, not too much a year, which forwards all the email to my ISP account. I can't change it easilly because it's been my address for 25 years.

Same here. I just checked, and it would appear I've had my Pobox for 22 years. Until I changed it to point to my personal domain email, I didn't even know what my "real" email address was most of the time. If I changed ISPs, I'd go to Pobox, change the forwarder, then change my email client, and I was good to go. For me, the best benefit of this service is that I never have to tell anyone if the underlying email address changes.

FWIW, I've been very happy with the stock filters that Pobox uses, and their service in general.

I'd like to point out that there is another Pobox out there, which is a US company (pobox.com), that is apparently not affiliated with this British "Pobox" company.

From their blog:

=snip=

We support @ThePSF in their fight for Python trademarks in the EU. @pobox is *not* http://pobox.co.uk. Learn more: http://pyfound.blogspot.nl/2013/02/python-trademark-at-risk-in-europe-we.htmlâ¦

=end snip=

I'm not affiliated with either company. I've used pobox.com for email forwarding for about 17 years though, which is one thing that made me investigate this, as the UK company's claim of having used 'python' for 17 years seemed to me like about how long the US company had been around.

That's why services like pobox.com exist. I've had the same email address since 1997, but I've used mutiple ISPs, Yahoo Mail, Hotmail, Gmail, etc. for my email in that time.

Whether or not anyone else cares that they can still get ahold of me is a different issue.

• A free email service. GMail offers free mail forwarding and I presume some other services do so as well.
  
• A university alumni address. There's a good chance your alma mater offers one. Universities benefit because they get to stay in contact with potential alumni donors. Institutions of higher education are more stable than almost any other entity in society, so the odds joe@alumni.example.edu will still work 50 years from now are as high as you can hope for.
  
• A for-pay forwarding service. Pobox has been around since 1995 and I've been a customer since 1996. The current price is $20 a year for three pobox.com addresses and some other features like spam filtering. As for whether customers can rely on any one company to stick around, Pobox's current FAQs have long since been "corporatized" but a rough paraphrase of a question in an earlier version went something like this:

  Q: How do I know you'll be around in the future?
  
  A: Will you? (Ha! Didn't think of that, did you?)

  
  I prefer my pobox.com address over my university's alumni address because the latter assigns a letter-and-number userid I've never liked. I could always start using my gmail.com address instead, under the presumably-safe assumption Google and GMail will be around for a long time, but as a firm believer in TANSTAAFL I can't believe that GMail and/or forwarding mail to another address will remain free forever. Meanwhile, Pobox has a more than ten-year history and counting with better than 99.44% uptime. Even were I to switch to GMail for my day-to-day email access as opposed to the Emacs-based mailer I've been using for more than a decade, I suspect I'd still give out my pobox.com address instead of the gmail.com one.
  
  If you prefer gaining a permanent address by supporting a worthy nonprofit, two possibilities are IEEE and the Free Software Foundation. Each costs annually considerably more than $20, of course; if FSF would offer some sort of lifetime membership for a reasonable sum I'd probably do it, though.

The problem with the scheme isn't that it's charging for e-mail; ultimately that's the only plan I'm aware of that has any chance of working. (See http://www.pobox.com/~meta/pages/spam for my rationale for that statement.)

No, the problems with this scheme are:

- No provision for non-profit entities (e.g. mailing lists I run for friends, etc.)

- The amount isn't set by the appropriate party (i.e. the only person qualified to determine how much it should cost you to send me mail, is me.)

- The criteria aren't set by the appropriate party (i.e. similarly, the only person qualified to determine whether a given source of mail *should* be subject to this charge/filtering in order to send to my mailbox, is me.)

- Doesn't scale (if every ISP does it, you have to pay every ISP, billing/paying costs become ridiculous, etc)

There may be other problems too, for example AOL's implementation may be insecure. In fact, I'm guessing it will be.

I did try ByteMark when Apple used it as a basis for it's claims, as I did with their other basis during other advertising campaigns over the years. When x86 ByteMark was compiled with a current compiler with appropriate settings the PowerPC improvements were far less dramatic than when Apple used an old 486 optimized version on a Pentium against a current PowerPC build.

And did you try ByteMark with a compiler built specifically for winning that benchmark on the x86? (Like the Intel Compiler?) Remember Apple quoted it, after taking whatever measures they wanted to to make sure they looked good on it. Intel responded many years later (they did not have a compiler shipping at the time Apple first used ByteMark publically), but only after Apple stopped using it as a benchmark. lmbench, which is a subset of the ByteMark benchmark for Linux systems, has been running for some time and show that x86 processors have been ahead of Mac processors from at least the time of the Athlon.

... Similar story when Apple used an inferior compiler for Intel spec scores, rather than official spec scores. ...

Which Spec scores? The recent stuff is fully debunked here: http://www.pobox.com/~qed/apple.html (scroll down a bit). Do you mean the old Spec 92 scores? If so, I just took the numbers from the Spec themselves -- Intel was mostly ahead of them (Motorola may have taken advantage of the lag in product launches between the Pentium and Pentium Pro to temporarily come out ahead).

Historically Apple's claims over the years have been marketing exaggerations, PowerPC turned out to only be slightly faster in technical comparisons but an overall loser in general real world comparisons.

There has never been any reputable numbers to back such a claim up. You have to go back to really old stuff before that is even possible.

You are mistaken regarding P3s and early Athlons. Are you playing games on the Athlon side where you use the actual clockrate rather than what AMD claims is the equivalent and uses on their product packaging and literature?

Its not likely that I would make that kind of mistake -- I used to work for an x86 vendor, and was following that stuff very closely at the time. The leading architecture of the PPC at the time was from Motorola, and the maximum potential of what the processor documentation said was lower than what the x86's of that same era actually delivered. The PowerPC G3 was basically comparable to the AMD K6 processor on a per-clock basis.

The G3 had fewer rename registers, the multistep single addressing modes common to most RISC processors, a non-fully pipelined floating point unit, two integer adder-ALUs, and very shallow speculation and reordering capabilities. The K6 had better reordering capabilities, but a slower instruction decoder. With the G4 the clock rate improved, and there was a slight increase in rename registers and reorder buffers, but the Athlon, P-III, and P4 all shipped during this period all of which had vastly superior microarchitectures (remember that these chips also all had hefty on-chip L2 caches).

The Motorola G4+ basically deepened the pipeline and increased the clock rate, but did something which dramatically lowered the IPC. I never bothered to figure out what that was since it was slower on clock rate anyways, and was clearly losing benchmarks even to the older G4.

It was not until the IBM 970 that the PPC was on a more even footing with x86s from an architectural point of view (deep pipelining, large reorder buffers, many rename registers, pipelined floating point, etc) -- except that they totally sacrificed integer performance. With a latency of 2 clocks per integer instruction, it meant that any code that has high integer utilization runs slower (some figures here:

I agree with Microsoft on this. I have been using http://pobox.com/ for some time now and the results are dramatic. With their filters I can log in and view messages that were rejected and those that are held for review, and have the option of releasing false-negatives and putting them on my whitelist. I still get 5 or 6 spams a day but I can handle this easily. The rejects are in the thousands sometimes. This all happens before the email gets to my email account. Pobox.com is a forwarding service. Mail for me goes there and then is sent to wherever I wish (up to 3 redirects).

Any program that can make the impact minimal is IMHO - as the article says - the ojbective. I can deal with some junk mail, I just don't want to spend any significant time cleaning it all up. What pobox.com does not get, gmail usually picks it up and places it in my spam folder. Nice. If Microsoft can do this then I think they are on the right track.

In C# structs are allocated on the stack.

No, they're allocated "inline" with the variable (if there's one involved) or on the stack if they're part of an intermediate expression. The mantra of "struct => stack" is one which has confused many people in my experience. See http://www.pobox.com/~skeet/csharp/memory.html for more details. (I'm only picky about this because of the confusion that this has caused.)

For limited-lifetime objects, C# actually has a built-in keyword. It's called using and it works along with the IDisposable interface, regardless of whether your object was allocated on the stack or not.

Calling Dispose doesn't change the lifetime of your object (well, it might suppress finalization). It's to do with releasing resources *other than* the memory taken up by your object itself.

That's absolutely correct. Take a look at SPF over at http://spf.pobox.com/ and how their embrace and extend approach was used to fracture an approach that would lighten the burden of spam for mail servers worldwide and break their SenderID model of selling keys to authorize users. Then notice that AOL has thrown out SenderID, but held up full implementation of SPF for nearly a year while the development and legal arguments were going on.

Or perhaps:

3: Take the results, skew them wherever possible, lie about them, and take sole credit for anything even vaguely positive that comes out of it.

Go take a look at Microsoft's attempts to enforce their SenderID "buy a Microsoft stamp on all your email" licensing scheme on top of the SPF anti-forgery email scheme, at http://spf.pobox.com/ for an example of how they not only manipulate development for their own ends but of how now they're taking credit for SPF, and how they actually prevented SPF from getting RFC's published so it can have standards implemented into new mail servers.

Implementing SPF widely would entirely block most modern email worms, and could reduce phishing schemes by a huge factor. But no, Microsoft had to "embrace and extend" its development and push most developers right out of it by supergluing their own already-proven-useless project onto it.

Actually, SPF is a good and lightweight first step to authorized (not authenticated!) email. Take a look at http://spf.pobox.com/ for more information.

Microsoft tried to hijack this with their SenderID system, which would have been a central authorization system and which has been harshly rejected by almost all of the actual SPF developers.

Not if SPF comes into common use. The DNS for most SMTP hosts or websites would contain a list of hosts or addresses permitted to send mail coming from there, and block mail that isn't from those addresses. It works quite well, although Microsoft's meddling has slowed its adoption quite a lot. Take a look at http://spf.pobox.com/ for more details.

I didn't realise when I replied to you earlier that you are not just a regular proponent of SPF, but Wayne* , so of course, you're very familiar indeed with the pros and cons of SPF. My apologies for not recognising you earlier, and for perhaps oversimplifying what I think all sides in the debate will concede is a difficult problem.

* I guess you've been on by Friends list for so many years, I'd long forgotten *why*

SPF seems like it might no allow forwarding and remailing to work, though.

Under SPF-aware forwarding, each remail operation on a message replaces the envelope's sender address, and only the newest envelope is checked against the domain's SPF record.

SPF seems like it might no allow forwarding and remailing to work, though.

Under SPF-aware forwarding, each remail operation on a message replaces the envelope's sender address, and only the newest envelope is checked against the domain's SPF record.

But, what about legit messages from banks, friends, and government agencies who aren't using senderid?

By definition, a valid Sender Policy Framework record is a valid SenderID record. Banks and government agencies control their own domains and can easily add the TXT records that SPF uses. Friends on dial-up can switch. Yes, it would hurt friends on broadband, who generally can't switch away from the monopoly or the duopoly and would have to find a webmail provider that has SPF.

There is also Sender Policy Framework (http://spf.pobox.com/), this is very simular to SenderID but it has the majour advantage that its open source, agreed microsoft is trying to push SenderID down everybodys throats, I myself publish SPF on a number of domains and it does a good job. The more people that use SPF the more power it will have over SenderID.

Stuart Gathman's opinion is recorded at http://archives.listbox.com/spf-discuss@v2.listbox .com/200410/0488.html.

Yes, it does. You'll have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.

If your forwarding runs through a commercial service like pobox.com, you shouldn't have to do anything. They have to change with the times, and perform the above rewriting automatically for you. SRS is a structured standard that helps them adapt.

Until the SRS patches are ready, the following workarounds will preserve the important functionality.

http://spf.pobox.com/faq.html#whichfield
So, this is implementation specific, but it seems that it will compare published SPF record of the domain in the FROM: or the return path with the fully qualified domain name of the sending machine (zombie123.earthlink.net yields "earthlink.net").

So, if the incoming email claims to be from/return-path taco@slashdot.org and slashdot.org publishes an SPF record, that SPF record had better list zombie123.earthlink.net as a legitimate mail server or it will fail.

What, specifically, happens when it fails is also up to the implementation.

The problem appears when taco@slashdot._org sends an email to my old college which offers forwarding services for alumni.

taco@slashdot._org sends to khasim@example._com

mail.example._com forwards that message to my gmail account.

mail.gmail._com checks the From:/return of slashdot._org and checks their SPF record for slashdot._org.

slashdot._org does not list any example._org boxes as a mail server so the message fails the SPF check.

Again, what happens at this point depends upon the implementation of SPF that is being used. It can range from increasing the SpamAssassin score to dropping the connection attempt.

It's all well and good that something is being attempted to alleviate spam in this manner

I don't think you are getting it yet. I would suggest you check out http://spf.pobox.com/ it will outline it some more. But think of it this way. The president of the company is at home and wants to send an email out of his earthlink connection to a customer on hotmail.com from his email company email address of abc@domain.com he has to send it to earthlinks smtp server because earthlink as well as many other ISP block outbound port 25. It hits Earthlink then earthlinks trys to send it to hotmail.com but hotmail looks up the spf records for domain.com and earthlinks outbound server isn't listed and gets assumed to be spam and gets blocked. So now we have to work around the issue by

a) having him send from his earthlink address to the custmer.

b) setting up his mail on ports other then 25 to get around earthlink port 25 issue and send thought the company servers.

c) add earthlink to our spf records including every spamer, etc. that ends up using earthlinks outbound servers to our record.

All 3 have issue and require resources to get around not to mentention that is will likely happen at 3:00 AM on Sunday Morning when the person on the other end must have it in his hand yesterday so I am tring to work around the issue then.

It will stop SPAM that is from a forged sender, which is a non-trivial amount. Meaning, I can't send you a message purporting to be from billgates@microsoft.com, which is how things are right now. Look over your SPAM headers, and you'll see, most of the return-addresses do not match the machine that relayed the message.

spamer.com TXT "v=spf1 ip4:1.0.0.0/2 ip4:64.0.0.0/2 ip4:128.0.0.0/2 ip4:192.0.0.0/2 a mx ptr ?all"

Your assertion that Hotmail will only be using SPF v2 records to do the filtering is patently false.

The following comes from http://spf.pobox.com/senderid.html

spf.pobox.com is responsible for the SPF concept, and was a partner with MS in developing Sender-ID. I quote:
--begin quoting---
spf2.0 records

I just published my SPF record. Do I need to publish an spf2.0 record?

Answer: probably not. By default, Sender ID will read v=spf1 records for checks against both identities. If a sender needs to distinguish one identity scope from another, it is welcome to publish spf2.0 records, which can be made specific to either the PRA or the MAIL-FROM. The vast majority of publishers are not expected to need to do this. Hotmail.com, for example, only publishes a v=spf1 record. So you probably don't need to either. You probably only need to worry about spf2.0 records if you're an ESP or have a contract with an ESP.

As of 20041110, this matter is still open to debate and is being actively discussed.
--end quoting---

Not a huge fans of Sender-ID either, but the assertion that an SPF2 record is required here ain't true.

Oops, SRS is Sender Rewriting Scheme. http://spf.pobox.com/srs.html (thanks to the poster below, sorry 'bout that.)

There are other efforts (in addition to RBL style lists) to fix some of the problems which derive from the assumed trust that's built into the SMTP protocol. For a brief shining moment last year, I thought that we might all hold hands and sing together on this one, but Microsoft managed to drive of their early Sender ID adopters and alienate potential allies in the battle against spam by making vague patent claims and apparently refusing to even clarify.

Adoption of the Sender Policy Framework seems to have slowed, probably caught up in the confusion around Sender ID and the Microsoft patent claims. The linked site claims that SPF is unencumbered.

It will inconvenience a big number of CEO's, CFO's, and other people who literally cannot be bothered to learn how their laptops work and want all their email to look like it is from their work account no matter where they are.

Blocking port 25 is a reasonable approach for most ISP's, since the large majority of email is now spam and email worms. Blocking port 25 puts a big dent in the worm traffic, since the outgoing traffic will hit the mail server of the ISP responsible for the infected customer. It also puts a big dent in the zombie traffic, which whips around most blacklists and burdens a lot of ISP's with maintaining huge and problematic blacklist of all DSL/cable/dialup IP addresses they can find.

A better solution is SPF. Not thw Microsoft DomainKeys or SenderID solution, but the pure DNS solution that says "this domain publishes a text record that says mail claiming to be from this domain must actually come from permitted IP addresses". It's cute, it's lightweight, it needs people to use the filtering to really have an effect. Check it out at http://spf.pobox.com./

I seriously don't understand anyone's statistics. I have a website that is not particularly aligned with FOSS and I have never seen MS IE above 75%. You can see longer term statistics here:

http://www.pobox.com/~qed/sitestats.html

Of course I am counting robots (they are essentially my control group, to make sure my stats are consistent) by that's never more than 12.5%. Ok, in any event, the other thing I am seeing is that Firefox started by gaining marketshare at an enormous rate. Like others have stated, the fact that the "second derivative" has been forced to negative is just a side effect of the insane initial growth.

This month so far looks like IE @ 54% and FF @ 20% BTW. So yes, its unlikely that FF will gain the insane 6% or 8% -- its more like 2.5%. Oh yeah, at a lot of FF's market share has come at the expense of Mozilla, of course, and it looks like Opera is slowly starting to give up some of its share to FF as well. But the balance, of course, is coming from IE.

What does SPF have anything to do with this?

If your domain is high-jacked due to a fault with the security of your domain registrar, then yes, you have bigger problems than any anti-spam solution.

This is not the purpose of SPF

If you read spf.pobox.com You can learn that SPF is merely designed to be a system which can eliminate domains being spoofed in the from field of spam messages.

If someone is using one of my domains (logicx.net) to send spam; I can reduce the affect of such a joe-job attack by having a published SPF record; such that receiving systems can verify if the email came from a logicx.net mail server, and reject it appropriately.

SPF and PGP have entirely different authentication approaches. I'd go so far as to say that PGP is more integrity checking.

SPF is a verification that mail for a particular domain came from an appropriate server -- with the goal of disposing false emails (spam, spoofs, etc.)
This is not at all a system to verify users on that particular email system.
This is where PGP steps in -- It is used to verify the integrity of the email -- that it came from a particular user, and came unaltered.

Finally, where has it been verified that their was a breach of their DNS system?

All of the screenshots have now been confirmed to be a firefox situation where when DNS failed it resolved www.google.com.net -- which resolved to the people who own com.net

Well, actually Microsoft should care what people use, specially if Mozilla and Firefox are the cause of IE decline. And I use PNG for every graphic in my website AND some of them have transparent backgrounds, if you want to make them "compatible" with IE you have to tweak the PNG with TweakPNG . Take a look. Actually you can't make it transparent, but can set the background color to match the color of your background. They'll be transparent in Mozilla and color-match in IE.

Ok? Smart-ass....

http://spf.pobox.com/

It's not a perfect solution but it's a darn good start to at least legitimizing the sources of email.

Looking in my mail server logs, I'm seeing more people use SPF but there are still way too many domains that don't.

I'm already relaying via ISP - the only problem is that I have to use my ISP email address as my from address.

Ah, bummer. Makes sense, though. From their perspective, anyhow. Cuts down on shenanigans.

I'd rather use my own address as a from address so that I'm not locked in due to inability to switch email providers.

Well, I don't want to sound like a shill, so I won't mention my favorite fowarding service again. I'm sure that Google can tell you about other email forwarding services, though. Some are free, and some are pretty nominal in cost.

Really, there is no reason not to grant static IPs to all DSL users - that gets around the whole dynamic IP situation. However, the ISPs want to make money, and there is no law saying that we have to make it easy on them.

Well, I understand your pain, but there's more to the story than just corporate greed. Even if ISPs did assign static IPs, I don't think much would change in terms of blocklists. Personally, I would still reject mail coming from known DSL/Cable space, regardless of whether or not it's dynamic. The reason is as I stated previously: 99.9% of mail originating from that kind of space is going to be from zombied PCs. It's not worth it to me to increase the burden on my mail servers by going past the step of checking the address against lists of known DSL/Cable addresses.

Think about what must happen whenever a busy ISP's mail server receives a connect request... One of the first things my servers do is check to see if the client is in a pool of known DSL/Cable addresses. If it is, the connection is dropped and the server is immediately freed up to attend to other requests. If I started doing things like checking for SPF records (when I know the client is very likely a PC on a DSL/Cable connection), my servers would begin to suffer. Should I add more servers to the cluster just so that I don't accidentally drop the occasional legitmate email from someone playing with Postfix at home?

I'm not saying that I'm happy about the situation. In fact, I hate that spammers have ruined the relaxed atmosphere of the Golden Olden Internet. Unfortunately, just as people lock their cars and houses, we have to accept that there are lots of sociopaths on the Internet who will take advantage of whatever they can to make a buck.

Linux and FOSS is affected by Windows viruses.. Lets see.. because of Windows viruses, my Linux based mail servers have had lots of great FOSS software developed to help combat the issue. On the down-side, many of these Windows viruses have also greatly affected my Linux systems due to DDOS attacks that have origins pointing back to viruses and other malware that has infected Windows boxes.

(*TOP*
(container
(title (@ (name "title")))
(item (name "Name1"))
(item (name "Name2"))
(description "Bla bla")
))

The spammers run their own SMTP servers - usually on 100,000 or so Windoze Zombies that they control. Recipients that check SPF on the forged messages, however, can detect and reject them. Caveat, if the recipient uses forwarders, then either the recipient or the forwarder has to be technical enough to properly configure forwarding (like SRS for the forwarder or a trusted forwarder list for the recipient). If the spammer publishes SPF, then the domain can be safely blacklisted without worrying about an innocent party getting joe jobbed.

This isn't magic, but if everybody publishes SPF Records for their domains and checks them (SpamAssassin 3) joe jobs become much, much harder.

So do the right thing and publish them. 5 minutes a domain tops if you're familiar with DNS.

vl

rhm

A few hundred random people received
"The message you sent X was undeliverable"
spam instead.

Maybe it'll teach them to publish SPF Records.

(and no, I don't know what the guy with thick glasses and the powerbook has to do with SPF)

That's what Sender Policy Framework and DomainKeys are designed to stop.

The expense of verifying real-world identities is why there aren't free SSL certs out there...

Actually, CAcert gives out free SSL certificates, if you can successfully interact with their web of trust.

Now, the PGP Global directory could certainly be subject to man-in-the-middle attacks if a malicious third party can actively read and respond to at least some of your incoming e-mail. That party could upload a bogus key and respond to the confirmation-request for you, then read things sent to you. Of course you'd find out when you saw strange unreadable signed messages coming to your account...

I also don't like the essage I got from the beta keyserver after I submitted my key today:

To ensure that your PGP software trusts keys verified by this directory, you must download and trust this directory's Verification Key.

Download the Verification Key

After downloading, import the Verification Key into your PGP software. Then, sign the key with your key and mark it as Trusted. Please see the documentation for your PGP software for specific instructions on trusting a key.

The directory seems like a highter-quality way to get keys, but I don't want to trust it *that* much; on the other hand, the Key Verification Policy seems to cover the same concerns that have been expressed here.

This is known as a "Joe job", apparently after one guy (Joe) who had this happen to him. The use of Sender Policy Framework (SPF) may help, but only if the mail recipients check this.

On the other hand, consider the address weisong@cs.wayne.edu. Visit www.cs.wayne.edu/~weisong, and you'll see his homepage. Look at the CS deprtment's list of faculty, and you see a link to that page. Wayne State University is an accredited institution listed, among other places, on the U.S. News & World Report site, and their campus directory has a link to their CS department. Since Dr. Shi is a professor, the department probably did a minimal background-check before hiring him, and you can trust his identity (at least minimally) based on his e-mail address.

Incidentally, I'm sure this directory would be useful to Dr. Shi; even though he teaches computer security, he's lost the passphrase or digital private key for all four of his public PGP keys, and he either never generated or subsequently lost the corresponding revocation certificates as well.

But even beyond that, you can do something to determine whether or not your domain issued the email that generated a bounce/challenge. TMDA can help with this even if you don't use the C/R portion. You simply tag the sender address in all outgoing email with a dated address that only you can generate. All bounces/challenges will come back to that address. If it passes, then you know it came from your site, and you should allow it. If it fails, drop it like a hot potato: you know you didn't originate it.

My recommendations:

1. Publish an SPF record
2. Deterministically ID legitimate bounces to your domain.

Secondly, SMTP supports tagged addresses of the form username+tag@example.com, and your email client can filter on the tags. Unfortunately, that's not foolproof - many web forms choke on the "+", because it has syntactic value to CGI and they're not always bright enough to escape the character. (But almost everything can handle subdomain-format tags.) Also unfortunately, Pobox's forwarding service and .forward files and other mail forwarders generally don't know how to preserve the tags while forwarding mail, though sometimes they can at least forward the mail.

The biggest problem with tagged emails is that to use them effectively, your email client needs to keep track of them, so if you get mail addressed to tag-for-alice@username.example.com, your reply to it will come From: tag-for-alice@username.example.com and not From: somedefaultvalue@username.example.com, and if you're sending mail to alice@alice.com, your mail client will know to send mail from tag-for-alice@username.example.com or whatever the last tag was that you used to send it to that address. Also, your email client should keep track of all the addresses you've sent out, because you might want to handle mail from unknown tags differently.

Moreso, with places like AOL, Hotmail, and the like where SPF has already been published. Send from your Uni's E-Mail system using an AOL account as return path, or a Hotmail, or any one of thousands of other domains and it _will_ get rejected (quite properly) as a forgery, and your Uni as a forwarder of forgeries, hence a forgery engine. (See http://spf.pobox.com/SPF )

Finally, comments about the Sender: vs From: header. It doesn't matter. Both are forgeable. What _does_ matter is the actual return path used in transit -- often called the "Envelope sender" or the "MAIL FROM" (taken from the SMTP verb). Ideally, the From: matches that, but when it doesn't a Sender: _must_ reveal it, or again, it's mismatch forgery. As for rDNS having a matching forward DNS entry. That's a standard check. If a host has no rDNS, or has no matching forward entry, it's not an internet mail host. If it uses a HELO or EHLO without DNS for the specific hame clamed, it's not an internet mail host. No mail should be accepted -- PERIOD. The EHLO/HELO doesn't have to match the rDNS name (because of NATting). That's the ONLY exception.

Why do we need something else than SPF? SPF is open, easy and already working in many places. It doesn't need vastly new software or much special at all.

All you do is to add a TXT record to your domain and write down which addresses are permitted to send mail in your name.

http://spf.pobox.com/

Or what about simply SPF.

Seriously, there has been enough noise made about it lately. I jumped on to set up SPF in all of about 10 minutes, it really was that simple.

Since then I have been using the Thunderbird Extension for Sender Policy Framework as a quick and easy way to see which and how many domains publishing SPF records and have noted a few interesting things.

Namely, depsite the fact that MS wants their own standard to be thrown out into the marketplace (namely Sender ID), they are publishing SPF records on both Microsoft.com and on Hotmail.com. If I was the kind of guy who used the word "kudos" I would say "Kudos to them". I am no more of a fan of MS than anyone else here, but, those two domains alone represent a not insignificant percentage of spam floating around that can be fairly simply removed with a mail server reconfig. AOL is also publishing, so well done there.

Gmail are as well of course, but would you expect any less?

Yahoo are not, which amazes me - I realize they want to push DomainKeys, but, I see no reason for them not to be publishing SPF records as well.

The one that absolutely staggered me though was Citibank.com. I recall reading somewhere (no link sorry, but a quick google illustrates the point) that something like half all the phishing emails floating about are aimed at Citibank. For the sake of a few minutes, they could at least give people who want to, a surefire way of rejecting all phishing emails at MTA time. They must have among the crappest DNS admins on earth, or some very bad policy makers.

I shall end this spiel with a request. If you administer a DNS, and you relay, or can easily relay through known machines every time (which would be about 99% of us), then please publish SPF records. You don't have to use other people's records yourself to reject mail - just publish your own records so that other can reject mail that is purportedly from you, but isn't.

The nice thing about all this from the running a receiving MTA perspective, is you can phase it in. Pretty soon, I will be rejecting all mail that is fails SPF checks, but still accepting for people that don't yet publish records.

So please, do it now, jump over to the SPF link at the top of this mail - there is a webform there which dumbs down creating your SPF record as much as it can be dumbed down, and actually gives you a line to paste into your zone file.

Spam could be all but gone in a week for those who want to reconfigure their mail servers to reject it if those records are publish. Imagine that - effectively wiping out spam almost instantly!

If you won't do it for me, do it for the children, oh won't somebody please think of the children.....

That is, I'm guessing, sourceforge.net's SPF record. It makes it hard/impossible to fake mail as if it were coming from there.

The way I do it is that I create a unique email address in my domain for each registrar I deal with (hostmasternetsol@mydomain.com, hostmastergodaddy@mydomain.com, hostmastergandi@mydomain.com, etc.).

Then, on the server side, I set each of these email address to reject all emails not from those registrars themselves. For example, the Network Solutions one reject emails without any of the following in the "From:" line:

Network Solutions
netsol.com
networksolutions.com
VeriS ign.com

The GoDaddy one rejects emails without:

godaddy.com
supportwebsite.com
gandi.net

And so on. Not a single spam email has made it through my domain contact email addresses since I set this up just under two years ago, and according to my stats, around 419 per week have been blocked (just over 41,000 total messages so far). And yet at the same time, I've gotten every email message when my domains have been coming up for renewal, or when I have made changes to them. So it seems to work well.

You just need to make sure that you include all applicable domain names in the filters, because Network Solutions (for example) sends emails from several domain names.

Of course spammers could get around this by spoofing the "From" line to pretend to be from a registrar. But, in practice, I haven't seen this happen yet. Hopefully SPF or some other such standard will become prevalent enough by the time that happens that it will be a non-issue.

It's probably too late for him, but if you are having to provide an email address for people it might not be a bad idea to use an email redirection service like Pobox.

Who are you or that priest to say that God created the world?

The fuss is that if your morality starts with a wacky 2000-year-old book, and that the benefits of moral behavior accrue in an undetectable and unfalsifiable realm, then you can end up with a perverse morality that causes overpopulation, poverty, disease, suffering and death, to say nothing of raped children.

There is no evidence that there is a god. New evidence, like that which started this conversation, keeps arriving in support of god-free scientific explanations of things formerly attributed to one god or other. We all need to open up our eyes to the obvious truth and let morality start and stop, on this planet, with each other.