Quote:
Originally Posted by Terry
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?