1334980 - Reply with Template does not send a reply when no identity exists for recipient

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[eicker]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

In Version 38, reply with template worked as expected. When I tried this feature again, it didn't work anymore. Updated today to version 45.7 - no change.


Actual results:

I created a filter to reply on incoming mails with a template.
Filter - Log file states, that it sends replies - but I do not get a response back, responses do not show up in IMAP sent folder.


Expected results:

Sender should get the response template mailed.

Comment 1

[Jorg K (CEST = GMT+2)]

Aceman, Magnus, I've seen "reply with template" mentioned in the source
https://dxr.mozilla.org/comm-central/search?q=regexp%3Areply.*template&redirect=false
but I can't detect it in the user interface.

The reporter seems to suggest that "reply with template" is a filter action, but I can't see it there either.

If that really broke from TB 38 to TB 45 this report comes very late :-(

What do you know about "reply with template"?

Comment 2

[:aceman]

As written at https://dxr.mozilla.org/comm-central/rev/07ccae5d880ba9f0e798b061abfe00fb100568d0/mailnews/base/search/content/searchWidgets.xml#126, the "reply with template" filter action gets hidden if there are no templates created yet.

I tried it now on TB 45.7 and it seems to work. If you create a template, the item gets exposed and you can create a filter with the action.

Comment 3

[Jorg K (CEST = GMT+2)]

I can see it now. However, the complaint is that the created filter doesn't do anything. Have you tried that? I'll try it later.

Comment 4

[Jorg K (CEST = GMT+2)]

So I won't forget.

Comment 5

[Jorg K (CEST = GMT+2)]

I tested this now. I created myself a rule whose action is "Reply with Template" on an e-mail received from [e-mail]. Then I sent myself an e-mail where I changed my From address to this address.

The e-mail was received and an answer was automatically sent out with this subject:
  Auto: (was: test)
This reply went to [e-mail], it's in my Sent folder and it was also received.

So, as far as I can see, it's all working. I've been testing with TB 54, latest Daily. But if this supposedly worked in TB 38, then there's little chance for it to be broken in TB 45 and now working again. Although, anything is possible (sadly).

The one thing I noticed is that the template is used was a template stored in "Local Folders" and not a template in the Templates folder of the account in question. Also, I saw no way to configure the template to be used.

So does anyone know how that's supposed to work. While trying to find an answer, I found bug 21210, bug 988817 and http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Using_Templates which says:
  If you want to automatically reply, ie autoreply for "out of office" or similar reasons,
  you can use templates in a message filter rule.

Question remains: Which template does it use and how do you configure that? In the rule definition the field to the right of the action is empty.

Comment 6

[Jorg K (CEST = GMT+2)]

Sorry, I had the templates folder of the account set to "Local Folders" in the account settings under "Copies & Folders". Also, my template didn't have a subject line, so the template selection to the right of the action "Reply with Template" was empty. After pointing the templates folder to the correct location, I get a nice choice of templates offered in that field.

Conclusion: All working, at least on a POP account. Maybe IMAP is a problem.

Comment 7

[Jorg K (CEST = GMT+2)]

Tested in IMAP setup. All working there as well.

Comment 8

[eicker]

Hi Jorg et al,

thanks a lot for your work. It seems to be a problem with my machine / account then. Here is what I get in my filter log file:

[31.01.2017 11:15:08] Filter "Eingangsbestätigung" auf die Nachricht "EI Systems, Andreas Eicker" <[e-mail]> - Test autoresponse am 31.01.2017 11:15:03 angewendet beantwortet 

It states that it responded to my testmail but it didn't.
The mail-address I'm applying this filter to is a sign in mail for our mountain bike kids club - by investigating more in detail I found out that the filter did indeed send a reply out twice - while we had 124 mails coming in...

I moved my profile from machine to machine, added and deleted accounts over the years - is there a way to repair / reset an account to defaults?

Comment 9

[Jorg K (CEST = GMT+2)]

Thanks for getting back. Yes, I know, accounts can get tangled up. I did a clean-up of my accounts in the prefs.js file the other day, but you need to be EXTREMELY careful not to smash anything.

The only good documented way to start again is to start with a new profile, but then you have the problem to migrate your e-mail over there.

This is really a support case and we don't have time here to support 25 million users. Try:
https://support.mozilla.org/en-US/products/thunderbird

Comment 10

[jimimaseye]

(In reply to Jorg K (GMT+1) from comment #9)
> Thanks for getting back. Yes, I know, accounts can get tangled up. I did a
> clean-up of my accounts in the prefs.js file the other day, but you need to
> be EXTREMELY careful not to smash anything.
> 
> The only good documented way to start again is to start with a new profile,
> but then you have the problem to migrate your e-mail over there.
> 
> This is really a support case and we don't have time here to support 25
> million users. Try:
> https://support.mozilla.org/en-US/products/thunderbird

I have this very same problem too.  I dont believe it is an individuals issue.  My report is the same as the original poster.

V38 worked fine, v45 does not.

Accounts are IMAP.  The account has 2 x templates in it - of which 1 is chosen as the REPLY WITH TEMPLATE filter. All messages and templates are help on the server (not local folders). Whether the incoming email arrives by delivery or the filter is ran manually it doesnt matter:  in btoh cases the Replay With Template action fails (all other actions following (if the exist) such as move to Trash do fire correctly)

I have tried this on several installations - all v45 and all of them were working fine on v38 before updating.

Comment 11

[Jorg K (CEST = GMT+2)]

Sorry, I tried it again in an IMAP setup with TB 45.7.1. It works for me. The only filter I had was "reply with template" on a message having HUHU in the subject.

Comment 12

[jimimaseye]

That simply tells me that the conditions of your test do not match the same conditions of mine.  You can see in my fresh report (https://bugzilla.mozilla.org/show_bug.cgi?id=1346548) that if I restore back to a v38 then it works fine (as it did anyway before v45).

V38 - works
v45 - doesnt work.  Same data, profile and mail server.  Both reported by me and eicker above.
v38 works. Same profile, no 'cleanup' or refrsh performed, simply the application reverted back.

The only difference is the version of Thunderbird

Ive tested this on several machines, several accounts, with several actions and templates to choose from.  And the results are always the same.

Now, obviously, the conditions are not the same otherwise you would be experiencing them the same as us.  However, it isnt for us to search and change our system and way of working to try to get them to work (as it does for you) - I consider our expectation and setup to be perfectly normal and ordinary. I am not doing anything that shouldnt be expected of thunderbird given its features and the fact it was working all the way up to v38.  I see from the changelog/bugzilla that there were a few modifications/fixes relating to the Reply With Template feature for v45.  Coincidence that now we are having problems with it? I doubt it.

Now, lets say that you were even able to reproduce it.  Then what?  How does it help to see just what we have reported?  Isnt there something I can provide you with (given I already have it failing)?  Im not a coder or anything but if there is some sort of debug logging that can be enabled and provide you with the results then let me know.

Comment 14

[Jorg K (CEST = GMT+2)]

If we can reproduce it, we have a chance to fix it. Impossible to fix something that doesn't fail for us.

So, perhaps you can reduce it to the minimum rule set that fails, maybe even one single rule.

Then attach the msgFilterRules.dat here or e-mail it to me.

Comment 15

[Jorg K (CEST = GMT+2)]

OK, well, if you insist I can reopen this one to "unconfirmed". We still need a reproducible case.

Comment 16

[jimimaseye]

The full contents of the msgFilterRules.dat ('mycompany' replacing our domain name):

---------Start--------
version="9"
logging="yes"
name="Reminder to start using COUK"
enabled="yes"
type="17"
action="Reply"
actionValue="imap://sales%40mycompany.co.uk@localhost/Templates?messageId=[e-mail]&subject=Email notification - IMPORTANT: mycompany email address change"
condition="AND (all addresses,contains,mycompany.com) AND (all addresses,doesn't contain,mycompany.co.uk) AND (subject,doesn't contain,[SPAM]) AND (status,isn't,read)"
-------End -----------

The condition can be anything you want (for a test I even said 'where subject=testword' and then sent in an email with the subject as "testword")

Comment 17

[Jorg K (CEST = GMT+2)]

Hmm, I don't quite understand the |AND (status,isn't,read)| bit. So the rule will only execute on unread messages. Is that intentional?

Here's the filter that works for me:

===
version="9"
logging="no"
name="Subject contains: HUHU"
enabled="yes"
type="17"
action="Reply"
actionValue="imap://[e-mail]/INBOX/Templates?messageId=[e-mail]&subject=jk"
condition="AND (subject,contains,HUHU)"
===

Comment 18

[jimimaseye]

Yes, that is intentional.  Under normal circumstances these emails are marked as read and sent to Trash and the actual intended recipient doesnt see them.  However, as admin, I might see it and decide it needs actioning anyway (instead of waiting for the original sender to resend to the correct address).  In this case I will drag it from trash and drop it in to Inbox.  By checking the READ status I can control whether the reply with templte will get actioned or not (if I dont want it to be actioned I just ensure the message has a 'read' status.

ie,
UNREAD = send the reply
READ = dont send the reply



I admit this is all truely bizarre.  The filters look simple (whether you fully understand my reasoning or not) but in any case v38 and v45 behave differently.  Im still doing more tests and see if I can pinpoint anything.

Comment 19

[jimimaseye]

Could you look in the code and explain what conditions are met when the following message is issued:

"Applying filter [name of filer] failed. Would you like to continue applying filters?"

Because I now have a situation where this happens EVERY time there is an email matching the filter condition.  It simply doesnt make sense.  Message filters have been deleted, tested, and recreated, tested.  In every case whenever there is an email message to be processed by the fileter the above message happens when manually run.

Comment 20

[jimimaseye]

Note, Further from my last comment:

if I change the Action from 'Reply With Template' to something such as 'Mark as read' (thus removing the reply with template action), then I dont get the "Applying filter..." error.

There is DEFINITELY something wrong with this version.

Comment 21

[Jorg K (CEST = GMT+2)]

Well, I created that filter you have with "(status,isn't,read)" together with a message that matches the rest of the filter conditions. If I make that message read, nothing happens. If I make the message unread, I get exactly the message you described in comment #19.

Even if I drop that condition, I get that message now. If I move the message out of the way, the filters work again.

Comment 22

[jimimaseye]

Exactly.  Always getting s the message (if a message exists that matches).  The only way to stop the error message is to either removing matching messages OR change the filter to NOT do a 'Reply With Template'.

So you agree there is something weird going on?

Comment 23

[jimimaseye]

I restored my profile (from the working v38) and started again - now Ive stopped that Error appearing and am back to simply the Template Message not being sent/is skipped as originally reported.

Comment 24

[Jorg K (CEST = GMT+2)]

(In reply to jimimaseye from comment #22)
> So you agree there is something weird going on?
Yes, but only when you *manually run* the rules. In comment #10 you said something else.

If I find the time, I can look into the "manually run" case.

Comment 25

[jimimaseye]

Indeed in comment 10 I did say something else.  But if you look at the other bug report (that you closed as a duplicate) https://bugzilla.mozilla.org/show_bug.cgi?id=1346548 you will see that I demonstrated (with screen shots) that BOTH of these problems existed and I think are intrinsically linked.

It simply cannot be coincidence that none of these problems occur for me (or eicker) in v38, and yet we both have them in v45, and that both problems refer to the use of 'Reply With Template'.  I suggest that even though you cannot replicate both problems as we have and can only replicate the one, that if you look in to the one problem you recognise (comment 24) hopefully you will identify and fix the fundamental issue that cause both problems in our environments.

Comment 26

[Jorg K (CEST = GMT+2)]

I appreciate your persistence.

Your screenshot in attachment 8846305 [details] only covers the "manually run" case which I *can* also reproduce.

I have once again tested the "reply with template" on message receipt, this time even with a rule that had "(status,isn't,read)". It worked for me.

I can't tell yet what I will find when I do the analysis for the manual run case, but just to reiterate: Problems that I can't reproduce are impossible to fix since there is no proof that they are fixed since they didn't occur in the first place.

Over in the other bug 1346548 you stated that for the "not manually run" case your filter log says that the filter did apply. So since you seem to be wanting a fix for the problem, perhaps you can help in the diagnosis.

Start Thunderbird with -p and create yourself another clean, fresh profile. In there, create your IMAP account, create a template and create the simplest of rules: Reply with template if HUHU is in the subject. Then send a message there while TB is running on that profile. See what happens. If something doesn't work, we need to strip down all complication and try to find the element that causes the bug.

Thank you for your collaboration.

Comment 27

[jimimaseye]

I will do anything I can to help and would be glad to.  (As long as you are guiding me on the technicalities and "How To"s).

I will do as you request and report back.

Comment 28

[jimimaseye]

v45.8

Well, you wont believe me.

Brand new install, from scratch, new profile, set up the account and pointed it to the server, set up the messagefilter and tested.

Result:  the same.  It fails to send the reply.  And it also gives the 'Applying filter...fails' when run manually.

I even set up a new template and pointed at that instead.

I dont know what to say to you except offer you a private direct connection for you to see it yourself.

What does the -p flag do?  Is there anyway a debug log file can be created that will help you?

Comment 29

[Jorg K (CEST = GMT+2)]

OK, TB 45.8, new profile. Configured existing IMAP account, created filer (to execute before junk classification) to reply with template when message with HUHU is received. While TB 45.8 was running, sent a message from anther client to that account. Reply with template works as tested a felt million times now.

Next test: Sent a message to that account while TB 45.8 wasn't running. Checked that message had gotten there with other client, then opened TB 45.8 on the account. Result: Message received and reply sent.

Let's not discuss the "run manually", we agree that gives an error.

I'll accept the offer of a private connection. Send me the details in a private message. You find my e-mail address in my account details here.

Alternatively I can send you some account details for an e-mail server I control so see whether that works differently.

Comment 30

[jimimaseye]

It's all very weird.  Whatever the combination of factors are (Operating system version, Thunderbird (production or beta v51), or template (as long as it is using a Reply With Template action) I know it works under v38 and yet seemingly randomly doesnt from 45 onwards.

In response to comment 29 I have sent you an email. Cheers.

Comment 31

[jimimaseye]

I give up with this.  I have performed extensive testing and all results just continue to cause confusion.

1, I have tested by using template of HTML only, PLAIN text only, BOTH multipart.  I have sent in test emails in each case of HTML only, PLAIN text only, and multipart.  These same 9 tests have been ran on TB v45 on win7 Laptop and Server 2008 and in every case it fails to create the reply.  Furthermore, when doing a forced MANUAL run the 'Applying filter...fails' occurs.  I am convinced tney are related and finding the cause of that will solve the other.  My reasoning for this is that a manual run is interactive and therefore a message can be presented whereas an automatically triggered filter happens in the background - in both cases the message from template is not generated.

The test is a simple one: the trigger is only where SUBJECT="TEST2" and the action is only "Reply With Template".

The above test has been performed against CLEAN installations (fresh profiles with the account create from scratch) and also on existing profiles that were included in an established installation that has been version upgraded through time.   The results are the same.

2, Log monitoring (both TB logging and mail server logging) shows ZERO SMTP communication - this is because TB client application is errorring and failing to generate from the template.

3, This never happened up to and including v38. If I revert back or load up a fresh v38 and do the above tests I *NEVER* get an error.  I can do it with an old profile or a fresh profile and I never get the error.

3, I previously mentioned (maybe in private conversation) that I had limited success on the Win7 pc.  This was incorrect. I got confused in switching around versions and actually was using v38.  V45 on win7 home laptop, and on windows server 2008 both fail to create the template

Now for the further confusion:

4,  doing a test to a test account run on a server provided for testing with (by Jorg) does not show the error.  This therefore suggests that it must be the SERVER that is the cause.  However:

a, it is the client that generates emails, not the server
b, no communications are being made with the server at this time.
c, under exactly the same scenario and environment v38 works fine.

5,  The log file from a WORKING v38 shows IMAP communications where the generation of the email is created and so (through IMAP) it reads the template:

2017-03-13 15:04:21.279000 UTC - 0[2711140]: proposed url = INBOX folder for connection Sent has To Wait = FALSE can run = FALSE
2017-03-13 15:04:21.279000 UTC - 0[2711140]: proposed url = INBOX folder for connection INBOX has To Wait = FALSE can run = TRUE
2017-03-13 15:04:21.279000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:SendData: DONE

2017-03-13 15:04:21.279000 UTC - 4712[ea868a0]: ReadNextLine [stream=f4de6a0 nb=23 needmore=0]
2017-03-13 15:04:21.279000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:CreateNewLineFromSocket: 16 OK IDLE terminated

2017-03-13 15:04:21.279000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:ProcessCurrentURL: entering
2017-03-13 15:04:21.279000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:ProcessCurrentURL:imap://larry%40mydomain%2Eco%2Euk@localhost:143/addmsgflags%3EUID%3E.INBOX%3E5193%3E2:  = currentUrl
2017-03-13 15:04:21.279000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:SendData: 17 uid store 5193 +Flags (\Answered)

2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: ReadNextLine [stream=f4de6a0 nb=46 needmore=0]
2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (FLAGS (\Answered \Seen) UID 5193)

2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: ReadNextLine [stream=f4de6a0 nb=21 needmore=0]
2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:CreateNewLineFromSocket: 17 OK UID completed

2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:SendData: 18 IDLE

2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: ReadNextLine [stream=f4de6a0 nb=10 needmore=0]
2017-03-13 15:04:21.357000 UTC - 4712[ea868a0]: f34d800:localhost:S-INBOX:CreateNewLineFromSocket: + idling

2017-03-13 15:04:21.513000 UTC - 0[2711140]: proposed url = Sent folder for connection Sent has To Wait = FALSE can run = TRUE
2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:SendData: DONE

2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ReadNextLine [stream=acea2e0 nb=22 needmore=0]
2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:CreateNewLineFromSocket: 9 OK IDLE terminated

2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:ProcessCurrentURL: entering
2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:ProcessCurrentURL:imap://larry%40mydomain%2Eco%2Euk@localhost:143/appendmsgfromfile%3E.Sent:  = currentUrl
2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:SendData: 10 append "Sent" (\Seen) {1612}

2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ReadNextLine [stream=acea2e0 nb=26 needmore=0]
2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:CreateNewLineFromSocket: + Ready for literal data

2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:SendData: To: jim <[e-mail]>

Subject: Email notification - IMPORTANT: mydomain email address change (was:

 test2 html)

From: larry <[e-mail]>

Message-ID: <[e-mail]>

Date: Mon, 13 Mar 2017 15:04:21 +0000

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101

 Thunderbird/38.5.0

MIME-Version: 1.0

2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: Content-Type: text/html; charset=utf-8

Content-Transfer-Encoding: 8bit



<html>

  <head>

    <meta http-equiv="content-type" content="text/html;

      charset=windows-1252">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

   body text
  </body>
</html>



2017-03-13 15:04:21.513000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:SendData: 

2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ReadNextLine [stream=acea2e0 nb=14 needmore=0]
2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:CreateNewLineFromSocket: * 335 EXISTS

2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ReadNextLine [stream=acea2e0 nb=12 needmore=0]
2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:CreateNewLineFromSocket: * 2 RECENT

2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ReadNextLine [stream=acea2e0 nb=24 needmore=0]
2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:CreateNewLineFromSocket: 10 OK APPEND completed

2017-03-13 15:04:21.637000 UTC - 0[2711140]: CopyNextStreamMessage: Copying 1 of 1
2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:SendData: 11 IDLE

2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ReadNextLine [stream=acea2e0 nb=10 needmore=0]
2017-03-13 15:04:21.637000 UTC - 3348[ea871d0]: ace8800:localhost:S-Sent:CreateNewLineFromSocket: + idling


However, under the failing v45 not a single line of text is generated in the log which would go hand-in-hand with the idea of the TB application failing prior to it looking up the Template.  Naturally, no SMTP logging takes place either as there are no emails generated.


I still firmly believe that an investigation in to the 'Applying filter...fails' error will uncover or point in the direction of the overall cause. It may well also help then realise what the very specific conditions are that shows why it worked under the Jorg environment and not this one.

According to bugzilla, there were mods made to v45 since v38 regarding the Reply With Template and its likely they have the answer (or cause).

It simply isnt right to suggest I am the only one with the problem as 'Eicker' already posted this original report. It does mean that (at the moment) only I am:
a, USING the feature and
b, I am operating under the *specific set of conditions* that causes this problem to v45 AND
c, that I am bothered to report it.

If I am matching the conditions, then its highly likely that others could too and it is only right the TB doesnt leave open such opportunity for these conditions to cause error. (After all, they didnt in v38).

Meantime, I cannot think of any more ways of doing detailed testing. I am open to offers if someone would like to guide me further but until then I am now disappointingly restricted to never upgrading from v38.

Comment 32

[Jorg K (CEST = GMT+2)]

Thanks for testing this.

(In reply to jimimaseye from comment #31)
> 2, ... this is because TB client application is errorring and failing to generate from the template.
But you don't see any error message or error in the error console?

> 4,  doing a test to a test account run on a server provided for testing with
> (by Jorg) does not show the error.  This therefore suggests that it must be
> the SERVER that is the cause. 
So using the server I provided always works?

> According to bugzilla, there were mods made to v45 since v38 regarding the
> Reply With Template and its likely they have the answer (or cause).
You know more than I do, which bug was that? I've been with the project since TB 38 and I don't remember any changes in that area. However, it's possible that we changed something that causes your particular setup not to work.

Comment 33

[eicker]

Hi all,
now that there is lots of activity again, I retested my setup, with a clean profile, but still I don't get replies - now on TB 45.8. The error console stays empty... The filter log states, that it send the reply out - although it does not mention any message IDs?
Since I had on this machine once a problem (different software) with loading dlls when not running the program as administrator, I tried to run TB as admin - to no avail.
I can live without it - but if I can do anything to help, I'm happy to do so.

Regards,

Andreas Eicker

Comment 34

[jimimaseye]

I have got even MORE weird results (not that I thought I could).

I have (for example) 2x EXISTING email accounts on our mail server.  These were tested (in the method described above - by adding them to a fresh new profile etc) and by using an external mail address to send in the trigger mail.  Result:  no reply sent.

I then created a NEW mail account on the mailserver ("tbtest"), added that account to the same TB install (so now have 3x accounts), and created an identical setup with the messagefilters.  I then sent in a trigger email addresses to all 3 accounts.  The 2x old ones still do not respond but the 3rd account does!  Same TB session, same setup, same mail server, same incoming trigger email. 

So.... one more test (if we havent got enough confusion going on here....keep reading for more weirdness.....)

Using the new account "tbtest" I sent in a trigger message to the old accounts.....and the old accounts reply correctly!

So, the old accounts reply correctly to an internal account but not to external accounts whilst the new account DOES reply to internal and external accounts - but of course the concept of 'internal' and 'external' accounts are statuses that TB doesnt know about (an account is just an account).

Can anyone see any flaw in this that I am over seeing that I havent tested?

Comment 35

[jimimaseye]

And of you REALLY want to see the weirdness in action, I will summarise one of the points above.

An account has 2x trigger emails in it (with a subject text of "test2" as the trigger).  One from an account on this server, and one that came in from yahoo.  If I highlight the message and click Tools - "Run Filters on MESSAGE":  the yahoo one fails to get a response (accompanied with the the 'Applying filter...failed' error) whilst the other message doesnt fail and a template-based reply gets sent.

Go figure!

This, Jorg, is why you cannot reproduce the error.  Clearly there is something VERY black-magic like in here that you are not matching in your setup/environment.  But it IS there and real.

Any ideas welcome.

Comment 36

[Magnus Melin [:mkmelin]]

I did fix a bunch of things for "reply with template" for tb45 (bug 405063, bug 561568, bug 904458). IIRC there was also one related to sending from wrong identity. I'd check the From/Reply-To (and Auto-submitted) headers of the incoming mails, and see if there's anything there.

Comment 37

[Jorg K (CEST = GMT+2)]

BINGO!! Jim, we solved your riddle!

Look at this which was added in TB 46 and uplifted to TB 45:
https://hg.mozilla.org/comm-central/rev/623f54877594#l1.13
The reply address is at first retrieved from the Reply-To: header, in the second place from the From: header.

In comment #34 it is reported that everything works when sending form a new account, which doesn't have a Reply-To: set up.

So the problem is triggered by the Reply-To: header!!

So apart from some bug that shows in filter processing when run manually, there may be another bug:

"Reply with template fails (silently?) if something is bogus with the Reply-To: header", or maybe:
"Reply with template doesn't send to own address if own address is contained in the Reply-To: header"
or similar.

Comment 38

[jimimaseye]

I disagree that this is the cause of all problems.

This is the message source from an email that fired the messagefilter successfully and successfully received the template reply:

>Return-Path: [e-mail]
>X-hMailServer-ExternalAccount: decdotcom
>Return-Path: <[e-mail]>
>From: Jim <[e-mail]>
>Subject: test4
>To: [e-mail], [e-mail]
>Message-ID: <[e-mail]>
>Date: Mon, 13 Mar 2017 19:46:00 +0000
>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
> Thunderbird/45.1.1
>MIME-Version: 1.0
>Content-Type: multipart/alternative;
> boundary="------------39A4E77EC73F3BA4FB01EEEC"
>
>This is a multi-part message in MIME format.
>--------------39A4E77EC73F3BA4FB01EEEC
>Content-Type: text/plain; charset=utf-8; format=flowed
>Content-Transfer-Encoding: 7bit
>
>
>
>--------------39A4E77EC73F3BA4FB01EEEC
>Content-Type: text/html; charset=utf-8
>Content-Transfer-Encoding: 7bit
>
><html>
>  <head>
>    <meta http-equiv="content-type" content="text/html; charset=utf-8">
>  </head>
>  <body bgcolor="#FFFFFF" text="#000000">
>  </body>
></html>
>
>--------------39A4E77EC73F3BA4FB01EEEC--

Note the LACK of "Reply-To".  And yet, it still worked.




And now here is a messagesource of an email that failed to trigger the very same filter:

>Return-Path: [e-mail]
>X-hMailServer-ExternalAccount: decdotcom
>Return-Path: <[e-mail]>
>From: Jim <[e-mail]>
>Subject: test5
>To: [e-mail]
>Message-ID: <[e-mail]>
>Date: Mon, 13 Mar 2017 19:47:31 +0000
>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
> Thunderbird/45.1.1
>MIME-Version: 1.0
>Content-Type: multipart/alternative;
> boundary="------------D44255B3827B2C55C4794914"
>
>This is a multi-part message in MIME format.
>--------------D44255B3827B2C55C4794914
>Content-Type: text/plain; charset=utf-8; format=flowed
>Content-Transfer-Encoding: 7bit
>
>
>
>--------------D44255B3827B2C55C4794914
>Content-Type: text/html; charset=utf-8
>Content-Transfer-Encoding: 7bit
>
><html>
>  <head>
>    <meta http-equiv="content-type" content="text/html; charset=utf-8">
>  </head>
>  <body bgcolor="#FFFFFF" text="#000000">
>  </body>
></html>
>
>
>--------------D44255B3827B2C55C4794914--

IT IS IDENTICAL (except dates and message ID's) and for good reason: it was the same email client of the same account on the same machine and simply a 'Edit As New' resend.   And yet this failed to send the template reply (despite being marked as 'replied' due to thunderbird THINKING it had replied).  That too has no reply-to and has the same FROM address which is perfectly valid and perfectly good enough to receive the first reply message above.

And I know that the trigger is activated on both messages as

a, the criteria is very specific
b, there is a multi-action response (reply with template & Tag for example which highlights it as actioned)


So, there may be something in the conclusion made regarding the reply-to field but it surely isnt the cause of my problems.  No accounts of mine use 'reply-to' headers and all FROM addresses are perfectly valid.  And yet there are erroneous responses when it comes to successfully carrying out the trigger messagefilter.

Comment 39

[jimimaseye]

Error correction in my last post comment 38:

I said:
" failed to trigger the very same filter:"

I meant 

" failed to successfully carry out the trigger".  

the trigger is fired but it fails to deliver due to the elusive error.

Comment 40

[Jorg K (CEST = GMT+2)]

(In reply to Magnus Melin from comment #36)
> I did fix a bunch of things for "reply with template" for tb45 (bug 405063,
> bug 561568, bug 904458). IIRC there was also one related to sending from
> wrong identity. I'd check the From/Reply-To (and Auto-submitted) headers of
> the incoming mails, and see if there's anything there.

Magnus, there's nothing to look at since I don't have a reproducible failure. Bug 405063 was about an empty From: field (and it modified the behaviour a little looking at Reply-To: as well), bug 561568 was about charsets and bug 904458 was about modifying the subject and adding another header. I don't see how any of this is related to the bug described here. Well, for a minute I thought it had to do with the Reply-To: processing which has changed a little.

In comment #34 the reporter writes that messages sent form a new account trigger the auto-reply, comment #38 claims that it depends on how many recipients the triggering message is sent to. Also the attempt to obfuscate e-mail addresses make for a very confusing mix.

Let's do this: I have two domains at my disposition. jorgk.com and hostalpancheta.es. On the first one, I have multiple e-mail addresses. Given these, tell me exactly which filters I should create on which account and from where to where to send e-mail (with exact details of the recipients). I'm happy to recreate the scenario with the accounts I have.

Comment 41

[jimimaseye]

>Let's do this: I have two domains at my disposition. jorgk.com and hostalpancheta.es. On the first one, I have multiple e-mail addresses. Given these, tell me exactly which filters I should create on which account and from where to where to send e-mail (with exact details of the recipients). I'm happy to recreate the scenario with the accounts I have.

And I also would be happy for your to create it with your accounts. But I cannot at this time give you this scenario.

If you read back through my comms (in the thread and the private emails exchanged with you) you'll see that I simply cannot identify a single scenario that suits to ALWAYS make the failure to successfully generate a reply with the template occur.  And that confounds the problem.  (The problem exists, I see it happening, ('Eicker' sees it happening), but trying to reproduce it using the same conditions but under any change/difference to the environment MAY not show the problem - where "environment" consists of account, email client OS, filter trigger criteria, etc.  The only thing that IS consistent that the same filters NEVER failed on TB v38 irrespective of the 'environment' they were run under.

Although I have pretty much exhausted my time, patience and combinations of testing for this (still leading to nothing conclusive) I will keep trying.  When I find a condition that fails to operate correctly, and I can reproduce it using a different environment (but with the same trigger criteria) I will let you know.

The offer of Teamviewer to see the failures in situ. and work on the failing environment as I see it still stands (although all you will see is what I (hopefully) have already explained and I like to think I and 'Eicker' are being believed).

Comment 42

[jimimaseye]

From comment 40
> Let's do this: I have two domains at my disposition. jorgk.com and hostalpancheta.es. On the first one, I have multiple e-mail addresses.

The "tbtest" account on my server is set up (as previously advised) and it will allow you to send (only) to addresses on the two domains you stated.

Comment 43

[Jorg K (CEST = GMT+2)]

Let's do a Teamviewer session to see the failures. Wednesday afternoon? During that session I will send a PM from one of my accounts to see whether the rule gets triggered or not (which I expect it would since sending from your new account also works, see comment #34). Then I'll let you operate it to see it not working.

In preparation, please download http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central/thunderbird-55.0a1.en-US.win32.zip and unpack it, so we can use this debug version to see whether there is any debug output in the failing case.

Comment 44

[Jorg K (CEST = GMT+2)]

Sorry, wrong link, for debug we need this one:
https://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-central-win32-debug/1489479575/thunderbird-55.0a1.en-US.win32.zip

Comment 45

[jimimaseye]

Jorg,  ok I have downloaded and it is in place awaiting tomorrow.  Meantime I Have just ran it against one example (of a manual fail) I quoted earlier (where the 'failed to apply...' message pops up:

>[2208] WARNING: ReplyWithtemplate failed: file c:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mailnews/base/search/src/nsMsgFilterService.cpp, line 786
>++DOCSHELL 12B0F000 == 12 [pid = 2208] [id = {7397755c-46ce-4ddb-ba23-b988746a5b62}]

Does it help?

Comment 46

[Jorg K (CEST = GMT+2)]

It tells us that sending the reply failed for some reason:
https://dxr.mozilla.org/comm-central/rev/d03f6d1f69374c85d4939d0c7cb92021614600f4/mailnews/base/search/src/nsMsgFilterService.cpp#786
This needs detailed debugging.

Comment 47

[jimimaseye]

Its worth remembering I HAVE NO IDEA what that console window is reporting when it 'does stuff'.  However, I do note that line (quoted) appearing when the manual fail was run and the error "Failed to apply..." window was issued (so I guess it all makes sense).

I then watched that console window when messages are received and the trigger of messagefilters are actioned and unfortunately that window doesnt do/show anything at all (even when it is correctly firing off a template).  So I was unable to make a comparison and, alas, thats the end of my input on this debug version/console window.

I have the environment all ready for you tomorrow.  Hopefully you have the tools to be able to use it to identify what is going on (presumably doing 'step through's or verbatim logging or something.)

Email me to your preferred time for tomorrow.

Comment 48

[Jorg K (CEST = GMT+2)]

OK, I had a Teamviewer session with Jim today and he showed me that incoming messages that matched subject or "From, To, CC, Bcc contains" rules don't send replies in some cased, although filter log says so. Also, when manually run, an error is shown, and when clicking "Cancel" on the error message panel, we got a reproducible crash in the debug version we used (maybe that was just a MOZ_ASSERT, I didn't check).

Running filters manually (or after SPAM classification) runs so-called "after the fact" rules in nsMsgFilterAfterTheFact::ApplyFilter() here:
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mailnews/base/search/src/nsMsgFilterService.cpp#785
That's where the warning reported in comment #45 comes from.

Applying filters to received messages (before SPAM classification) is specific to POP and IMAP processing:
POP:
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mailnews/local/src/nsParseMailbox.cpp#2345
IMAP:
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mailnews/imap/src/nsImapMailFolder.cpp#3749

Looking at the IMAP code, when it fails, it will fail just silently since there is zero error checking.

I will compile a special version for Jim to try that will at least report errors.

Comment 49

[jimimaseye]

Cheers Jorg, noted.  Awaiting your special version.

Comment 50

[Jorg K (CEST = GMT+2)]

OK, in an hour or two, you can download a debug build from here:
https://archive.mozilla.org/pub/thunderbird/try-builds/[e-mail]-6f3dfeb4ba99caed6a44802891e66a416d7a8673/

For me that prints using the HUHU in the subject rule:
=== DEBUG FOR JIM: Writing to log: Applied filter "huhu" to message from Jorg Knobloch <[e-mail]> - HUHU at 3/24/17, 11:39:51 PM
replied

=== DEBUG FOR JIM: Before ReplyWithTemplate
=== DEBUG FOR JIM: ReplyWithTemplate returned 0

So the funny thing is, we log the success before we attempt the action. And never mind the result :-(

Comment 51

[jimimaseye]

(In reply to Jorg K (GMT+1) from comment #50)
> OK, in an hour or two, you can download a debug build from here:
> https://archive.mozilla.org/pub/thunderbird/try-builds/[e-mail]-
> 6f3dfeb4ba99caed6a44802891e66a416d7a8673/
> 
> For me that prints using the HUHU in the subject rule:
> === DEBUG FOR JIM: Writing to log: Applied filter "huhu" to
> message from Jorg Knobloch <[e-mail]> - HUHU at 3/24/17,
> 11:39:51 PM
> replied
> 
> === DEBUG FOR JIM: Before ReplyWithTemplate
> === DEBUG FOR JIM: ReplyWithTemplate returned 0
> 
> So the funny thing is, we log the success before we attempt the action. And
> never mind the result :-(

Where is the output of interest going to appear?  In the console screen or....?

Comment 52

[Jorg K (CEST = GMT+2)]

Yep, on the debug console, the window that looks like a DOS window.

Comment 53

[Jorg K (CEST = GMT+2)]

https://archive.mozilla.org/pub/thunderbird/try-builds/[e-mail]-6f3dfeb4ba99caed6a44802891e66a416d7a8673/try-comm-central-win32-debug/thunderbird-55.0a1.en-US.win32.zip

Comment 54

[jimimaseye]

Okay, here are the results.  It seems the key errorcode you are looking for is "80004004":

I will list the output in 2 parts.  A is the output when the email is RECEIVED and the message filter should be applied automatically, and B is when a manual run is applied with "Run Filters On Message".


First for comparison, here are the logs for a SUCCESSFUL (failure-free) operation when the client behaves correctly and applies the filter:

A (automatic sending)

>=== DEBUG FOR JIM: Writing to log: Applied filter "templatetest" to message from user1 <[e-mail]> - test4 BOTH at 3/25/17, 11:06:31 AM replied
> 
>=== DEBUG FOR JIM: Before ReplyWithTemplate
>=== DEBUG FOR JIM: ReplyWithTemplate returned 0

B When manually "Run On Message":

>=== DEBUG FOR JIM: Writing to log: Applied filter "templatetest" to message from user1 <[e-mail]> - test4 BOTH at 3/25/17, 11:06:31 AM replied



Now the Log output for when an UNSUCCESSFUL operation occurs where the messagefilter 'reply with template' fails to apply:

A (automatic sending)

>=== DEBUG FOR JIM: Writing to log: Applied filter "templatetest" to message from user1 <[e-mail]> - test5 COM only at 3/25/17, 11:05:22 AM replied
> 
>=== DEBUG FOR JIM: Before ReplyWithTemplate
>=== DEBUG FOR JIM: ReplyWithTemplate returned 80004004


B Manual Run On Message

>=== DEBUG FOR JIM: Writing to log: Applied filter "templatetest" to message from user1 <[e-mail]> - test5 COM only at 3/25/17, 11:05:22 AM replied
> 
> [3552] WARNING: ReplyWithtemplate failed: file c:/builds/moz2_slave/tb-try-c-cen-w32-d-00000000000/build/mailnews/base/search/src/nsMsgFilterService.cpp, line 786

(at which point you get the 'Failed to apply' message window)

Hope it helps.  I am at your disposal for further tests.

Comment 55

[Jorg K (CEST = GMT+2)]

It helps!

As I explained in comment #48, running a filter manually ("after the fact") and when something is received are two totally different code paths, which of course both call ReplyWithtemplate(). On the manual run, the code already had some error checking, hence the WARNING, on the "reply on receive", there was none, so I added some debug.

This findings confirm what I suspected: Sending the reply fails in the "reply on receive" case just as well as on manual run, although I don't have its exact error code. That's the commonality.

Now I need to investigate where the 80004004 (https://james-ross.co.uk/mozilla/misc/nserror?0x80004004, NS_ERROR_ABORT) comes from. Sadly a very frequently used error code. But since I have a reproducible manual case, there's hope that fixing that might also fix the "reply on receive" case, as Jim has always said ;-)

Thanks for your help and patience and persistence, I'll get it sorted ;-)

Comment 56

[Jorg K (CEST = GMT+2)]

If you look at comment #21, I claim to be able to reproduce the problem when running the rule manually. I just repeated that test and now it passes, no error.

However, I found the problem, NS_ERROR_ABORT is only issued here
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mailnews/compose/src/nsMsgComposeService.cpp#901
in the function nsMsgComposeService::ReplyWithTemplate().

This error is only returned from TB 45, as Jim always said, and was introduced in bug 904478, a bug Magnus sadly didn't mention when he listed the bugs he worked on in the area in comment #36 (only mentioned: bug 405063, bug 561568, bug 904458). Look twice 904478 != 904458.

Here is the change that got landed:
https://hg.mozilla.org/comm-central/rev/79e74959cca2#l1.196

To understand what's going on, we need to read through the code from here:
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mailnews/compose/src/nsMsgComposeService.cpp#880

It tries to see whether in the recipients or the CC list of the original mail you want to auto-reply to, there is an e-mail address that matches one of the entities you have configured.

So say your client has one identity configured: [e-mail] and the e-mail is sent to [e-mail], then there will *NOT* be any auto-reply (and I have to admit, the error handling is shocking and I will fix that) if you magically, through some server tricks, deliver the e-mail into the mailbox of [e-mail].

If you send to [e-mail] *and* [e-mail] you get the reply sent and this is observed behaviour.

So bottom line is, your use-case doesn't work any more: You get an e-mail to [e-mail] and want to reply from [e-mail]. If you were to add another identity, [e-mail], then your auto-reply would be sent out via that e-mail address, which in your use-case is no good, since you want to reply from the [e-mail] address saying that the other e-mail address isn't valid any more. The only thing you could do it add an identity with [e-mail] and set its Reply-To: to [e-mail].

Jim, you can read through bug 904478 comment #0 to understand why we had to discontinue the feature.

Now that I know how to reproduce the problem, I'll improve the error handling (including looking at the crash we saw), but all that won't make you happy, I'm afraid. Anyway, we solved the riddle.

Comment 57

[Jorg K (CEST = GMT+2)]

We'll continue to improve the error handling and logging in bug 1350607.

Magnus, why do you only consider the "current" server to look for identities?
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mailnews/compose/src/nsMsgComposeService.cpp#867
Would it be better to consider all identities?

Comment 58

[jimimaseye]

Well done Jorg, good work.  Thanks for finding it and persisting...and thanks for believing me (that there was definitely something different since tb45).

I read and understood what you have said and the reasons.  I noted your workround too.

I added an identity ("[e-mail]") and I left the reply-to blank (contrary to your advice) and it solves the problem (the 'reply-to' set to ".co.uk" was not required for it to work - and I dont want them replying to this notification-only email anyway).

Its perfectly acceptable to me as the sender still receives the intended reply just like they did in earlier versions - the ONLY difference being is that the FROM will be from the very domain address that I say no longer exists (instead of the new domain as it did before in TB38).

EG, this is what they will now receive (paraphrasing the body):

>FROM: [e-mail]
>TO: [e-mail]
> 
>SUBJECT:  Auto: OLDODMAIN.COM doesnt exist.
> 
>Body:
>Dear Sender, please be aware that OLDDOMAIN.com doesnt exist anymore and you should be sending to NEWDOMAIN.co.uk (despite me sending this back to you from OLDDOMAIN.com.  Please get over it - it isnt THAT confusing.)
> 
>Regards......

(in TB38 it would have been FROM: [e-mail])

I have one question though:  the Template-based reply correctly includes the "Auto-Submitted: auto-replied" header (to prevent receiving servers auto-replying back to this auto-reply).  However, in TB45 onwards the subject also now appends "AUTO: " to the subject. eg "Auto: OLDODMAIN.COM doesnt exist."  Is there a config flag to stop this "AUTO:" being appended to the subject?  Its very ugly IMO and certainly unnecessary. (Ive searched but cant find reference).

Comment 59

[Jorg K (CEST = GMT+2)]

Hi Jim, thanks for your understanding. I hope you will move to TB 45 and TB 52 when it comes out next week, every version brings improvements and surprises ;-) I'll mark this bug as "invalid".

A side issue is that "reply with template" is really a poor man's auto-reply. Usually that can be handled better through the mail server. I hope your sample auto-reply was meant with some irony since it's not strictly customer friendly ;-)

I'm sure the original reporter can now also work out why the "auto-reply" doesn't work for him, he mentioned a "mountain bike kids club" e-mail address which might not match any of the identities he has configured.

As for the forced Auto: in the subject, that comes from bug 904458. Once again we're complying with RFC 3834 3.1.5. https://www.ietf.org/rfc/rfc3834.txt, although it's just a "should". Magnus, who implemented that, is not a great friend of preferences, so that can't be switched off.

(In reply to Jorg K (GMT+1) from comment #57)
> Would it be better to consider all identities?
Maybe not, let's forget about this question.

So I guess we're finally done here.

Comment 60

[jimimaseye]

Cheers Jorg.  Yes, this particular quirk is resolved.

> I hope your sample auto-reply was meant with some irony since it's not strictly customer friendly ;-)
Very much so. I paraphrased and exaggerated (just to highlight the contradiction of the words against the address the words are referring to).



> Once again we're complying with RFC 3834 3.1.5. https://www.ietf.org/rfc/rfc3834.txt, although it's just a "should". Magnus, who implemented that, is not a great friend of preferences, so that can't be switched off.
I think Magnus is wrong with this (not inclusing an off/on flag).  SHOULD is not a 'must' and the consequences of enablement (as default)/disablement can be considered by the end user and given the choice to use it by the means of a flag in preferences (just as 'SHOULD' is defined as being):

ie https://www.ietf.org/rfc/rfc2119.txt:
>   SHOULD: ..... there MAY EXIST valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.

...and IMO, having considered that it will cause no harm whatsoever anywhere, turning off gives a more professional and easy-readable form of subject text for those that choose to use this function by means of an auto-reply.  Not everyone has access to the mail servers that they run through and rely on their email client to do such filtering/actions.

(How do I make this point for review?  Is there any point in raising it in bugzilla?)

Comment 61

[:aceman]

Jorg, if we reject sending the reply for some reason, shouldn't that be noted at least in the filter log? Yes, the filter was run and matched the message, but the action was not executed. In comment 50 you paste the log which sais a reply was sent. It is a lie, isn't it? So maybe this part should be fixed in this bug so that other users can understand TB intentionally rejects the replies.

Comment 62

[Jorg K (CEST = GMT+2)]

Aceman: I intend to fix this in bug 1350607 if you don't mind.

Jim: I asked about a preference in bug 904458 comment #34.

Comment 63

[eicker]

Hi Jorg,
first of all: Thanks a lot for all your work you put into this!
I got hope that the problem you discovered applies to my case as well - although it is slightly different:
I apply my auto-reply to an email-alias within the same domain (IMAP): 
Mails sent to [e-mail] get delivered to [e-mail] (as set up within our mail-provider). My reply with template filter checks for mails for [e-mail] but tries to send with [e-mail].
Since our provider allows only for one mailbox, I'm limited to email-aliases and the one [e-mail] to send...
I set up a filter for the info address and it works, so the problem really is the not matching address.
As I said, it is really within the same domain, but the filter rule is against an alias.

Regards

Andreas Eicker

Comment 66

[Anje]

Thunderbird version 102.9.1

I can reproduce this error and I can also make it work to some degree.

In the Message Filter:

• If I set : 'Filter before junk classification':

• Result: The filter works as expected, but is not desirable as it means you may have an issue by auto replying to everything that comes into an Inbox.

• If I set: 'filter After junk classification':

• Result: it fails with same error code "Sending reply aborted" with error code=0x80004004. It seems you cannot use an Auto reply using a template if you select 'filter after junk classification'

Whilst it is preferable to use 'After' junk classification for obvious reasons as an auto reply may not want to be sent to spam or people just prospecting for business, it is unavoidable until fixed.

One workaround:

• set : 'Filter before junk classification':
• 'From' 'is in an address book' and select name of address book.

You can add more address books, but be careful to select 'Match any of the following' so it means FROM in any of the address books.

This would now only reply to people who are in any of the address books which should help to not include spam speculative emails.
Obviously this is not as perfect as 'after' junk classification, but it is an improvement.
If that is desirable then this workaround maybe one answer around the problem.