|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
22 Jan 2021, 02:35 AM | #1 |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
"Undelivered mail" message to email address set to autodelete
I have an email address (at FM) that has been subject to a lot of spam, and so I set a Sieve rule to silently delete any email sent to that address, and that works fine.
Recently, I have started to receive a number of "Undelivered Mail Returned to Sender" messages from "Mail Delivery System." Obviously, someone has forged headers so that the spam they are sending has the spammed email address as the sender. What I don't understand is this: If I send an email to the address, it silently deletes. When a receiver's mail server generates an email to that same address saying that an email message is undeliverable, why doesn't the Sieve rule apply and silently delete that "Undeliverable" message? |
22 Jan 2021, 04:30 AM | #2 |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 490
|
Maybe you have a higher-priority rule that accepts such mails?
If you have no other sieve rules, maybe you miscoded the one you did set up. It's hard for anyone else to comment unless you show us - suitably censored if needed - what you've defined. And also, what the headers of a mail that you think should have been deleted but wasn't contain. If you do have other sieve rules, it's sometimes useful to add to those an action that will alter incoming mails' headers so you can see which rule caused which action. For example (test code): if header :contains "Subject" "this is just a sieve test" { addflag "\\Flagged"; addheader "X-JN-Breadcrumb" "Inserted at start of headers by my sieve code"; addheader :last "X-JN-Breadcrumb" "Appended at end of headers by sieve test 23"; stop; } will turn on the red "flag" pin, and add two new headers, one at the top of the mail's existing headers and one at the bottom. |
22 Jan 2021, 06:55 AM | #3 |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Thanks for the tips...I'll give them a try.
Some followup, for clarity...I have lots of Sieve rules. Are you suggesting I create a "addheader" command at the top and bottom of EACH Sieve rule I have, to try to pin down which one is causing the difficulty? And, what would I be looking for to "see which rule caused which action"? I would describe myself as having middling familiarity with Sieve...beyond basic but well short of expert! Thanks again. |
22 Jan 2021, 01:53 PM | #4 |
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,929
|
Envelope address used for delivery if no TO or CC header is present
Look carefully at the full headers of one of those “Undelivered Mail Returned to Sender” messages. My guess is that there is no “To” header, or if it’s present your address is not in “To” or “Cc”. So your spam filtering rule is looking at only the “To” or “Cc” header, it will fail to work on those messages.
If you use the standard rule “To/Cc/Bcc” rule it should catch such messages, since it also looks at the “X-Delivered-to” header. Messages arrive at the Fastmail server based on the envelope address, not the To or Cc address. This explains how BCC messages make it to you with no To or Cc shown in the full headers. The “X-Delivered-to” header shows the address used by Fastmail to find the delivery account using the aliases assigned to each account. If a “To” or “Cc” header includes your address, it is used to create “X-Delivered-to”. But if there are is no “To” or “Cc” header, the envelope address of the received message is used instead. The “ X-Resolved-to” header shows the target delivery address assigned when the sieve script is executed. If the sieve script doesn’t discard the message, it will be delivered to the Fastmail account and folder (using plus+addressing) assigned by the Aliases screen setting for that alias. If you are not currently using a certain alias and spam is arriving for that alias, you should open the Aliases setup screen and disable that alias, which will “Reject (bounce) all mail sent to this address (disable the alias)”. If it’s an alias at a domain you own and you have the wildcard alias enabled, just create a new alias you need to block and disable that alias in the Aliases setup screen. This only works if you want to ignore ALL messages sent to that alias. Bill |
23 Jan 2021, 03:21 AM | #5 | |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 490
|
Quote:
There's only any point in adding addheader actions to rules which might be involved, but you're not sure. You don't need both the addheader and addheader :last actions; choose one or other depending on where you want the new headers to be placed in any matching email. You will need to put different text in the addheader parameters so that if - say - there's ten rules that might be the problem, you have ten possible variants on the content of the new headers. Then, when a mail ends up in the wrong folder you inspect its headers to see which of the addheader texts is present. |
|
23 Jan 2021, 02:19 PM | #6 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
The first thing I would do in debugging this is to see whether the sieve rule that you think should be deleting mail sent to that address is really being processed. This will tell you whether you need to look closely at that particular rule, or whether you need to trace why processing is skipping the rule.
|
24 Jan 2021, 04:02 AM | #7 |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Thanks, all, for your replies.
@n5bb: It makes sense to include in the Sieve code a look at "Bcc" headers, and my Sieve code did not do that (I've updated it). But, if you take a look at the raw message (below), I think there IS a "To" header, and the "To" header IS the email address that the Sieve code is not catching (see text in red) My Sieve rule now is: Code:
If address :matches ["to","from","x-delivered-to","Cc","Bcc"] ["bitly@myaddress.com"] {discard;stop;} I'm pasting (appropriately munged) the raw message that isn't being processed correctly by my Sieve code: Code:
Return-Path: <> Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by sloti22d2t07 (Cyrus 3.5.0-alpha0-78-g36b56e88ef-fm-20210120.001-g36b56e88) with LMTPA; Sat, 23 Jan 2021 07:31:23 -0500 X-Cyrus-Session-Id: sloti22d2t07-1611405083-461329-2-1527621697041207028 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-sender-reputation: 0 (email; noauth) X-Spam-score: 6.5 X-Spam-hits: BAYES_50 0.8, HTML_MESSAGE 0.001, ME_NOAUTH 0.01, ME_SENDERREP_DENY 4, SPF_HELO_NONE 0.001, SPF_NONE 0.001, URIBL_BLACK 1.7, LANGUAGES en, BAYES_USED user, SA_VERSION 3.4.2 X-Backscatter: Yes X-Backscatter-Hosts: 77.40.62.178, bear.lev3.com X-Spam-source: IP='104.206.99.154', Host='bear.lev3.com', Country='US', FromHeader='com', MailFrom='unk' X-Spam-charsets: plain='us-ascii' X-Resolved-to: myaddress@fastmail.fm X-Delivered-to: bitly@myaddress.com X-Mail-from: Received: from mx5 ([10.202.2.204]) by compute4.internal (LMTPProxy); Sat, 23 Jan 2021 07:31:23 -0500 Received: from mx5.messagingengine.com (localhost [127.0.0.1]) by mailmx.nyi.internal (Postfix) with ESMTP id CA448214007E for <bitly@myaddress.com>; Sat, 23 Jan 2021 07:31:22 -0500 (EST) Received: from mx5.messagingengine.com (localhost [127.0.0.1]) by mx5.messagingengine.com (Authentication Milter) with ESMTP id 3A667C01F1C; Sat, 23 Jan 2021 07:31:22 -0500 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=fm1; t= 1611405082; b=JZLTmjQTo8D2sinNv3KcYKcMSfN+nZgb7EVAQaCTlyvb8WVhbR d/V3UTnvFuZ80K9PPfbHCEMIpa3muTbFbCLPeVdrc6DdGIiJI3pVbA6wpzt4z0+m kgiY54GQ4YVTJ+cV4zKhOeyIyBg+vgGZTa8g/YgTr/t5Cy/8UC1OJUJz2WC0RT30 YiDH8kbeohkGOsS5T/g1Lnt1jfc2Mhd8gdSDYSdEKGsSIp1LlV4IoUPJ4E4Y7bxG ZjaO+PeY31UBKtU7KOqJOJRJD0obWD/gfuGqNilkMGycXsVifmgamHpMVdqUuRTS s6pJDwHJBFr1l0yeymgiCifbcPscwWC2FPfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=from:to:content-type:mime-version:subject :message-id:date; s=fm1; t=1611405082; bh=TRPmZQ2Vl8Z8dkAClCktBh MKbtdbFLke/4OZt2PTmVI=; == ARC-Authentication-Results: i=1; mx5.messagingengine.com; arc=none (no signatures found); bimi=skipped (DMARC did not pass); dkim=none (no signatures found); dmarc=fail policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none policy.arc-aware-result=fail (p=none,d=none,d.eval=none,arc_aware_result=fail) policy.policy-from=p header.from=bear.lev3.com; iprev=pass smtp.remote-ip=104.206.99.154 (bear.lev3.com); spf=none smtp.mailfrom="" smtp.helo=bear.lev3.com; x-aligned-from=null_smtp (No envelope domain); x-ptr=pass smtp.helo=bear.lev3.com policy.ptr=bear.lev3.com; x-return-mx=fail smtp.domain=localhost.localdomain policy.org_domain=localdomain policy.is_org=no policy.mx_error=NXDOMAIN policy.a_error=NXDOMAIN policy.aaaa_error=NXDOMAIN policy.org_mx_error=NXDOMAIN policy.org_a_error=NXDOMAIN policy.org_aaaa_error=NXDOMAIN; x-return-mx=warn header.domain=bear.lev3.com policy.org_domain=lev3.com policy.is_org=no policy.mx_error=NOERROR policy.aaaa_error=NOERROR (A Records found: 104.206.99.154); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=bounce score=10000 state=3 Authentication-Results: mx5.messagingengine.com; arc=none (no signatures found); bimi=skipped (DMARC did not pass); dkim=none (no signatures found); dmarc=fail policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none policy.arc-aware-result=fail (p=none,d=none,d.eval=none,arc_aware_result=fail) policy.policy-from=p header.from=bear.lev3.com; iprev=pass smtp.remote-ip=104.206.99.154 (bear.lev3.com); spf=none smtp.mailfrom="" smtp.helo=bear.lev3.com; x-aligned-from=null_smtp (No envelope domain); x-ptr=pass smtp.helo=bear.lev3.com policy.ptr=bear.lev3.com; x-return-mx=fail smtp.domain=localhost.localdomain policy.org_domain=localdomain policy.is_org=no policy.mx_error=NXDOMAIN policy.a_error=NXDOMAIN policy.aaaa_error=NXDOMAIN policy.org_mx_error=NXDOMAIN policy.org_a_error=NXDOMAIN policy.org_aaaa_error=NXDOMAIN; x-return-mx=warn header.domain=bear.lev3.com policy.org_domain=lev3.com policy.is_org=no policy.mx_error=NOERROR policy.aaaa_error=NOERROR (A Records found: 104.206.99.154); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=bounce score=10000 state=3 X-ME-VSScore: 10000 X-ME-VSCategory: bounce Received-SPF: none (bear.lev3.com: No applicable sender policy available) receiver=mx5.messagingengine.com; identity=helo; helo=bear.lev3.com; client-ip=104.206.99.154 Received: from bear.lev3.com (bear.lev3.com [104.206.99.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx5.messagingengine.com (Postfix) with ESMTPS for <bitly@myaddress.com>; Sat, 23 Jan 2021 07:31:22 -0500 (EST) Received: from mailnull by bear.lev3.com with local (Exim 4.93) id 1l3I4W-0001dq-Sm for bitly@myaddress.com; Sat, 23 Jan 2021 07:31:20 -0500 X-Failed-Recipients: tizi.fac58@libero.it, imrith@hotmail.it, credente1@tiscali.it, enotoby@libero.it, lufrano.salvo@libero.it, tricolor@tin.it, fcgraphic@libero.it, pinodebg@libero.it Auto-Submitted: auto-replied From: Mail Delivery System <Mailer-Daemon@bear.lev3.com> To: bitly@myaddress.com Content-Type: multipart/report; report-type=delivery-status; boundary=1611405080-eximdsn-452654600 MIME-Version: 1.0 Subject: Mail delivery failed: returning message to sender Message-Id: <E1l3I4W-0001dq-Sm@bear.lev3.com> Date: Sat, 23 Jan 2021 07:31:20 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bear.lev3.com X-AntiAbuse: Original Domain - myaddress.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - X-Get-Message-Sender-Via: bear.lev3.com: sender_ident via received_protocol == local: mailnull/primary_hostname/system user X-Authenticated-Sender: bear.lev3.com: mailnull X-Source: X-Source-Args: X-Source-Dir: --1611405080-eximdsn-452654600 Content-type: text/plain; charset=us-ascii This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: silvestrosax@yahoo.it Domain mr-wizards.com has exceeded the max defers and failures per hour (25/25 (100%)) allowed. Message discarded. fcgraphic@libero.it Domain mr-wizards.com has exceeded the max defers and failures per hour (25/25 (100%)) allowed. Message discarded. pinodebg@libero.it --1611405080-eximdsn-452654600 Content-type: message/delivery-status Reporting-MTA: dns; bear.lev3.com Action: failed Final-Recipient: rfc822;credente1@tiscali.it Status: 5.0.0 Action: failed Final-Recipient: rfc822;imrith@hotmail.it Status: 5.0.0 Action: failed Final-Recipient: rfc822;tizi.fac58@libero.it Status: 5.0.0 --1611405080-eximdsn-452654600 Content-type: message/rfc822 Return-path: <bitly@myaddress.com> Received: from [77.40.62.178] (port=11076 helo=tbaoe) by bear.lev3.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <bitly@myaddress.com>) id 1l3I4W-0001XI-De; Sat, 23 Jan 2021 07:31:20 -0500 From: "Doris" <bitly@myaddress.com> Content-Type: multipart/alternative; boundary="5a2239f74be8a472bd8322dd069a" X-EsetId: QXOPM Subject: Ti scrivo per sorridere dolcemente MessageID: EDE85E0D06D2FC1FC3C68F32866C4B77@myaddress.com Precedence: 6476:42:5078:66735 MIME-Version: 1.0>"); X-Mailer: CrossPoint Light response 5.51.3 Date: Sat, 23 Jan 2021 15:31:00 +0300 X-Clang-BrandId: mx:zotpgaks=w]pcq_qzgr Reply-To:"Doris" <bitly@myaddress.com> To: "ebookblog@thecommissionclub.com" <ebookblog@thecommissionclub.com> --5a2239f74be8a472bd8322dd069a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable   Ciao. Me si chiama Doris. Il mi e molto insolito offerta. Spero di si mi capirete. Sono sposata da quasi 3 anni. Siamo mio marito amiamo sperimentare sessuale piano. E, infine, abbiamo deciso di organizzare sesso a tre. vogliamo, che se si= sono stati i nostri terzo partner. voglia sperimentare 2 uomini e ottenere indimenticabile piacere. abbiamo profilo sito di dating online Bafflegab12113 . Copiare questo link bablove.site metti in il browser. --5a2239f74be8a472bd8322dd069a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable (Html version deleted) --5a2239f74be8a472bd8322dd069a-- --1611405080-eximdsn-452654600-- |
24 Jan 2021, 08:01 AM | #8 |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 490
|
It's not common for incoming mails to contain "BCC" headers.
The whole point of BCC is that recipients don't see who else received copies of mails. When an email is composed containing BCC addressees the email client (in some cases), or usually (ISP's mail-sending process) generates copies of the mails without those headers, and sends one to each required recipient. The "sent" copy that is retained by the sender's email system is not the same as what is sent to the recipients. The most likely reason why your message isn't being processed by your rule is that an earlier rule is processing it instead. |
24 Jan 2021, 11:32 AM | #9 |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
@JeremyNicoll: I'm having a little trouble understanding what you are saying (no doubt, due to my ignorance).
I (think I) understand that when emails are sent out with BCC addresses, the sending system makes sure that recipients have no way of identifying the other recipients of the same email message. So, it makes sense that the "sent" copy retained by the sender's system is not the same as what is sent to the recipients. What I don't understand is how the above relates to what is going on in my case. I have gone to FM's Sieve tester, and put in my (entire) Sieve code as well as the entire raw "Undelivered mail" message that FM delivered to me. The results of the Sieve test are that the message should be silently deleted, not retained. If an earlier rule were processing the "Undelivered mail" message, wouldn't the Sieve tester tell me that the result of my Sieve code on the raw message was to have the email retained rather that deleted? |
24 Jan 2021, 11:39 AM | #10 |
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,929
|
There are various things which may be causing this. I noticed that the message headers you posted including “X-Backscatter: Yes”, which means that the Fastmail backscatter spam filter settings will affect your results. We also don’t know the target you are using for that alias, and that will affect the delivery.
I will repeat my suggestion from earlier in this thread. If you host your domain at Fastmail and have the wildcard alias enabled, all you have to do to block one alias is to create an alias at your domain in the Fastmail Aliases screen and then disable that alias. This will result in Fastmail not accepting incoming mail for that alias. Bill |
24 Jan 2021, 04:25 PM | #11 |
Essential Contributor
Join Date: May 2018
Posts: 477
|
I think you may have "hit" his problem. Specifically just what are the Spam Protection's Backscatter setting(s)? Could it be set to "move"? That would certainly intercept any sieve code (filter rules) that follows.
Last edited by xyzzy : 24 Jan 2021 at 04:30 PM. |
24 Jan 2021, 08:18 PM | #12 | |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 490
|
Quote:
The Sieve Tester is known not to be reliable. People here have complained but FM have not fixed the problem(s). (I don't know the details.) The way that email systems work varies, but generally when you "send" an email, what you're really doing is handing it over to special software (known historically as a 'smart host' - see: https://en.wikipedia.org/wiki/Smart_host ) that your ISP (or, if you specifically use someone else's outbound server, that) uses. It removes any BCC header that you may have included, and works out who all the recipients are (from that BCC, and TO and CC). Then for each intended recipient: it looks up (from DNS) the name of the mail server that each recipient's mail should be sent to. It tries to establish a connection with that server, announces who it (the sending server) is, says it wants to send a mail intended for whoever, and waits to find out if the destination server will accept that. The destination server might reject the attempt, perhaps because it doesn't trust the sending server, or because it knows it doesn't have a customer with the email address that the sending system wants to send to. If everything is ok, the mail's contents are wrapped up with "SMTP envelope" headers which actually describe who's sending it and who to, then sent. The receiving system strips off the "SMTP envelope" headers but in most cases these days the values that were in them will end up somewhere in the headers of the mail that the recipient will be able to see. It's the 'smart host' that will also, for each mail, try alternate destination servers if the first one it tries is offline, and retry (in theory) all of them for up to a week or so, until it finally manages to send on the mail, and it's also the thing that sends 'Undelivered' messages back to a sender. There are email clients who do some of this work themselves, but they're uncommon, and it really boils down to the user running an SMTP server on their own machine and that liasing with their mail client. The email client may save a copy of what it sent out to the 'smart host'. But as you can see from the tale above, it's not the email client that actually sent any of the individual mails onwards to the recipients, but the 'smart host'. Even amongst email clients that do keep a copy of what they sent, not all of them keep the BCC details. The reason I said all of this is that you posted earlier that you'd decided to include testing of BCC headers in your Sieve test, and I was trying to explain that that was pointless. BCC headers shouldn't be in any of the mails that your ISP's smart host is sending onward, and they shouldn't be in the "Undelivered" messages that are being returned to you. What would be the point? When the 'smart host' sends you a notification of a problem, it's only going to send that to you, not BCC it to anyone else. Just to muddy the waters, there /are/ people who argue that BCC headers /should/ be in mails so that (in theory) someone could eg send a mail TO Tom, CC to Colin and Craig, and BCCed to Bertie and Bruce and Barbara. Some people think that Bertie/Bruce/Barbara should all know that all three of them were sent a 'secret' copy of the mail. Some people think that Bertie, Bruce, Barbara shouldn't know who each other are, but that Tom & Colin & Craig should know. Some people think other combinations should know more or less about who got what. The problem with that is that there's no way for the (perhaps too simple) mechanism to do these subtlely different things. |
|
25 Jan 2021, 10:38 PM | #13 | ||
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Quote:
Quote:
Thanks for taking the time for such a complete and helpful tutorial. |
||
25 Jan 2021, 10:47 PM | #14 | |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Quote:
So, I guess this is it! The "undeliverable mail" message is backscatter, and the rule moving backscatter to my spam folder takes precedence over my Sieve rules, which is why the rule fails. I have no idea why my Backscatter setting is what is, whether at some point long ago I set it that way or whether that's the FM default. Is there any reason not to change the Backscatter setting to "Discard"? |
|
25 Jan 2021, 10:51 PM | #15 | |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Quote:
Your suggestion to create an alias for an address I don't want to receive email at, and then disable the alias, is a good one. It is also simple, and doesn't require me to go into my Sieve rules to add an address to discard silently, which keeps my Sieve rules shorter, and thus easier to maintain. I'll give this a try! Thanks for your help. |
|