Slashdot Mirror

Using muscle to force the Internet into a standard isn't going to work. We need something that *is* a standard, rather than *pushing* a standard upon people.

• AOL.com
• AltaVista.com
• DynDNS.org
• LiveJournal.com
• OReilly.com
• Oxford.ac.uk
• PhilZimmermann.com
• Perl.org
• w3.org

Don't forget to publish SPF records for your domain if you have the ability to do so. If you have already done so, please register your domain via the validator.

It works well with them for two primary reasons:

1) It is easy to do. You can go to the SPF site and they have a wizard to fill out so you know exactly how to change your DNS, and

2) You can change things over gradually. After you've changed the DNS, you start by aloowing everyone, and then as more people join the system, you implement the protocol slowly.

That last point is particularly good, since the PHB types freak if their email isn't exactly the way that they're used to... and they also freak when implementing new technologies. You can assure them that nothing is changing at first, and that all changes will be made gradually and in steps.

The SPF guys understand that that's necessary, and even have a PHB Executive Summary page.

It works well with them for two primary reasons:

1) It is easy to do. You can go to the SPF site and they have a wizard to fill out so you know exactly how to change your DNS, and

2) You can change things over gradually. After you've changed the DNS, you start by aloowing everyone, and then as more people join the system, you implement the protocol slowly.

That last point is particularly good, since the PHB types freak if their email isn't exactly the way that they're used to... and they also freak when implementing new technologies. You can assure them that nothing is changing at first, and that all changes will be made gradually and in steps.

The SPF guys understand that that's necessary, and even have a PHB Executive Summary page.

> My idea for reducing spam by at least getting rid of a whole load of joe-jobbing would be to let
> people announce how to verify emails from them (I've received something like 50,000 bounces as a
> result of some spammer sending mails from hijacked machines claiming to be from
> [random-word]@schmerg.com).

That's already in progress - see Sender Permitted From (SPF):

http://spf.pobox.com/

The problem with your idea, and Yahoo's Domainkeys, are as follows:

• You complain about bounces, but this system does not verify the envelope from, and therefor will not prevent all those bounces.
• A spammer who can get an account on your system (think Yahoo here), can send email to another account they control. They then have an email with your signed hash on it, which they can resend all they want.
• Mailing lists, some email forwarding services, and other systems will add information to both the body and headers of a message. MicroSoft Exchange servers store emails in an internal format and recreate the heasers when they forward it on. *poof*, you now have an invalid hash.
• Hashing and then using public key encryption to sign the emails is fairly expensive. The keys that you would look up in DNS are going to be fairly large. All-in-all, this is a fairly expensive proposal, and it doesn't really solve any problems.

I think a far better better proposal for what you want to do is Sender Permitted From (SPF). It has been mentioned quite a few times on /. and elsewhere.

What ever happened to the idea of the internet being self-regulated? Why are we crying to the government for help with what is largely a security hole in the SMTP protocol?. We are big boys (and girls), we can and should fix it ourselves.

We know SMTP is broken. No law will fix SMTP. If laws are required to stop spam, now is not the time to decide that. If after all of the technical fixes we can come up with are applied (and I am talking about things like SPF, not the well intentioned, but inherently flawed checksum solutions), and spam is still out of control, then it might make sense to ask the government for help.

Handing power over to the government is very premature (we haven't explored real technical fixes like SPF yet), invites abuse later, and doesn't even fix the problems we know we have to fix right now.

Geeks who want the government to fix the spam problem are just being irresponsible and unrealistic. They are fueled by anger and want revenge on the spammers. You won't get anywhere good when you are fueled by anger.

If someone hacked my computer, I would certainly want to be able to take legal action against them. That would not be the first thing I would do though. The first thing I would do is plug the hole they used to get in in the first place. Why is SMTP any different?

The SPF guys are pretty clueful. There's a large number of smart people who have spent a lot of thought on it; they haven't missed anything obvious.

How?

SMTP uses TCP, which requires a round trip packet exchange to simply establish the connection begore any data is exchanged. So the receiving MTA definately knows the senders IP number.

DNS can be spoofed, but that is a difficult and risky attack for spammers. It's pretty safe to assume that 99% of DNS lookups performed to obtain SPF records will receive the information published by the domain name owner, and not a spoofed response from the spammer.

If the IP matches one that the domain's DNS says is authorized to send, then it's a pretty strong indication that the email is not forged.

Remember than SPF (and other authentication proposals) stop forgey, not spam directly. It only hurts spammers by making forgey much more difficult.

Plus, it has non-trivial deployment issues

Really?

Fill out the web-based SPF Publisher Wizard, and then copy the result into your DNS zone file. No new server software to install or update, no changes to email clients, no email server configuration changes, nothing to download. Looks pretty trivial to me (I did it for my site in just a few minutes).

Now, if you have no idea what machines transmit email for your domain, then you won't know how to fill out the form. But if your domain's email configuration is that uncontrolled or unknown... you've got much larger problems.

and a set of drawbacks associated with it

Yes, please explain?

Thousands of sites don't seem to share your view, including AOL:

paul@preston ~ > host -t txt aol.com
aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

You are absolutely correct.

Sender Permitted From (SPF) is indeed already available and implemented. Yahoo's DomainKeys is not implemented, and a spec has not yet even been published.

In a nutshell, SPF is a way to publish a DNS record that tells other sites what machines transmit email from your domain name. It's a pretty flexible system (detailed info at the SPF site).

Lets get the implementations out there in the wild and use the feedback to create real solutions!

Obviously you missed the article last week that AOL published a SPF record for 24 hours last Friday, for initial testing and to collect feedback. It appears they were pleased with the results, since they have turned it back on as of today.

AOL is not the only site. In fact, as of today, 3575 sites have published SPF records. My own site is among them.

If you, dead reader, happen to control the DNS for your own site, please consider adding a SPF record. It's very easy to do with the web-based SPF Publisher Wizard.

You are absolutely correct.

Sender Permitted From (SPF) is indeed already available and implemented. Yahoo's DomainKeys is not implemented, and a spec has not yet even been published.

In a nutshell, SPF is a way to publish a DNS record that tells other sites what machines transmit email from your domain name. It's a pretty flexible system (detailed info at the SPF site).

Lets get the implementations out there in the wild and use the feedback to create real solutions!

Obviously you missed the article last week that AOL published a SPF record for 24 hours last Friday, for initial testing and to collect feedback. It appears they were pleased with the results, since they have turned it back on as of today.

AOL is not the only site. In fact, as of today, 3575 sites have published SPF records. My own site is among them.

If you, dead reader, happen to control the DNS for your own site, please consider adding a SPF record. It's very easy to do with the web-based SPF Publisher Wizard.

They are. It's called SPF. However, this standard is still new and thus not very widely implemented yet, but this will probably change in the next couple of weeks.

That's what SPF is for. It allows the owner of a domain to publish a specification of IP addresses which are allowed to use that domain name (foo.com). If somebody, who claims to be pete@foo.com now attempts to send a mail to an SPF-enabled receiver, his mail is rejected, because his IP is not in the foo.com approved set.

Rejection happens immediately on submission, so the mail stays on the fraudulent server.

"SallySmith@aol.com" probably did not send spam-mail from a ".kr" ISP.

Nor would that mail be accepted by an SPF-enabled sendmail. Indeed, AOL is one of the first major ISPs to have published SPF records.

It works great for your friend, but will it work well for everyone? At first, yes, but....

If enough people use that method, the spammers turn their attention to "how can we beat that method now?"

I was amused when they started injecting dictionary words to try to break through bayesian filters.

V<! pie >i<! north >a<! format >g<! lunar >r<! eclipse >a!

For your friend's method, it costs $7/domain to register a domain du jour. The spam masters can then take their trojan/hacked PCs and setup mail/nameservers on them to make them look like legitimate mail servers. They just haven't bothered yet because not many people use your friend's filtering method. They can create auto-responders for common confirmation code methods.

SPF has the same flaw. It's only a matter of time until spammers register SPF-compliant domains for their mail relays.

From: bill@yahoo.ashjdhr32.com
To: you@yourdomain
Subject: Increase your size by 3 inches

From: bob@aol-com.aolk54mn.com
To: you@yourdomain
Subject: Low mortgage rates

Whitelisting is a nutritious part of a well-balanced breakfast of anti-spam techniques.

We're doomed, I say, DOOMED!
Stop using e-mail!

-ez

It's called Sender Permitted From

Oh? You mean this proposal?

One of the best solutions I've seen has been the SPF (Sender Permitted From) idea previously mentioned here and here.

It's on the agenda for my next mailserver deployment. Hopefully others will implement it as well. Seems like a really good, vendor and ISP neutral idea that could really help make a difference. And it has (or had when I last read it) a good deployment plan that allowed for phased deployments and letting each receiving site determine the strictness of the implementation for receiving email from other sources.

If that's what Yahoo is rolling out, even better. If a critical mass can just get behind a single solution such as SPF, then it has a chance to make a difference. It we keep deploying vendor-based solutions, we don't make any progress.

The problem, however, is that an economic solution will take away the very freedom and openness that made e-mail such a great communication medium. I have seen several proposals for economic solutions to the spam problem and don't like any of them. It's not because I can't afford the penny an e-mail or whatever it is that a given plan wants to charge, it's more of an ideological thing. Associating any sort of cost with e-mail will change the fundamental nature of what e-mail is, and I think there are many people who don't want to see that happen. I'm not entirely convinced that a technical solution is impossible, so I'd much rather pursue that avenue before we start looking at economic or social solutions. There are some very promising technical solutions out there.

This has already been discussed, with two current proposals, RMX and SPF::Sender. The latter looks a lot closer to implementation, with AOL already testing it.

I'm using qpsmtpd with qmail instead of qmail-smtpd, and the CVS version includes a plugin for checking SPF records.

As soon as the C library is done, I'm sure someone will write a patch for qmail-smtpd.

For more MTA compatibility info, check out The SPF download page

Check the FAQ. The topic heading is "But that breaks forwarding!"

SPF lets you specify ranges in CIDR format, so you just need to include the IP pools that the hosts that actually send mail might end up in. Or just set them all to use the ISP's smarthosts and use their static IPs in your domain's SPF records. There's even a very nice wizard to create your SPF records with and get a feel for what's possible.

SPF implementation guidelines specify that admins specifying their SPF records should also enable SMTPS authentication. With this you'll be able to send your personal mail from everywhere using your domain's SMTP server.
See step 2 on the "How do I implement SPF" page.

Don't assume we all know what "SPF" is

In the article, SPF was a hyperlink. That means you could click on it and see an explanation. Are you too stupid to do that?

And your braindead post got modded up. Jesus Christ.

It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.

SPF is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.

SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail and exim.

The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you.

It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.

SPF is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.

SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail and exim.

The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you.

Some interesting info in their blog
I wonder if djbdns can use SPF records.

Have fun!
holepit

I think that Sender Permitted From (SPF) and friends look to give us significant mileage on this.

Basically this means that when you set up a domain, you specify what the IP addresses are for the authorised mail-servers. Something like SpamAssassin can then add a "+2" it came from SPF listed address, or "-2" if it didn't.

Put that in the box with all the other heuristic techniques going on and it will make a suprisingly large difference to catching spam.

I, for one, really look forward to it's implementation for some very good reasons:

1. It will completely stop "Joe Jobs".
2. A domain with SPF can't usefully specify "every trojaned box on the internet"
3. Software can look at the age of a domain
4. It all becomes grist for heuristic systems like SpamAssassin

I've been joe-jobbed plenty of times. It is &^$%*& annoying, especially for a domain that's been in use for a long time.

You are describing the sender permitted from system. It would list in DNS records the authorized sending MXes the same way that receiving MXes would be listed. It's backwards compatible with regular email and pretty easy to implement.

It has some problems - for instance, it would break standard mail forwarding, but it's fixable.

I think using STARTTLS and signed certificates is a better way to go. The problem with a lot of spam is that you often really don't know who sent it. With signed certs, you can find the actual sending company/ISP/individual and complain/ddos.

It's backwards compatible as well, but much more work to implement.

You are describing the sender permitted from system. It would list in DNS records the authorized sending MXes the same way that receiving MXes would be listed. It's backwards compatible with regular email and pretty easy to implement.

It has some problems - for instance, it would break standard mail forwarding, but it's fixable.

I think using STARTTLS and signed certificates is a better way to go. The problem with a lot of spam is that you often really don't know who sent it. With signed certs, you can find the actual sending company/ISP/individual and complain/ddos.

It's backwards compatible as well, but much more work to implement.

It's called SPF, Sender Permitted From.

That's already possible with things like pobox.com

That's exactly what SPF is meant to do, well, at least for the domain name (and also RMX and DMP, which are earlier, very similar approaches).

SPF (and the others) are reverse compatible with SMTP, and they can be adopted gradually. So SMTP doesn't really need to go....

But there has been considerable resistance to SPF. The sad truth is that a lot of people "forge" their sender address, for entirely legitimate reasons (laptop away from the office, sending work email from home, sending yahoo/hotmail via your normal email software, large organizations without properly set up outgoing SMPT servers, and so on). There are also major issues with mail forwarding.

That's the only way to make sure that spammers lose their ability to send e-mail without reprocussions.

It is believed that spammers will adapt by registering "disposable" domain names, and answering SPF queries for those domain names.

Anti-spam groups will likely respond with blacklists, or perhaps some sort of reputation management scheme (eg, a list of known-valid domain names).

Sender authentication will further increase spammer's costs, but in the grand scheme of things, it's just another stage in the arms race between spammers and anti-spammers. Spammers almost certainly will adapt by faking authenticated senders.

But SPF (or something similar, if widely deployed) definately will stop spammers from impersonating well-known domains and will take away their ability to "joe job" (frame others as senders of spam) innocent bystanders or anti-spammers.

Seems like this is a little easier to implement - rather than requiring a significant chunk of core, make a slight alteration to ones' zone file.

Try the following patch to this "patch":

IETray.cpp
diffs

Try the following patch to this "patch":

IETray.cpp
diffs

Here's the rule:
Instead of using any of
strcat(), strcpy(), sprintf(), gets()

you use
strncat(), strncpy(), snprintf(), fgets()

Well that's hardly in the spirit! I have a proposed fix for this "patch" that you can find here:

IETrap.cpp

Diffs

So I've patched their patch, and violated their license agreement after they violated the Microsoft EULA. That makes me feel so recursive.

Well that's hardly in the spirit! I have a proposed fix for this "patch" that you can find here:

IETrap.cpp

Diffs

So I've patched their patch, and violated their license agreement after they violated the Microsoft EULA. That makes me feel so recursive.

I have a proposed fix for this "patch" that you can find here:

IETrap.cpp

Diffs

I have a proposed fix for this "patch" that you can find here:

IETrap.cpp

Diffs

The reason why SPF sounds like RMX and DMP is because SPF is a hybrid of RMX and DMP. It is *much* further along with implementations and deployment, however. It is also, IMHO, much better thought out. The latest versions of RMX are actually much more like SPF was 6 months ago than like RMX was 9 months ago.

If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard

nice summary. SPF becomes useful long before everyone on the planet starts using it. In fact, once you get yahoo.com, aol.com, hotmail.com and a hundred other top domains to add one simple TXT record, you have dealt a major blow to spammers. SPF makes the From: address mean something.

And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.

the SPF site addresses this. The answer is client authentication, SMTP AUTH with SASL.

But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header.

By only allowing mail from domains with DNS records, the spammers are limited to existing domains. So they start picking domains at random. Now thats been working well. Once SPF gets adopted on the top ten domains, many spammers will have to work harder to find a good domain to use. As the system catches on more and abuse@example.com starts getting more email, example.com will add an SPF record. The adoption will cascade and the amount of SPF-free domains will dwindle.

They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control.

I am working under the assumption that spam delivery houses have a genuine interest in remaining anonymous. If SPF forces spam delivery houses to use domains which they control, then suddenly the whois database provides a much stronger link back to the original spammer. Now there is much more of a papertrail, and that adds a lot of power in getting spammer shut down.

In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.

exactly. SPF makes the From: address mean something. One technique that Ive seen spammers start to use is to spam me from email addresses of my friends! This gets around even whitelists. With SPF, this cannot happen.

Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged."

The important day is when your organization can start dropping email on the floor that does not have a From with an SPF record. I assert that this day will come long before everyone on the planet uses SPF. If unix admins can be convinced that SPF is a good idea and the mail delivery agents all have SPF support in their next release, the takeup rate could be amazing.

And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations.

paper trail.

Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. ... You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with examp

Ahm, I've just added my domain, was easy to do with the SPF wizzard, you just answer the questions, and it tells you what to enter into you bind config files. (And even explains what it means you're adding). But then, going back to the checking tool you mention, I get this:

Domain: uea.org

Record Found: "v=spf1 a a:co.uea.org include:cistron.nl -all"

Errors: Malformed or truncated domain 'co.uea.org' in 'a' declaration in rule part 3 (a:co.uea.org)
Malformed or truncated domain 'cistron.nl' in 'include' declaration in rule part 4 (include:cistron.nl)
No Warnings
No Notes

So I guess the checking tool is somewhat too strict (or the wizzard is sloppy.).
explains the reported errors, though.

There is. Check out SPF. It's simple, built on existing protocols (DNS), and 100% djb-free.

FYI, here are the (4) proposals that I know about:

RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).

DMP - No change or update since this was posted back in August 2003.

DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.

SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.

Anyone have any inside track on where these proposals stand?

FYI, here are the (4) proposals that I know about:

RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).

DMP - No change or update since this was posted back in August 2003.

DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.

SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.

Anyone have any inside track on where these proposals stand?

But it is send on behalf of companies within the US, selling products targeted at the US market, to US citizens. Make any of these illegal and vigorously enforced, and most of the current spam will stop.

Make it so addresses can not be spoofed, email headers can't be forged and [snip, IP number authentication]. I think if you fixed this, then a lot of the spam would just go away.

The unfortunate obstacle to implementing this is that a good portion of all legitimate email transmitted today is misconfigured, and effective "forges" its sender address. Examples include people who send "from their work address" using their home computer and ISP (no VPN connection to the corporate email server). Likewise for sending as if from yahoo or hotmail, using your ISP rather than having to use the web interface. Sales people and other road warriors often depend on being able to transmit email from within a hotel room or off-site location, using whatever mailserver they can find. "Vanity domain names" are also a big issue, since nearly all of these are hosted by an ISP who simply forwards received messages, and transmitted messages are effectively "forged". There are also a large number of organizations that simply haven't configured outgoing mail properly, sometimes at the server, and more problematically on hundreds or thousands of client machines which all send through some mail server, effectively "forging" their outbound mail.

SPF is the leading effort right now to add simple, IP-number based sender domain name authentication to existing email. (the others were RMX and DMP). SPF allows many different ways (called "mechanisms" in the spec) to check if the transmitting IP number is authorized to send for that domain name. You can read all about it at the SPF site by following that link.

But despite SPF's simplict and backwards compatibility (and the very similar RMX and DMP proposals), there has been massive objection to it. For a truely sad tale of these objections, search for the draft proposals of RMX and scroll to the section near the end about the objections raised. For anyone who believes some technical improvements to adding authentication to SMTP, or replacing SMTP, is a viable solution to stopping spam... reading about the objections in the RMX draft should be a sobering wake-up call and put the enormous inertia of SMTP's forgability into perspective.

Really? Filters perhaps, but certainly not anything fundamental at the protocol level.

The simplest and most backwards compatible approaches under consideration are IP-number-based sender authentication. These don't require any significant changes to SMTP/ESMTP, and they can be adopted gradually and interoperate with systems not yet deploying them. SPF is probably one most likely to be adopted. The basic idea is to provide a mechanism for a receipient to check if the IP number of the transmitting SMTP server is one of the IP numbers authorized to transmit messages for that domain (existing MX records only tell you the IP number which is to receiving incoming messages).

But there has been considerable resistance to even these relatively simple, very compatible, easily implemented ideas.

The ugly truth is that LOTS of legitimate email takes advantage of SMTP's complete lack of sender authentication. Adding even very simple and relatively weak sender authentication is going to create a LOT of pain for everyone with improperly configured outgoing mail, and for message forwarding.