SoylentNews is people
SoylentNews
from the spammers-should-be-{insert-punishment-here} dept.
Peter N. M. Hansteen asks the question, "Does Your Email Provider Know What A "Joejob" Is?" in his blog and provides some data and discussion. He provides anecdotal evidence which seems to indicate that Google and possibly other mail service providers are either quite ignorant of history when it comes to email and spam, or are applying unsavory tactics to capture market dominance.
[Ed Note: I had to look up "joe job" to find out what it is. According to wikipedia:
A joe job is a spamming technique that sends out unsolicited e-mails using spoofed sender data. Early joe jobs aimed at tarnishing the reputation of the apparent sender or inducing the recipients to take action against them (see also e-mail spoofing), but they are now typically used by commercial spammers to conceal the true origin of their messages.
]
(Score: 4, Interesting) by Whoever on Monday April 25 2016, @12:38AM
I believe that you are correct. The problem is that Google allows this historic data to override SPF. When I changed my outgoing mail server, my emails sent to gmail started going into spam folders, despite having valid SPF.
I think that many large email providers just make sure that they accept emails from other large providers and they don't care beyond that. The end goal for Google is to make it impossible to run your own mail server and hence increase the number of domains hosted at Google.
I have set up SPF, DKIM and DMARC records. I think that they make very little difference. For support of this proposition, look at the scores for DKIM in SpamAssassin.
(Score: 3, Interesting) by TheRaven on Monday April 25 2016, @08:37AM
I have set up SPF, DKIM and DMARC records. I think that they make very little difference. For support of this proposition, look at the scores for DKIM in SpamAssassin.
I'm not sure about the more recent things, but someone did a study a few years after SPF was introduced and found that over 90% of domains with valid SPF records were owned by spammers. It's easy to register a new domain and add SPF records.
That's fine, because SPF was never intended to say 'this mail is not spam', it was intended to say 'all emails that come from the wrong server are spam and if messages from this domain are spam then it's safe to bounce them back to this server'. In spite of that, the last time I was on the receiving end of a Joe Job it was from a domain that had SPF records set up correctly and the server responsible for bouncing all of the spam at me as GMail.
sudo mod me up
(Score: 0) by Anonymous Coward on Monday April 25 2016, @11:59AM
> 'this mail is not spam', it was intended to say 'all emails that come from the wrong server are spam and if messages from this domain are spam then it's safe to bounce them back to this server'.
No that is not what SPF is intended to do. For one thing, who bounces spam? That goes into spam folders or is null routed. All SPF is intended to do is say whether or not the sending host is authorized to deliver the message or not. Its up to the receiving host to decide what to do with that information.
> In spite of that, the last time I was on the receiving end of a Joe Job it was from a domain that had SPF records set up correctly and the server responsible for bouncing all of the spam at me as GMail.
It doesn't matter if the spammer's domain had an SPF record, what matters is if your domain had a restrictive SPF record.
Even then it is possible to set up SPF in such a way as to permit anyone to impersonate your domain. I've seen lots of SPF guides that recommend ~all or even +all at the end of the SPF record.
(Score: 0) by Anonymous Coward on Monday April 25 2016, @10:53AM
Yep, they don't care. My employer runs their own email server, and we have constant headaches with emailed reports we send out being sent to the spam folder or sometimes just disappeared entirely.
My standard response has been to forward the copy of the email (report engine saves this) and just say something to the effect of let your IT department or consultant know. If they want an escalation, the server admin will forward info from the mailserver log showing that we did our part and delivered it "to the next relay."
Of course, nobody ever does anything about it to resolve the problem. I suspect there's a lot of apathy out there among small businesses that use gmail in particular. Everybody knows that if Google doesn't want to do something, Google doesn't want to do something, and they'll tell you "fuck you" for trying to contact them about a problem.
I forget if we've got DMARC set up, but SPF and DKIM are there. Doesn't make a damn difference.
(Score: 0) by Anonymous Coward on Monday April 25 2016, @04:17PM
> For support of this proposition, look at the scores for DKIM in SpamAssassin.
So I took you up on that and did go looking.
The rule that would be most useful is still just a test-mode rule - T_DKIM_INVALID - the message fails DKIM validation.
Apparently the reason they have not promoted that to a full-blown rule is that too many domains have screwed up their DKIM implementation and it would give too many false positives if they made it an official rule.
That's not really an indictment against DKIM being effective, but rather a problem of too many sloppy sysadmins.