EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 6 May 2017, 11:56 AM   #16
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,995
Quote:
Originally Posted by jhollington View Post
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.
That seems stupid whats the point of having sieve script if it does not do what is required.
So Fastmail now are only giving us parts of sieve script....my god things are getting worse instead of better.
Terry is offline   Reply With Quote
Old 6 May 2017, 12:20 PM   #17
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by Terry View Post
That seems stupid whats the point of having sieve script if it does not do what is required.
So Fastmail now are only giving us parts of sieve script....my god things are getting worse instead of better.
Actually, on testing it would seem it's sort of working, but in a way that's even weirder than I'd have expected...

For whatever reason, one of the servers in FastMail's inbound mail stream is queuing and retrying messages that are rejected, essentially delaying delivery with an SMTP 421 error rather than bouncing the message outright.

I created a few "reject" rules in my Sieve script to test this, and then proceeded to send messages to myself that would match those rules. While most of those messages silently disappeared, two very odd things happened....

1. When I removed the rules, the messages I had sent, which I'd assumed were discarded, eventually showed up.

2. The messages sent for rules that weren't removed eventually resulted in "Delayed Mail" MDNs from MAILER-DAEMON@messagingengine.com, citing the host mailmx.nyi.internal as holding the message.

Code:
This is the mail system at host mailmx.nyi.internal.

####################################################################
# THIS IS A WARNING ONLY.  YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################

Your message could not be delivered for more than 1 hour(s).
It will be retried until it is 1 day(s) old.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                  The mail system

<myaddress@mydomain.com>: host
   mailmx.nyi.internal[/var/run/lmtpforward/incoming] said: 421 4.3.0
   Unexpected delivery error - 550 5.7.1 Go away (reported by sloti29t02 in
   END OF DATA) via compute2 (in reply to end of DATA command)
In other words, while the "reject" rule is resulting in a 550 response somewhere deeper down in the chain (the "Go away" phrase is what I used in my reject testing Sieve script), FastMai's inbound servers still accept the message AND try to redeliver it for up to a day before (presumably) permanently bouncing it with a non-delivery notification.

This is also why removing the "reject" rule in the Sieve script results in the message eventually getting through. Each time the upstream server retries delivery, the Sieve script is reprocessed, and if the "reject" rule has been removed by the time of the next attempt, the message will get through successfully.

It's times like this that I wish some of the FastMail folks were still around here and actually paying attention, as this sound more like a bug in the system somewhere than intentional behaviour..... Bron? Rob? Anyone?
jhollington is offline   Reply With Quote
Old 6 May 2017, 12:26 PM   #18
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,995
I only used it to block about two nuisance people, but now will just use an modified auto reply.

Some sieve rules wont work if you have don't discard mail from known senders.
Terry is offline   Reply With Quote
Old 6 May 2017, 12:42 PM   #19
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by Terry View Post
Some sieve rules wont work if you have don't discard mail from known senders.
Actually, for the most part that option doesn't really affect Sieve rules at all, other than spam filtering, which is really it's own predefined block that you can't edit anyway.

In essence, what turning on the "Do not discard messages sent by my contacts" option does is add an extra wrapper around section 3 in the predefined chunk of the Sieve script that only runs the spam rules if the e-mail is not from a "known sender" (specifically, if not header :matches "X-Spam-Known-Sender" "yes*").

So if you have that option on, and a message comes in from a known sender, the spam filtering block gets skipped entirely, but the rest of the Sieve script continues along its merry way.
jhollington is offline   Reply With Quote
Old 6 May 2017, 12:57 PM   #20
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,917
Arrow Automatic responses are usually a bad idea

Quote:
Originally Posted by FredOnline View Post
A guy called Bill??
Thanks for the kind words ... I'm blushing, Fred!
Quote:
Originally Posted by jhollington View Post
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...
I have sent a message to someone I know on FM staff asking about this recent change. It appears to me that a MDN message "Delayed Mail (still being retried)" is returned to the sender after a bit over an hour, and that Fastmail internally retries delivery after initially accepting the message. This disagrees with their Help system description of sieve reject and seems incorrect in several ways to me. I can't quickly tell if the MDN is sent to the From or envelope sender.

As jhollington properly stated, the From address (and sometimes the envelope From address) are often set to an innocent person's address. If you reply in any way to spam or phishing or scam emails you are sending a message with one of the following results:
  • Your response message will be received but ignored. This is what happens when you respond to most automated advertising mail.
  • Your response message will be rejected with an automated reply, leading to what will appear to you as new incoming spam. This is what happens if the original From address does not exist or if the owner of that address has set up an auto-responder just as some in this thread want to do. In some cases the rejection can lead to another automatic response from you, leading to an email loop.
  • Your response will be received by an innocent third party, creating spam for them. They may mark your email address as spam, causing you and other Fastmail users difficulty in the future. In other words, you (and the Fastmail server) could be classified as spammers.
  • A few scammers want you to reply to their messages. This lets them know their messages are getting to you. Anything you tell them will just lead them to send you more scamming attempts, since they know their messages are getting to someone.
  • The only reason to send an automated response would be if you believe the sender to not be a spammer or scammer and you wanted to inform a human sender that you were changing your email address or closing an account. You may want to send a response due to an emotional response on your part, but don't let you ego make a stupid mistake. Just as in person to person interactions, it's usually best to shut up and not respond in these cases.
Of course, you can choose to manually respond to someone you believe will read your message, such as normal person to person email or a business email which is not automatically sent. But if you ask someone to not send you messages and they continue doing so (or you receive automated messages and you can't unsubscribe), it's best to just add a discard rule as follows:
  • While reading the messages, click More>Add Rule from Message...
  • A proposed draft rule will be shown. Set the Conditions to catch only messages you want to discard. You can remove unwanted conditions or manually add additional conditions. Be sure you set the Action section properly.
  • Click Save to add this rule to your other rules, or Cancel to exit making no changes.
I will post again in this thread when I get some answers from Fastmail staff about the current sieve reject behavior.

Bill
n5bb is offline   Reply With Quote
Old 6 May 2017, 01:01 PM   #21
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,995
Thanks Bill...
Terry is offline   Reply With Quote
Old 10 May 2017, 02:23 PM   #22
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Did you submit a support ticket about this? It's the first I've seen of the issue being mentioned, but yes - it does look like an unintentional side-effect of a change that's been in place for... about 2 years I think!

I'll create a development ticket for it.
brong is offline   Reply With Quote
Old 10 May 2017, 02:33 PM   #23
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,917
Quote:
Originally Posted by brong View Post
Did you submit a support ticket about this? It's the first I've seen of the issue being mentioned, but yes - it does look like an unintentional side-effect of a change that's been in place for... about 2 years I think!

I'll create a development ticket for it.
I just forwarded to you an email I sent to Rob M late last week, Bron.

Bill
n5bb is offline   Reply With Quote
Old 10 May 2017, 02:38 PM   #24
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Ahh, I see n5bb emailed about it as well, so Rob was looking at it separately. We've tracked down the cause - upstream Cyrus sieve changes that made it reply back to the sending MTA asking for a bounce rather than generating the bounce in-process.

We're working on a fix to make those bounces go back out immediately.
brong is offline   Reply With Quote
Old 10 May 2017, 02:46 PM   #25
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,917
Thanks, Bron. I just sent you an attachment with the "delayed message being retried" email. I originally forgot the attachment when I forwarded my message to Rob M to you.

Bill
n5bb is offline   Reply With Quote
Old 10 May 2017, 02:51 PM   #26
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,995
Quote:
Originally Posted by brong View Post

We're working on a fix to make those bounces go back out immediately.
Thank you.....sorry I got cranky I thought you were removing pieces of sieve script and I thought here we go again we have to do another work round.
Sorry my apologies...

Also check the return emails as currently its showing my main Fastmail address which I never give give out also with my alias.
Terry is offline   Reply With Quote
Old 10 May 2017, 02:56 PM   #27
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,917
Quote:
Originally Posted by Terry View Post
...Also check the return emails as currently its showing my main Fastmail address which I never give give out also with my alias.
I also reported this to Fastmail in detail late Friday Texas time last week, Terry. Due to time zones my message arrived in Australia on Saturday, so they probably haven't been working on it until yesterday. So this is a pretty fast response to a rather odd bug.

Bill
n5bb is offline   Reply With Quote
Old 10 May 2017, 03:10 PM   #28
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,995
Yea.....very quick.

I long time ago I would email Rob and I am thinking seriously about doing that again rater than post on here and upset everyone.

I got cranky for various reasons I have mentioned before.
I'm no computer whizz kid so for me to find a work round takes a little bit longer than most.
Terry is offline   Reply With Quote
Old 10 May 2017, 03:11 PM   #29
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Yep, we'll definitely check what postfix does, and if it's starting to include the eventual destination address then we'll figure out a way to strip that back out of bounces.
brong is offline   Reply With Quote
Old 11 May 2017, 12:08 AM   #30
joe_devore
Essential Contributor
 
Join Date: Dec 2003
Location: Dover, NH, USA
Posts: 315
Quote:
Originally Posted by Bamb0 View Post
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)
I liked it too when I could setup known spam to bounce, so that way.. SPAMMERS thought they had an invalid email address..

I only get sporadic SPAM these days so its not too bad...
joe_devore is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 04:24 PM.

 

Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy