Hacker News new | comments | show | ask | jobs | submit login

It could be server side spam filtering (not all spam messages make it to your spam folder with any provider - the worst offenders are often just thrown out).

Just saying it is possible that this is an over-aggressive spam filter vs. Apple taking such an invasive measure. Although, Apple has done similar crazy things before, so who knows.




That doesn't conform to RFC 2821:

  4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>

   When an SMTP server returns a positive completion status (2yz code)
   after the DATA command is completed with <CRLF>.<CRLF>, it accepts
   responsibility for:

   -  delivering the message (if the recipient mailbox exists), or

   -  if attempts to deliver the message fail due to transient
      conditions, retrying delivery some reasonable number of times at
      intervals as specified in section 4.5.4.

   -  if attempts to deliver the message fail due to permanent
      conditions, or if repeated attempts to deliver the message fail
      due to transient conditions, returning appropriate notification to
      the sender of the original message (using the address in the SMTP
      MAIL command).
If it's spam, the email should be rejected while the SMTP connection is still established with an error code (4XX or 5XX). If the email was accepted for delivery, there are really only two options: deliver the email or bounce it back to the sender.


Google also runs an smtp server that violates the relevant RFCs, but nobody seems to care much: http://lee-phillips.org/gmailRewriting/


RFC 5321 says:

"As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice."

http://tools.ietf.org/html/rfc5321#section-6.2


That is the wrong way to run a mail server. I know how common it is at big providers, but it's still wrong.

You should REJECT a message if you won't deliver it. If it was a legit message inappropriately REJECTed, then the server that's relaying it can generate a bounce back to the sender, and something can be figured out.

Dropping a message on the floor like that, after you have promised to deliver it is almost always the Wrong Way.


I imagine the reason that it's done is because rejecting it gives spammers more information that could possibly be used to get around the rejection. It's much harder if they aren't sure whether or not the message was received.

Whether or not that's appropriate is another thing, but that is probably the rationale behind it.


More likely the rationale is that it's easier to filter stuff asynchronously after it is sitting in queue, and there's no longer a TCP connection hanging off it, waiting for a response. In other words, it's cheaper.


"not all spam messages make it to your spam folder with any provider - the worst offenders are often just thrown out"

This is news to me. Citation needed?


Postini.com (Google), Forefront (Exchange), and Barracuda Networks are some products/vendors in the space - its a whole industry. Just Google around a bit for "server side spam filtering" and such.

Anecdote: we use hosted Exchange from Microsoft. I tried to setup a cron job to email us all at 4:57 with the subject line "Get The Fuck Out". Those don't come through either.


Yahoo (particularly when providing services for BT) silently delete some spam, even mail with a raw SA score < 1.5.

And they don't respond to complaints, even from their own users.

I've been running the same pukka mailing list for 12 years, I'm in their abuse feedback loop, have proved exclusive ownership of the mail server, all mail is DKIM signed with valid SPF records, mail is accepted with a 250 OK, you name it.

Still they bin my emails, but only to some accounts. No rhyme or reason, no bounce, no spam folder. Just never arrives.


Greylisting, for one.

You could also reasonably configure a filter to not land emails over a spam threshold.

Given the amount and type of spam in my Gmail Spam label, I'm quite sure there's a hard filter in place there too.


Greylisting does not throw anything out. It does the exact opposite. The mail server simply says, "I have a temporary problem, so I can't take this right now. Try again later" Mail servers are supposed to (and do) try again, at which time a greylisted message will be delivered. Accepting a message for delivery In Go Faith and then dropping it on the floor, is poor, lazy, cheap, RFC-breaking spam filtering.


What I mean is that greylisting is a trick mechanism where some mails, declared spam based on an unrelated and technical criteria, never reach the user's spam folder. This contradicts the 'spam should go to spam folder' point.


Russian mail provider Mail.ru did that, maybe still does. I blame white-listing, as perfectly valid mail from custom domains could become missing.


Isn't that generally done on the receiving end? In this case, the message is simply never sent.


It depends what email account he sent it to. It seems like at least Apple and Google are both using F-Secure.

So it could be a bug in their definitions files.


That's the thing though. Apple has never filtered emails before or even hinted that they would.

I'm going to take a guess that this is just a misconfiguration in the spam filters.


> I'm going to take a guess that this is just a misconfiguration in the spam filters.

A misconfiguration in your email server that results in emails being silently dropped is about as bad of a misconfiguration as you can have. That shouldn't even be an option to configure.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: