Gmail, SPF, and Broken Email Forwarding? 300
alek writes "I recently stopped getting Email from a friend ... which turns out to be related to his use of SPF records and my forwarding to gmail. This 'lost Email problem' may get worse with
Google implementing Domain Keys." Alek is looking for a non-complicated solution to this non-trivial problem; read on below for more details.
"Background: Like many people, I have me@mydomain.com as my public facing Email address. When Email comes into my server, I forward it to me@gmail.com. But since my friend has published SPF (Sender Policy Framework) records that say only his server is allowed to send Emails for friend@frienddomain.com, gmail apparently rejects (silently buries actually!) the Email since it is forwarding through my server. Please note that this is exactly what SPF is designed to prevent — spammers from sending Emails with your address — but it breaks forwarding and has other problems.
What's *really* strange is that if I look at the raw sendmail logs on my server, the Email from friend@frienddomain.com comes in, and is forwarded to gmail ... with an "OK" as the response — i.e. the gmail MTA doesn't reject the message as it ideally should. However, the Email then disappears — it's not even in my gmail spam filter ... so there is no trace of it at all. If my friend sends directly to me@gmail.com, it shows up ... since his domain sends directly and the SPF test is passed. Note that on my gmail account, I associate me@mydomain.com with my me@gmail.com account ... so perhaps there should be a recipient test applied before SPF is tested on the sender ... although this arguably defeats the purpose of SPF.
The logical solution is to configure sendmail on my server to do Sender Rewriting — anyone have an easy FAQ to do this? But many people/domains aren't doing this ... and my Email forwarding to gmail is quite common, so I'm surprised that this issue hasn't gotten more attention. Is there another solution?"
Sunblock (Score:4, Funny)
I prefer SPF 60. It allows me to keep the pasty white, computer nerd complexion that drives the women wild.
Re:Sunblock (Score:5, Funny)
I prefer SPF 60. It allows me to keep the pasty white, computer nerd complexion that drives the women away.
There, fixed that for ya.
Re:Sunblock (Score:5, Funny)
I prefer SPF 60. It allows me to keep the pasty white, computer nerd complexion that drives the women away.
There, fixed that for ya.
. o <-- joke
.
. </sarcasm> tag
. o <-- you
Re: (Score:2, Funny)
Re:Sunblock (Score:5, Funny)
company that makes servers.
Re:Sunblock (Score:5, Funny)
Please adhere to RFC (Score:5, Informative)
The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples.
Re: (Score:2)
Got any real reason that this matters, or should we all applaud you for reaching new levels of pedantry?
(Spam doesn't count, anyone with a domain so easy to pull out of a hat as to be used as an example domain gets bombarded with spam already.)
Re: (Score:2)
Every now and then you'll see a How-To that has absurd example domains. "a.b.c" or "bob.jones.company". I seem to recall an LDAP How-To that had such junk in it.
It's hard to read and really is a pain in the ass. To me it's just like doing a search-and-replace of all capital "S"s to "$".
"example.com" is useful, and available. Use it.
Re: (Score:2)
Re:Please adhere to RFC (Score:5, Interesting)
Re: (Score:2)
Doubly ironic that the article you point to makes the exact same mistake that it warns against: it uses a seemingly random string instead of example.com. Great story, though.
Re: (Score:2)
for instance, if the person who wrote this slashdot story had used "example.com" for his domain, what would you suggest he use for his friends domain?
Re: (Score:2)
for instance, if the person who wrote this slashdot story had used "example.com" for his domain, what would you suggest he use for his friends domain?
example.net
It's just an example in a text message (Score:4, Insightful)
For God's sake. It's just text! RFC 2606 doesn't specify what you're allowed to write in a text message.
If you're actually going to do some testing then it might matter. What matters here is can the reader understand the question. I can. Can you?
Re: (Score:2)
Really? I'm glad you cleared that up for us....
Re:Please adhere to RFC (Score:5, Informative)
Um, no. If you actually read RFC 2606, it is for TESTING. If this guy were really sending test emails to me@mydomain.com, then he would be in violation. Simply posting it on Slashdot as an example is not prohibited.
Re: (Score:3, Informative)
"To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented."
And no, it's not prohibited per se, but it is a good practice so as not to annoy those who own the domains the submitter used.
Re: (Score:3, Funny)
Did you score a 200 on your SAT? Did you even take the SAT? Since your reading comprehension skills are apparently on par with first graders and congressmen, allow me to clarify.
1) The story submitter used 'mydomain.com' as an example domain in his original post.
2) The OP of this thread said 'Don't do that', use 'example.com' instead of 'mydomain.com'.
3) You pointed out (1)
4) You are being rightfully flamed for being such an ignoramus.
Re: (Score:2, Funny)
wow, you posted AC and then posted again. Cool.
Haha, incredible.
MyLongNickName, I present you Select/Copy/Paste. You can do that with almost all the new Operating Systems :)
You are welcome.
Re:Please adhere to RFC (Score:5, Funny)
I present you Select/Copy/Paste. You can do that with almost all the new Operating Systems
not on my iPhone you insensitive clod.
Re: (Score:3, Insightful)
Technically you're right. But I'm pretty sure that if some idiot chose "me@mydomain.com" as his personal email address, he's already used to getting mountains of spam.
Sorry, Swoosh belongs to Nike. (Score:4, Funny)
Re:Sorry, Swoosh belongs to Nike. (Score:5, Funny)
Re:Sorry, Swoosh belongs to Nike. (Score:5, Funny)
deprecated
Re:Sorry, Swoosh belongs to Nike. (Score:5, Funny)
Actually, RFC 0444 has been reserved by the IETF for use as an example RFC number. Your joke should have used that.
Come on, people!
Is there another solution? (Score:5, Informative)
Re:Is there another solution? (Score:5, Informative)
Our company forwards email to google (MX record in the DNS), where it runs through the spam filter and then a forwarding rule (an anything-but-spam rule) sends it on to our mailboxes.
For free...
Re: (Score:3, Informative)
Our company forwards email to google (MX record in the DNS), where it runs through the spam filter and then a forwarding rule (an anything-but-spam rule) sends it on to our mailboxes.
Or you could just use Spamassassin, which properly configured is every bit as good as commercial offerings (and I have actually trialled them to do the comparison). If you put MAIA Mailguard [maiamailguard.com] on top of it, you have a solution that leaves the commercial offerings for dead - per user, server based sensitivity settings, quarantin
^---- what jeffmeden said. (Score:4, Interesting)
Another satisfied google hosted apps customer chiming in. I have a reseller webhosting account that I keep about 10-15 domains on for myself/friends/family which does acceptable e-mail, but I advise everyone to just shove their e-mail over to gmail/a instead.
You get your own hosted mail/webmail service with (currently) 7gb of storage per/account, no preset account limit, POP and IMAP, as well as great spam-filtering.
All free.
And for $50/acct/year you can have 25gb/acct storage, API access to customize it for single-signon and/or gateways, a full Postini implementation, and 99.9% uptime guarantee.
Hate to sound like a shill, but it's a fantastic service and I don't mind pimping it.
Re: (Score:3, Informative)
.. easier to just update your MXs (Score:2)
True..
but if you have a web-presense where you don't want to deal with having another POP/IMAP server to maintain yourself, you can point your MX's to Gmail..
Frankly.. I use google web app tools and love em.
Re: (Score:2)
Simple answer: stop forwarding (Score:5, Insightful)
Effective spam filtering for forwarded email is pretty much impossible, as you lose vital information in the forwarding. Either get rid of your forwarding address, or have it hosted at Google as well. Probably the largest single reduction in spam I've ever made was the week that I got rid of years-old forwarding addresses. If the forwarding address is more important, just get it hosted at Google directly, or tell people to stop using it!
Re: (Score:3, Funny)
Actually, Charlie tells them what they've won. Vanna plays the part of "Jerry Springer's insightful monologue" at the end, except less controversial, less insightful, and it's actually a dialogue with Pat.
Forwarded messages will be fine (Score:2)
Forwarded messages will have all the headers and information to indicate they came from your server.
Bounced messages, where none of the headers are rewritten but it seems to come from your server, is the issue you are describing and it isn't one that I have an easy answer for.
The only solution that I can think of would use greasemonkey and special rules on your server to make it easy
Re: (Score:3, Informative)
Actually, the term "forwarding" applies both to client-forwarding (remailing the mail with all of the headers) and server-forwarding (what you call bouncing.) It's the difference between clicking forward and using a .forward file (hey, why do you think they called it that?)
silently dropping is not unexpected (Score:5, Interesting)
What's *really* strange is that if I look at the raw sendmail logs on my server, the Email from friend@frienddomain.com comes in, and is forwarded to gmail ... with an "OK" as the response -- i.e. the gmail MTA doesn't reject the message as it ideally should. However, the Email then disappears -- it's not even in my gmail spam filter ... so there is no trace of it at all.
While the RFCs specify that an MTA that is dropping should notify the sender in various ways, modern MTAs often violate these parts of the spec, pretending to accept and then dropping the mail and/or failing to send bounce notifications.
This is deliberate. Not sending bounce messages reduces the load on the servers and net (now that most mail traffic bounces). Pretending to accept mail which is actually dropped is a defense against guessing email addresses and probing filters to see what gets past them.
Re:silently dropping is not unexpected (Score:4, Insightful)
It violates RFCs and causes problems like we are reading about now. It needs to stop.
Comment removed (Score:5, Informative)
Re: (Score:2)
No, fuck the spammer. Either respect the RFC, or come up with a solution with at least as much attention as the RFCs were given.
Or, give up and come up with a proper solution from the start, and let traditional email rot.
Re:silently dropping is not unexpected (Score:5, Informative)
No, fuck the spammer.
Following the RFC fucks the innocent bystander, not the spammer. Is following the RFC worth fucking innocent bystanders over?
Either respect the RFC, or come up with a solution with at least as much attention as the RFCs were given.
In the meantime, while you come up with a solution, I'll disregard the RFC for this situation, because fucking innocent bystanders over while the world figures out a 'real solution' isn't acceptable.
Re: (Score:3, Informative)
If somebody has a problem with back scatter then they obviously don't have their SPF records set up correctly. They aren't so innocent. I'm getting spam traffic from their domain.
I'm sorry, Mr Holier Than Thou Standards Guru, but could you please point me to the standard that requires e-mail systems to support SPF?
You'll be there a while, because there is no such standard. Moreover, there probably never will be, because SPF is fundamentally broken in several ways. If you use SPF, either setting it up for your own domains or filtering on it, then you are not part of the solution, you are part of the problem. And it's is a lousy way to filter e-mail anyway, since it's statistically be
Re: (Score:3, Insightful)
The rfc is broken, as it assumes no one would lie in their 'MAIL FROM' field.
Will you fix it for us?
--jeffk++
Re:silently dropping is not unexpected (Score:5, Insightful)
What they should do is reject the email immediately, in which case they don't have to send a bouce email but the mail is properly logged as being rejected. Ofcourse this does mean google will have to do all of their checks before accepting the message which is a bit harder to do but it is the only correct solution for the bounce problem.
Re:silently dropping is not unexpected (Score:4, Insightful)
Either way, you should never silently discard an email unless you are 110% sure it's spam. In all other cases it should either be dropped in the spam folder or be properly rejected. Anything else makes email totally unreliable. (And frankly, you shouldn't entrust your email to a company that thinks it ok to silently drop something addressed to you, but that another issue.)
Re: (Score:3, Interesting)
People violate the RFC because spammers spoof the sender as the people they are spamming, so the bounce goes back to that person and they get the spam. The RFC does not account for this, so fuck it.
Only if the mail admin is incompetent. This comes up every time there's a story about something in mail that's been screwed by spammers.
Receiving mail server should not be sending ANYTHING to the sender's mail address, faked or not. The Receiving server's responsibility is to generate a 5xx error on a permanent error and send that back to the SENDING MTA. The Sending MTA has the responsibility to generate the appropriate mailer-daemon message
Re: (Score:3, Informative)
Re: (Score:2)
That means you Hotmail!
Re:silently dropping is not unexpected (Score:5, Insightful)
It violates RFCs
I'm giving up mods to post this, but it really needs to be said.
People need to stop blaming things on services who pragmatically choose to violate selected aspects of decades-old standards that don't address today's realities. The problem with modern e-mail is that the standard is hopelessly out of touch with modern demands. There should long ago have been a consistent standard that covered things like sender authentication, encryption and signing, formatted messages ("HTML e-mails"), smart handling of errors without treating them all as e-mails in their own right, and numerous other fundamentally broken parts of the original e-mail specs. But there isn't, so people try to do reasonable things and stay as true to the standard as they can without being dogmatic about it when it's obviously a stupid thing to do.
So no, I don't think silent dropping needs to stop under all circumstances. E-mail has never had useful reliability of delivery (another thing a replacement standard should deal with) so you can't count on it anyway. On the other hand, I'm sick and tired of getting a deluge of hundreds of unwanted e-mails in ten minutes because someone sent out a mail with webmaster@my.domain as the sender, and loads of people who were confident enough that the message was spam to block it still sent back a bounce message to an address that is 99.99% likely to have been faked as well in that case. I'm sorry, but that's just antisocial behaviour, and responsible sysadmins should take steps to avoid it: if you're confident enough to refuse delivery, why aren't you confident enough not to reverse-spam the innocent bystander? If you're running a sensible service where a user can whitelist specific senders or switch off spam filtering altogether for specific receiving addresses if they want to guarantee receiving everything, and they've opted in to your spam filtering, this shouldn't be a problem.
Re: (Score:3, Funny)
Hotmail has been doing the same for years... And it is bad bad bad. There is a reason for those RFC's you know. I've had several complaints from people that I was loosing their mail. Checked the server logs and the mails were sent to Hotmail and it replied with a nice message received and accepted. Yet it dropped them afterwards even though it was 100% Ham. Fantastic. I get complaint about their mistakes, it takes me time and effort, and best of all, you can't contact them about it.
Pull instead of push? (Score:5, Informative)
Doesn't GMail offer the ability to fetch your email from POP accounts now? It would probably not be the ideal solution, but perhaps you should stop forwarding and instead start POPping.
Re: (Score:2)
and wtf would one want to enable pop on a server that is already doing IMAP just fine? Maybe google should implement IMAP checking, then I wouldn't have to forward (it's temporary until my own web server is back online, but it certainly is convenient).
Re: (Score:2)
It's not even so much the filtering solution as simply the lack of data to filter on. Google is dealing with billions of messages a day, so their filtering algorithms can end up stupidly accurate.
Of course, those low end hosting solutions would be wise to aggregate their spam filtering data. I know, data privacy issues become a possibility, but whatever. Just use Google Apps For Your Domain and be done with it.
Re:Pull instead of push? (Score:5, Informative)
Or given the box of horrors that is POP, you could try IMAP, which google now also supports.
Re: (Score:3, Interesting)
... IMAP, which google now also supports.
Gmail claims to support IMAP, but if you try really using it, its awful.
Eg deleting an email from my mail client inbox only removes it from the Inbox label, it still stays in AllMail. And deleting from AllMail is impossible, the email reappears in thunderbird in a minute or two. Deleting attachments doesnt work. Etc.
I understand they want to keep my data as long as possible and also that they want to make IMAP work with their Labels, but I don't care I just want an IMAP compliant email account...
Re:Pull instead of push? (Score:4, Informative)
gmail does let you pull via pop3 BUT the scheduler is not configurable. Gmail checks pop randomly when it feels like it. For me it's about every 30 minutes to 1 hour. YMMV
Re: (Score:2)
Or better yet don't do either, just have the e-mail go to gmail. Google Apps for Domains is free, and less clunky than forwarding.
Re: (Score:2)
I'm using that for an old account and trust me, that is extremely slow. As one poster already pointed out, you can just host the email on google instead of forwarding it which is not efficient in the first place.
Re: (Score:2)
That means you have to implement an additional mail server program that does POP, as forwarding only requires SMTP.
Domain Keys doesn't have the same issue (Score:4, Informative)
Domain Keys authenticates that the message was generated by a server with access to the DK private key. Forwarding the message does not affect the originator of the message, so the Domain Key authentication still checks out.
SPF and DKs solve similar issues, but in a much different manner.
Easy -- sign up for Google Apps for your Domain (Score:4, Informative)
Sign up for Google Apps, and then you can have all mail sent to me@mydomain.com be handled by GMail. All you have to do is sign up at http://www.google.com/a/ [google.com] and link your domain. Then point your domain's MX records to aspmx.l.google.com.
In the future, all you have to do in order to get your mail is to go to http://mail.google.com/a/mydomain.com/ instead of http://www.gmail.com (and you can even set it up so that http://mail.mydomain.com CNAMES to your email login page)
Re: (Score:3, Funny)
OMG you didn't use example.com as your domain. You're risking the nerdwrath of that dude above.
FAQ (Score:5, Informative)
You seem to have answered the question already (Score:5, Informative)
This is also known as, "The Problem With SPF." SPF breaks forwarding. This is well known. People who use SPF need to be aware of the ramifications.
The SPF people have created SRS, as you are aware, to work around this problem. It is a complicated and unappealing workaround. I certainly won't do it.
You have three options as I see it:
1) Stop forwarding. It's really a terrible idea. Install webmail on your mailserver. Check out RoundCube, for instance.
2) Wait for people to figure out that strict SPF policies break SMTP too badly for most users.
3) Implement SRS. (this would probably be easier if you were using a modern MTA)
I guess you were hoping for an easy fix, but there simply isn't one.
Re: (Score:2)
Or...
1) Stop forwarding...
...and use Gmail to fetch stored mail instead.
Re:maybe a silly question but.. (Score:5, Informative)
People over-generalize terms quite often, and "forwarding" has different meanings in different situations. Generally the difference boils down to if you're talking about a "server" implementation or a "mail client" implementation.
In this case, the SPF folks are addressing server admins, so by "forwarding" they mean sending the message to a new recipient without altering the headers. This use problably originates back to the old ".forward" files on unix machines, but may go back further. Most server-side implementations use this meaning for "forward".
However, forwarding by hitting the "forward" button most mail clients does something different. That creates a new message with new headers and preserves the old body text. sending with the same headers is called "redirect" in most mail clients.
Isn't it great how mail clients and mail servers use different meanings for the same word?
Even the client/server pair that go together from the same company have this problem. For example, Microsoft - exchange server has forwarding contacts, which forward without header changes, while Outlook clients do change the headers when you hit the "forward" button.
proper forwarding (Score:2)
Proper forwarding should rewrite the SMTP envelope sender (leaving the "From" header intact). There's just no other way to do it that doesn't break with SPF and other things these days.
Yes, that means the new sender address will have to be valid. Yes, that means it'll look like spam is coming from your domain if your forwarding service is easy to abuse. You might also want to preserve what's happened in headers for future reference and debugging uses, and rewrite the SMTP envelope sender to something that m
There is an easy way to do e-mail forwarding... (Score:3, Informative)
There's an easy way to do e-mail forwarding, which unfortunately is wrong. We no longer live in a world where you can just create a .forward file with the destination address in it (unless it's on the same server).
If you're going to run your own mail server, there are things you need to do if you want it to run correctly. One of them is that if you are forwarding to a mail server that does SPF, you need to do SRS. Though you probably also need to be doing all the spam rejection on your mail server as well, because otherwise you may be allowing mail through that you wouldn't otherwise.
For example, say that your server doesn't check SPF, and you do SRS. Now you're basically bypassing the destination server's SPF checking.
How to do SRS? I would personally probably just change my .forward file from the destination address into a small script that re-injects the message with a different envelope sender, but I'm sure there are already scripts that do this and much more fancy....
Ideally, you probably just want to move your mail for your domain directly to google, as another repondant says. Don't have it shunting your your own server if at all possible. If you have mail that you want handled directly on your server, either forward it from gmail to your home machine, or use a different domain ("address@homebox.example.com").
Sean
Re: (Score:3, Interesting)
How do you deal with the problem of being blacklisted as a spammer if you end up forwarding lots of spam mail off of your domain? Remember, SPF itself doesn't address the problem of spam, so the fact that you're checking SPF doesn't matter a lot in this regard.
Gmail Is Broken (Score:2, Flamebait)
Gmail has been silently dropping emails for as long as I remember. It's broken, and that's yet another reason I don't use it.
Correct the Envelope Address (Score:2)
I am not rereading the specification, so I might be wrong.
SPF probably checks the Envelope Address and not the From: address which are not the same.
The envelope address is the address that the SMTP client says to the server who is the sender,
the From: address is what is in the message header.
Simply altering the Envelope Address to a valid mail from your server and google wont complain anymore.
The solution, Return Path Header (Score:4, Informative)
SPF will validate the Return-path header if there is one instead of the From: address.
Unfortunately, I don't know how to make either sendmail or postfix insert a return path when they forward an e-mail, but the easy work around is to install mail list software as your forwarder. You can create a mailing list as your incoming e-mail, with only 1 mail list member, (which is your g-mail account). Mail list software will automagically insert the appropriate return-path header that is needed in this case.
DomainKeys DOES NOT HAVE THIS PROBLEM (Score:3, Informative)
DKIM and DomainKeys work in a fundamentally different way. The message is SIGNED. Hosts are not indicated one way or the other. So any DKIM signed mail can transit any number of hosts provided they don't modify the signed sections.
SPF has no such luxury unless implemented in a much more advanced manner in terms of the senders publishing. And it's not GMail's fault for following the SPF records as published, they should do a better job of rejecting early rather than just /dev/null-ing the email though.
How to make it work (Score:5, Informative)
For this example, I'm assuming that your email is joe@example.com and your gmail address is joe-example@gmail.com.
Create an alias (/etc/mail/aliases) for the address that get's forwarded to gmail.
joe: joe-example@gmail.com
Also create an alias for <foo>-owner:
joe-owner: joe
Sendmail will look for this special <foo>-owner alias whenever sending mail to the <foo> alias, and use it as the envelope sender on the outgoing mail. So any mail that is sent to joe@example.com will be resent by sendmail with a sender address of joe@example.com. The header addresses will remain unchanged, so hitting reply will still go to the right person.
Is this the solution to all SPF forwarding brokeness? Of course not, but it's a surpisingly simple solution to a number of common forwarding situation. Note that you better be careful about spam filtering on your machine, or your mail server (your sender's address) will appear to Google as a source of spam, and might get filtered.
Re:How to make it work (Score:5, Informative)
It's owner-<foo>, not the other way around. So the aliases example should read:
joe: joe-example@gmail.com
owner-joe: joe
See the aliases man page [freebsd.org] for further details.
You insensitive clod! (Score:4, Funny)
Regards,
Joe Example
SPF, Gmail, and SRS (Score:5, Informative)
Since you are running your own SMTP server, you signed on to be a sysadmin. I am replying to you as a fellow sysadmin and I'll give sysadmin-style answers. Please don't take my response to be negative in any way, as I'm trying to help.
The logical solution is to configure sendmail on my server to do Sender Rewriting [openspf.org] -- anyone have an easy FAQ to do this?
If you follow the link that you just gave for Sender Rewriting, it answers your question. "Implementation" links to modules, source, and configurations.
But many people/domains aren't doing this ... and my Email forwarding to gmail is quite common, so I'm surprised that this issue hasn't gotten more attention. Is there another solution?"
I say that you don't know how many people are implementing SRS, nor do you know how many forward e-mail to Gmail. Let's stick to the basics before giving up so readily. I take it that you absolutely do not want to give up carte blanche forwarding from your own SMTP server to Gmail; so I'll tailor my reply to that.
But since my friend has published SPF (Sender Policy Framework) records that say only his server is allowed to send Emails for friend@frienddomain.com, gmail apparently rejects (silently buries actually!) the Email since it is forwarding through my server.
Your friend has published an SPF record because he doesn't want people forging his domain in the envelope-sender field. This is a common spam tactic that ruins the reputation of someone's domain, either through spammer apathy or sometimes pure malice. Your e-mail forwarding (especially since you run your own SMTP) to Gmail is out of pure convenience to you and is unnecessary, so don't ask your friend to drop his SPF record.
There are two ways to solve this:
1) Have your friend add your SMTP server to his SPF record.
2) Implement SRS if you want to solve it once and for all. If you follow your own links, there are explanations, examples, and actual code. You haven't said which SMTP server you're running, so you've limited the responses people can give you for your situation.
I publish SPF records for my domains. There isn't anything "broken" about wanting to protect my domains' reputations from forgery. Very few people have a problem with forwarding that they didn't create themselves. This exception I'm talking about is people who have old university accounts (or similar) which only allow e-mail checking through a shell account and forwarding purely through a ".forward" file (or similar), with no POP, IMAP, or administrative access. This is not you. But for anyone who this describes, because of the draconian service policies, they shouldn't be giving out that e-mail address to new contacts, publish on papers, etc.
My SMTP server checks SPF, but not DK. With SPF, the forged domains are instantly rejected, requiring minimal overhead. DK requires reception of the entire message (because the headers are in the DATA phase) in order to validate the message, on every message -- this uses unnecessary network bandwidth, and it places an extra load on my system since it would have to calculate and verify signatures for every single message. Maybe that's not an issue for you if you only receive a handful a day, but I receive thousands. Spammers know that including fake DK info in a message and then sending millions of these is effectively a Denial of Service attack on the servers that indiscriminately check DK signatures.
I also use backup relays. For the relays that are not under my control and don't implement SRS, I simply bypass SPF checks from those IP addresses.
About Google silently dropping your e-mail: Keep in mind that with your carte blanche forwarding, you're also forwarding spam. You are essentially spamming Gmail, even though it is you simply forwarding e-mail to your own account. It is difficult for Google to know this without human intervention or implementing some co
Re: (Score:3, Informative)
Replying to myself because I just spotted the article submitter did mention "sendmail" as his solution. There are plenty of solutions readily available for sendmail. Like I said above, he can follow his own links for that information, and many others here have helpfully posted sendmail solutions also.
I don't know why my eyes filtered out sendmail. Odd.
Does business take gmail addresses seriously? (Score:5, Informative)
One very good reason not to have your email address @gmail.com, if you are using it for your business, is that a LOT of businesses, wholesale vendors, even the federal government will not accept an @gmail.com address because of the large number of frauds associated with free email accounts (not just gmail, but also hotmail, yahoo mail, etc.) For example, this last tax season the federal govenment would not accept a gmail account for notification of your tax return status when filing electronically.
It is much better from a business standpoint to have your own domain and email sent to your domain. If your MX points at gmail, that's okay. Just don't make your email address me@gmail.com if you want to be taken seriously.
Fail/HardFail vs SoftFail (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
SPF stops phishing, and FROM forgery, not spamming, as the original poster already mentioned.
It's been a while since I read SPF specs, but there is a header you can add to the e-mail that identifies the sender domain of the forwarded e-mail, which will fix the SPF issue when you forward the mail from your server to gmail.. Unfortunately, a) I forget what the header is b) I have no clue how to configure sendmail so it inserts the header when it forward e-mails. I would be interested in these answers however
Re: (Score:2)
Wouldn't the existence of such a header break SPF? Spam could just come "forwarded" from the spoofed sender.
Re: (Score:2)
Not really, the client is able to tell that there a discrepenc in From and Sender: and notify the user appropriately...
Again, SPF was never to stop spam, just prevent domain forging.... btw, believe it not, the header you have to insert is Return Path: which means I have a solution for the OP
Support SPF (Score:4, Insightful)
I put SPF on my domain not because I think that it'll solve the world's spam problem, but because it helps reduce the (large) number of bogus returns that come back to my domain (the more recipients that have SPF checking on, and realize that some sender in China isn't a legitimate source for emails from my domain, eats and discards the message rather than bouncing back some wasteful return spam to me).
SPF is great. It isn't a total solution, and there are negatives, but it certainly is better than the anyone is anyone free for all.
Re: (Score:2)
SPF won't do anything to stop spam anyway (despite what some of it's proponents say.) It needs to die a quick death.
In case anyone doubts this, here's a brief list of domains that are owned by spammers that actually have SPF configured, as well as forward and reverse DNS for their dedicated IPs. Each of these domains also has a web site with an "unsubscribe" form on the front page. These are just a few of the domains that have tried to send me spam in the last couple of days.
amd-computer.com
bionona.com
bounce-spring.com
building-clam.com
building-pearl.com
cartoonchristmasornaments.com
catch-history.com
champion-clam.com
cham
Re: (Score:2)
gohan-saiyan.com
goku-saiyan.com
goten-saiyan.com
vegeta-saiyan.com
That isn't spam, that's a feature!
On a serious note, what the hell kind of spam are you getting from domains like that?
Re: (Score:2)
Nothing to do with the actual domain name used; they're obviously pretty random.
Actually I'm not sure what kind of spam they're sending, since I've been rejecting it. I set up a script to check the reverse DNS hostname of the connecting host, and if it matches a particular pattern, send an HTTP query to see if that host has a web site, and if so, whether the web site has an unsubscribe form on the front page. If all these conditions are met, the IP is cached in a database and the message is rejected; othe
Re: (Score:2)
SPF isn't supposed to stop spam. It is supposed to stop backscatter from people spamming with your email address in the "from" field.
If the SPF doesn't match, that means the email has a faked "from" field, so the receiving server shouldn't bounce it back to you. In that respect, Google's approach of silently eating the mail is probably the "correct" approach. Perhaps it should put it in the spam folder though.
Re:Dump SPF (Score:4, Informative)
Of course it won't stop spam. It wasn't designed to. Its purpose is to stop joe jobs [wikipedia.org].
Re:Easy answer (Score:5, Insightful)
That's outstandingly unhelpful. How about attaching a link to a decent SRS implementation [srs-socketmap.info]? Or sending them to OpenSPF [openspf.org]?
Randomly throwing down on people legitimately asking for some technical help is a big problem in the OSS community. Whether or not /. is the appropriate place to ask this question is debatable, but since it made the front page and there is no helpful SRS faq on this site, might as well direct them somewhere.
Re: (Score:2)
Re:I knew .. (Score:5, Insightful)
At first I was wondering why they hell someone that had a working email server would shuttle it through Gmail, but then I read about using the spam filters, etc.
While that sounds good on the surface, is anyone out there not a little apprehensive about having all your email, particularly if you're a business, going through and being stored on their servers? I mean, someday Google will bend completely for govt. wanting to search all emails for 'terrorists' activities, and God knows who else will too.
I guess I'd want a bit more privacy on my emails, especially if they contained sensitive or proprietary information. I know...they're in plain text and could be intercepted if not encrypted, but, this is altogether different. It is stored on google's servers and there for easy data mining.
I'm getting ready to dig out my old email server post Katrina...can you not use procmail and spamassassin to filter spam as effectively as Gmail does?
Re: (Score:3, Insightful)
1) stop using email altogether.
2) you need to get to a drug rehab center... cocaine is a hell of a drug
Re: (Score:3, Insightful)
I agree with cayenne8, but not quite for the same reason. I've been using my GMail account for a while now and loving it. There's nothing incriminating in the email, per se, but there probably would be enough to do a bang-up job of identity theft. More than the government, I'm worried about Google misplacing an unencrypted backup tape with my account on it.
The reasons I still use them are that I think the quality and utility outweigh the risk, and because my much-smaller web hosting company is more likely t
Re: (Score:3, Insightful)
The reasons I still use them are that I think the quality and utility outweigh the risk, and because my much-smaller web hosting company is more likely to do something bird-brained than Google is.
That's actually a foolish remark. Use google to search for things like "gmail outage" or "gmail issue". My favorite is "gmail security issue" with over 100k results.
I've heard stories personally about people logging into gmail and ending up in someone else's Inbox. Yes, that's right, full access to someone else's email. [slashdot.org] Or how about another goodie: mass deletes of random emails. [oreillynet.com]
I don't understand why people have the idea that Google is better then competent system administrators - it's just plain fooli
Re:I knew .. (Score:4, Informative)
My e-mail goes through my domain, forwarded to Gmail, and then is downloaded to my computer via POP. Gmail is my offsite back-up (that is accessible from anywhere) and home is where I do most of my mail viewing/sending. All of those GB of space, local copies in case Gmail fails, remote copies in case my computer fails. And assuming Google is "not evil", then I should be ok.
Layne
Re:I knew .. (Score:4, Interesting)
Short answer is, no. Google's large amount of incoming email, their patented algorithms, and the huge data mine they're sitting on give them a unique ability to provide very through and high-quality spam filtering.
Of course, that isn't to say that one can't do a half decent job with spamassassin, it just won't be as good as Google's filter.
Re:I knew .. (Score:4, Interesting)
I have a gmail account, I get a handful of spam a week slipping through. I don't ever advertise my gmail account, however it's a common enough username with no numbers so dictionary attacks would hit it.
I have a private email server, with clamav running spamassassin and postfix tuned to prevent spam (Simple settings really), I get even less spam than my gmail. This address has been published for years on multiple websites, I use for just about everything, in cleartext on websites that are spidered.
In my experience you can do just as well or better than gmail without any headaches and a simple setup. Expect a few hours initial setup, and maybe an hour every 6 months to check if you're missing something the auto-updates can't update. It's been like this for a few years so far.