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 22 Jan 2021, 03:35 AM   #1
camner
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?
camner is offline   Reply With Quote

Old 22 Jan 2021, 05:30 AM   #2
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
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.
JeremyNicoll is offline   Reply With Quote
Old 22 Jan 2021, 07:55 AM   #3
camner
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.
camner is offline   Reply With Quote
Old 22 Jan 2021, 02:53 PM   #4
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,916
Arrow 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
n5bb is offline   Reply With Quote
Old 23 Jan 2021, 04:21 AM   #5
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
Quote:
Originally Posted by camner View Post
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.
If you have many sieve rules then presumably it's clear to you that some of them, maybe many, can't be the ones causing your problem.

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.
JeremyNicoll is offline   Reply With Quote
Old 23 Jan 2021, 03:19 PM   #6
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,084
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.
BritTim is offline   Reply With Quote
Old 24 Jan 2021, 05:02 AM   #7
camner
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;}
This rule works if I send an email directly to <bitly@myaddress.com>, but does NOT catch the "Mail Delivery Failed" emails that have been coming to me over the last week or so.

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

&emsp; 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--
camner is offline   Reply With Quote
Old 24 Jan 2021, 09:01 AM   #8
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
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.
JeremyNicoll is offline   Reply With Quote
Old 24 Jan 2021, 12:32 PM   #9
camner
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?
camner is offline   Reply With Quote
Old 24 Jan 2021, 12:39 PM   #10
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,916
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
n5bb is offline   Reply With Quote
Old 24 Jan 2021, 05:25 PM   #11
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 474
Quote:
Originally Posted by n5bb View Post
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.
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 05:30 PM.
xyzzy is offline   Reply With Quote
Old 24 Jan 2021, 09:18 PM   #12
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
Quote:
Originally Posted by camner View Post
@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?

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.
JeremyNicoll is offline   Reply With Quote
Old 25 Jan 2021, 11:38 PM   #13
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
Quote:
Originally Posted by JeremyNicoll View Post
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.)
Good to know. I won't tear my hair out trying to figure out why FM's actual behavior is different than what Sieve Tester tells me.

Quote:
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.
Bingo, makes perfect sense! Although if the smart host is just sending back an "undeliverable mail" message to the sender, including the BCC header wouldn't violate privacy, right, because the original sender surely knows the identities of those to whom he/she sent the BCCs, no?

Thanks for taking the time for such a complete and helpful tutorial.
camner is offline   Reply With Quote
Old 25 Jan 2021, 11:47 PM   #14
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
Quote:
Originally Posted by xyzzy View Post
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.
My backscatter setting is set to "Move to Spam." AND, looking at the raw message, I see that there is the following header: X-Backscatter: Yes!

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"?
camner is offline   Reply With Quote
Old 25 Jan 2021, 11:51 PM   #15
camner
Cornerstone of the Community
 
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
Quote:
Originally Posted by n5bb View Post
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
I don't use aliases. Since my domain is hosted at FM, I've just used Sieve rules forever and a day to sort emails into appropriate places and to filter out email addresses at my domain that have been compromised and at which I would receive a lot of spam.

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.
camner 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 05:56 PM.

 

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