Need to block user and return message of it
 

Hi there,

Already tried to block a user, and letting it know that his email was returned, but I cannot follow the instructions I found here:

http://www.emaildiscussions.com/showthread.php?t=62680

because those menu option don´t exist anymore.

Is there any easy way to block a sender from a message received and return a message informing it?

Hope someone can help.

Regards.

Are you using the current or classic interface?

Hi sflorack,

I´m using the regular one. I just login trough:

https://www.fastmail.com/login/

I now found that way to login to the classical interface but the option to rules/spam protection is disallowed:

"Rules and Spam Protection can no longer be configured via the Classic interface. Please log in to the regular interface to configure Rules / Spam Protection. "

So, for me the regular interface is not a easy option.

And with the loss of the classic interface I will loose an option - that I now recall - "After message action, go to " very useful because of the included option that I cannot find on the regular interface.

If until June Fastmail won´t find equivalent options in the new interface I must find an alternative.

Regards.

Is post #3 in the thread you linked to above a viable alternative?

- Bruce

Bounce messages tend to be frowned upon these days. You can easily discard the message on receipt without a message using the current Rules system (Settings->Rules). If you feel a message is really necessary in your case, the custom sieve snippet in the old referenced thread is the only real way to do it. Custom sieve is inserted using the Rules system. If you use copy (from the sample in the referenced thread) and paste, then adapt it accordingly, that should do the trick.

If you still cannot figure it out, post again. A guy called Bill should come by who is very good at producing clear detailed instructions.

A guy called Bill??

That in no way comes even close to describe the true awesomeness of n5bb, who is EMD's equivalent of Deep Thought.

I'm sure that sieve is the best way to go - for myself (with next to no knowledge of that subject), I would set up a filter to forward the offending e-mail to an external e-mail account (a throwaway Gmail account, for example) that had a vacation response permanently set up.

That's if you really need to respond to the offender every time, of course.

Thank you all for the help.

I will try to arrange a script that does what I need. Although I think this kind of option, and I think It´s not a weird request, should be more user friendly, as it was in the old/classical interface.

Best regards.

Good luck!

The reason the support for bounce messages was removed from the Rules system in the modern version is because, as I said, it is considered bad practice in most situations today. (It was a fairly common thing to do 10-15 years ago.) That is combined with the fact that there is a workaround using custom sieve for the rare cases where it may still be appropriate. Simplifying the system while discouraging use of bounce messages is a good decision IMHO.

Sorry OP Fastmail are not allowing the reject message anymore....

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;
}

What's the point? If the message has been returned, the sender will see it without any additional tricks.

well in my script I put why the message has been returned.
Spam, Junk, hate list, idiots...

I prefer to silently discard.

I was just trying to help the Op out.

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)

That makes me want to send you an e-mail, just so I can get it bounced back to me: "We're sorry, your message is being returned because you're an idiot."


Such honesty and directness is rare these days. ;)

Most unwanted email messages, I just silently discard; but there was one software vendor from whom I bought a product, who kept spamming me despite my not clicking on anything giving them permission, so their emails (if they're still sending any) get bounced with the message "Unknown user". :D

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.

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.