Quote:
Originally Posted by Terry
Try something like this....hope it works.
if anyof
(header :contains ["subject","from"] ["the address you want to return mail to"]
){reject "We are sorry to inform you that unfortunately your mail has been returned ";
stop;
}
|
Unfortunately, as far as I've been able to tell, the Sieve "reject" directive these days is pretty much equivalent to the "discard" directive for all practical purposes. FastMail doesn't appear to send any kind of non-delivery notification back out, but only silently discards the incoming message.
So in short, there's really no point in using it, and especially no point in wasting time specifying cute little rejection phrases
IMHO, this is a
good thing, since the vast majority of spam comes from forged e-mail addresses anyway, so you'd most likely be sending rejections back to innocent bystanders. In fact, this is why the original sieve implementation of reject, outlined in
RFC 3028 was later updated in
RFC 5429 to reject messages at the SMTP session level. The latter is definitely the "correct" way to do it, but unfortunately FastMail doesn't run Sieve scripts during that particular stage, so a proper RFC 5429 implementation of "reject" isn't possible, and it's therefore better to just disable it entirely.
In other words, the original RFC 3028 implementation of "reject" — which is what FastMail would be using — actually accepts the message into FastMail's servers, and then generated a Message Delivery Notification (MDN) back to the "FROM" address (which is almost always either forged or simply invalid). This creates pointless e-mail traffic that either clogs up FastMail's send queues (in the case of invalid addresses) or bugs the poor folks whose addresses have been harvested (and usually results in a lot of confused folks wondering why they're getting non-delivery notifications for a message they never sent in the first place).
The "correct" RFC 5429 implementation blocks the message during the SMTP session. The receiving mail server essentially "hangs up" on the sender and the message is never received. This is less likely to result in a non-delivery notification in the case of actual spam, and in the case of semi-legitimate e-mail, it's up to the sending server to generate the MDN after FastMail closes the connection.
Again, though, because of how FastMail is architected, the RFC 5429 implementation isn't possible. Sieve scripts are run after the message has already been received by FastMail's servers and is being delivered to the user's mailbox.
Quote:
Originally Posted by Bamb0
Bouncing really IS the best way as then these spammers really think they have an invalid address.... (The ones that actually use a valid FROM address)
|
Which, unfortunately, is almost none of them.
However, even if they used a valid FROM address, chances are they're just ignoring any non-delivery notifications that get sent out anyway.
The only type of "bounce" that's likely to have any impact on a spammer is at the SMTP session level (as I described above), since this simply refuses to
accept the message in the first place, resulting in an immediate error that's basically equivalent to a "user unknown." Sadly, very few commercial e-mail providers support this method, as Sieve rules aren't traditionally run at the SMTP session level.