Re: Cannot connect to Dovecot IMAP or POP

[Joseph Tam]

C. Andrews Lavarre writes:


Presumably, as Joseph shows with his nc call, imap calls are to ServerName 
mail.privustech.com.


No, nc is just a dumb tool -- it knows nothing about IMAP or SSL.  You didn't
even get to the SSL handshake.  Your problem has nothing to do with the
interaction of client and server -- it's strictly a server problem.


ssl = required
ssl_cert = 

ssl_ca is not analogous to Apache's SSLCertificateChainFile.  I believe "ssl_ca"
is used to validate clients (i.e. mutual authentication).
You ought to concatenate your intermediate CA chain certificates and
your public key into ssl_cert.

See

http://wiki2.dovecot.org/SSL/DovecotConfiguration

Also, anything enlinghtening  in the logs when ssl_verbose turned on?

Joseph Tam 

Re: pread() failures when using mdbox on btrfs

[Timo Sirainen]

On 05 May 2016, at 16:21, Marc Joliet  wrote:
> 
> (Note: I am not subscribed to this ML, so please be sure to CC me in replies.)
> 
> Hello,
> 
> I see a strange bug when running dovecot under btrfs with a mailbox in mdbox 
> format.  At some point, which can take a few minutes or more than a day, 
> dovecot starts logging pread() failures, like so:
> 
> Apr 02 23:43:42 thetick dovecot[570]: imap(marcec): Error: pread() failed 
> with 
> file /home/marcec/.mdbox/mailboxes/LinuxAudio/User/dbox-
> Mails/dovecot.index.log: Input/output error
> 
> These would trigger when getmail runs (which in turn is configured to use 
> dovecot-lda).  It's only ever the *.index.log files, and it would usually 
> happen to the same one many times in a row.  To demonstrate, this is the full 
> list of unique pread() failures on one host (my desktop PC):

*.index.log files are always appended to using O_APPEND flag. Maybe this is 
relevant.

Also when a new .log file is created it's opened without the O_APPEND flag and 
the O_APPEND is added later. This was causing a bug recently in unionfs, which 
ignored the flag change and caused log file corruption.

> Rebooting the system would make it go away (without loss of mails), though 
> remounting the file system should have worked, too.  I tried a variety of 
> options, but the only one that helped was to convert the mailbox from mdbox 
> to 
> maildir.  I have not seen any pread() failures in the two weeks since.

I can't really think of why Maildir format would get rid of the problem, since 
the dovecot.index.log files still exist and they're accessed the same way. 
Maybe with Maildir there are enough locks that it prevents some race condition 
that triggers this.

You could try stress testing with imaptest to see if it's easy to reproduce: 
http://imapwiki.org/ImapTest

Re: Dovecot/Rainloop 2.0.13-1_129.el5

[Chris Smith]

> On 5 May 2016, at 21:03, Edgar Pettijohn  wrote:
> 
> 
> 
> On 05/05/16 14:40, Chris Smith wrote:
>> I configured Dovecot on our mail server under Centos 5.3 (I think) some 
>> while ago now (about 2 years) and, to the best of my knowledge,it had been 
>> working correctly all that time.
>> 
>> However, one of the team wanted to use webmail while away from base and 
>> found that, although he could receive emails OK, he was unable to reply or 
>> send fresh emails. When he pressed Send he got a message “Authentication 
>> failed" in a pop-up box.
>> 
>> He assured me that sending mail had been working and I was certain that I 
>> had tested that aspect when I was setting Dovecot up, at least for local 
>> mail.
>> 
>> I tried to send email from my Dovecot account and had the same problem.
>> 
>> Our MTA is sendmail and that is not configured to authenticate on outgoing 
>> mail, The configuration for sendmail hasn’t changed at least since the last 
>> update in 16 March 2015 (sendmail 8.13.8-10.el5_11).
>> 
>> Dovecot uses php-5.5.5 in this set up.
>> 
>> The relevant entry in /var/log/maillog when I attempt to send an email from 
>> Dovecot is:
>> 
>> May  5 16:34:29 firewall dovecot: auth: Debug: auth client connected 
>> (pid=13001)
>> May  5 16:34:29 firewall dovecot: auth: Debug: client in: AUTH   1   
>> PLAIN   service=imapsecured lip=127.0.0.1   rip=127.0.0.1   lport=143
>>rport=51861 resp=AGNocmlzADB1dFkwdUcwNDkh
>> May  5 16:34:29 firewall dovecot: auth: Debug: pam(chris,127.0.0.1): lookup 
>> service=dovecot
>> May  5 16:34:29 firewall dovecot: auth: Debug: pam(chris,127.0.0.1): #1/1 
>> style=1 msg=Password:
>> May  5 16:34:29 firewall dovecot: auth: Debug: client out: OK1   
>> user=chris
>> May  5 16:34:29 firewall dovecot: auth: Debug: master in: REQUEST
>> 2607546369  13001   1   0bcf2e3a108cd9cd18eaff4b7de9c428
>> May  5 16:34:29 firewall dovecot: auth: Debug: passwd(chris,127.0.0.1): 
>> lookup
>> May  5 16:34:29 firewall dovecot: auth: Debug: master out: USER  
>> 2607546369  chris   system_groups_user=chrisuid=514 gid=100 
>> home=/home/chris
>> May  5 16:34:29 firewall dovecot: imap-login: Login: user=, 
>> method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=13002, secured
>> May  5 16:34:29 firewall dovecot: imap(chris): Disconnected: Logged out 
>> bytes=11/334
>> May  5 16:34:29 firewall sendmail[13003]: u45FYTtd013003: 
>> localhost.localdomain [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during 
>> connection to MTA
> Looks like a rainloop issue. Apparently it isn't speaking to sendmail 
> correctly.

You are quite correct. I had misconfigured the domain to require 
authentication. All is working now. Many thanks

> 
> 
>> 
>> 
>> The webmail server and our mail server are the same system. The firewall is 
>> open for port 143.
>> 
>> It is only send from Dovecot that fails authentication, all other outgoing 
>> mail is sent correctly.
>> 
>> Does anyone have any idea where else I can look for clues as to why there is 
>> this behaviour?
>> 
>> Suplementary question: what does the “Sign me” check box on the webmail log 
>> in page do?
>> 
>> Many thanks.
>> 
>> Chris

pread() failures when using mdbox on btrfs

[Marc Joliet]

(Note: I am not subscribed to this ML, so please be sure to CC me in replies.)

Hello,

I see a strange bug when running dovecot under btrfs with a mailbox in mdbox 
format.  At some point, which can take a few minutes or more than a day, 
dovecot starts logging pread() failures, like so:

Apr 02 23:43:42 thetick dovecot[570]: imap(marcec): Error: pread() failed with 
file /home/marcec/.mdbox/mailboxes/LinuxAudio/User/dbox-
Mails/dovecot.index.log: Input/output error

These would trigger when getmail runs (which in turn is configured to use 
dovecot-lda).  It's only ever the *.index.log files, and it would usually 
happen to the same one many times in a row.  To demonstrate, this is the full 
list of unique pread() failures on one host (my desktop PC):

# journalctl -u dovecot -p 3 -o cat | sort -u | grep pread
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/BTRFS/dbox-Mails/dovecot.index.log: Input/output 
error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/Gentoo/User/dbox-Mails/dovecot.index.log: 
Input/output error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.log: Input/output 
error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/LinuxAudio/User/dbox-Mails/dovecot.index.log: 
Input/output error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/Newsletters/dbox-Mails/dovecot.index.log: 
Input/output error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/SCons/User/dbox-Mails/dovecot.index.log: 
Input/output error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/storage/dovecot.map.index.log: Input/output error

and on the current host (a home server):

# journalctl -u dovecot -p 3 -o cat | sort -u | grep pread
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/mailboxes/Privat/dbox-Mails/dovecot.index.log: 
Input/output error
imap(marcec): Error: pread() failed with file 
/home/marcec/.mdbox/storage/dovecot.map.index.log: Input/output error

Rebooting the system would make it go away (without loss of mails), though 
remounting the file system should have worked, too.  I tried a variety of 
options, but the only one that helped was to convert the mailbox from mdbox to 
maildir.  I have not seen any pread() failures in the two weeks since.

I originally wrote to the btrfs ML, see the thread at [0], in particular my 
messages [1] and [2], for additional details, including references to what 
little I could find on the web.  However, nothing much came of that thread, so 
I am now posting here.

My dovecot configuration:

# doveconf -n
# 2.2.19: /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.9 (357ac0a0e68b+)  


   
# OS: Linux 4.4.8-gentoo x86_64 Gentoo Base System release 2.2  


   
auth_mechanisms = plain login   


   
mail_location = maildir:~/.maildir  


   
managesieve_notify_capability = mailto  


   
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags 
copy include variables body enotify environment mailbox date index ihave 
duplicate
namespace inbox {   


   
  inbox = yes   


   
  location =   

Re: Cannot connect to Dovecot IMAP or POP

[C. Andrews Lavarre]

Hello all, thank you again for your help.
Thanks to Edgar Pettijohn's inspiration, we changed /etc/dovecot/conf.d
/10-auth.conf to include login (which did not work) and cram-md5 (whichdid 
work):
auth_mechanisms = plain login cram-md5
and we no longer get Connection refused.

Although it doesn't say so explicitly, my reading of 
http://wiki2.dovecot.org/Authentication/Mechanisms
is that SSL/TLS puts a wrapper around plaintext passwords, 
so you don't need an encrypted password. 
However, obviously, you need a scheme to first decrypt the TLS 
envelope! 
So does cram-md5 do that?
Seems to work. Thank you.

So now, as Joseph Tam points out, (thank you for the exposure to nc—cool) we 
are back to "Server certificate not installed".
 
But "the certificate" is installed AFAICT on mail.privustech.com and 
dovecot: 

So which server? The choices are 
• The root server: 70.186.159.22
• The virtual host mail server: mail.privustech.com
• The dovecot server: /etc/dovecot/dovecot.conf
• Something else.

Presumably, as Joseph shows with his nc call, imap calls are to ServerName 
mail.privustech.com.
So we need it to exist and we need cert files for that ServerName:
· We can connect, so the server exists and is responding.
· It is configured as a virtual host and has its own Apache2 
configuration files
mail.privustech.com.conf
mail.privustech.com-ssl.conf
These in turn specify SSL cert, key, and CA files with the CN   
mail.privustech.com 
This host is specified as a port 443 vhost, but changing to 143 had no effect.
I can also connect with https, so the cert is valid.

So I cannot imagine how better to "install" it to a valid host with a valid 
cert... ??? :-(

I examined the other possible "servers" and they all seem correctly established 
as well. Details of today's angst appended below.

Thanks again for the help and inspiration. Tomorrow is another day.

Best regards, Andy

==  
1. The root server is 70.186.159.22
It is configured in /etc/apache2/default-server.conf
This file specifies ServerName as 70.186.159.22 The root server 
under Apache2 does not have an SSL.conf file, however
the root server also is installed as a virtual host in 
/etc/apache2/vhosts.d through
/etc/apache2/vhosts.d/70.186.159.22.conf
/etc/apache2/vhosts.d/70.186.159.22-ssl.conf
The latter file specifies three SSL files:
SSLCertificateFile 
/etc/apache2/ssl.crt/mail.privustech.com_start.crt 
SSLCertificateKeyFile 
/etc/apache2/ssl.key/mailprivustech.key 
SSLCertificateChainFile 
/etc/apache2/ssl.crt/mailprivustech_root_bundle.crt 
Of course, the Common Name (CN) in these files does not match the root 
ServerName. 
If dovecot connects from the root server rather 
than mail.privustech.com that would explain the matter.
We'll check that out tomorrow.

2. We are not, however, trying to connect to the root server, rather to 
mail.privustech.com
This virtual host is manifested  in Apache2 through
/etc/apache2/vhosts.d/mail.privustech.com.conf  
/etc/apache2/vhosts.d/mail.privustech.com-ssl.conf
The ServerName does match the CN in this case. 
The port number in the vhost is 443 vice 143, but we changed 
that with no effect.
So it does not make sense that an imap connection 
responds with
"Server certificate not installed"
How more to "install" the cert than to specify 
it in the vhost -ssl.conf file?

The mail server vhost StartSSL certificate is
/etc/apache2/ssl.crt/mail.privustech.com_start.crt
and has been validated against its key. Its CN is 
mail.privustech.com. 

3. The dovecot server SSL certificate is specified in the configuration file:
/etc/dovecot/dovecot.conf
It does not specify a key, however it includes all files in 
/etc/dovecot/conf.d
This contains a number of files, including
10-auth.conf
10-ssl.conf

The first includes 
auth-mechanisms plain login cram-md5
Adding 

Re: Dovecot/Rainloop 2.0.13-1_129.el5

[Edgar Pettijohn]

On 05/05/16 14:40, Chris Smith wrote:

I configured Dovecot on our mail server under Centos 5.3 (I think) some while 
ago now (about 2 years) and, to the best of my knowledge,it had been working 
correctly all that time.

However, one of the team wanted to use webmail while away from base and found that, 
although he could receive emails OK, he was unable to reply or send fresh emails. 
When he pressed Send he got a message “Authentication failed" in a pop-up box.

He assured me that sending mail had been working and I was certain that I had 
tested that aspect when I was setting Dovecot up, at least for local mail.

I tried to send email from my Dovecot account and had the same problem.

Our MTA is sendmail and that is not configured to authenticate on outgoing 
mail, The configuration for sendmail hasn’t changed at least since the last 
update in 16 March 2015 (sendmail 8.13.8-10.el5_11).

Dovecot uses php-5.5.5 in this set up.

The relevant entry in /var/log/maillog when I attempt to send an email from 
Dovecot is:

May  5 16:34:29 firewall dovecot: auth: Debug: auth client connected (pid=13001)
May  5 16:34:29 firewall dovecot: auth: Debug: client in: AUTH  1   PLAIN   
service=imapsecured lip=127.0.0.1   rip=127.0.0.1   lport=143   
rport=51861 resp=AGNocmlzADB1dFkwdUcwNDkh
May  5 16:34:29 firewall dovecot: auth: Debug: pam(chris,127.0.0.1): lookup 
service=dovecot
May  5 16:34:29 firewall dovecot: auth: Debug: pam(chris,127.0.0.1): #1/1 
style=1 msg=Password:
May  5 16:34:29 firewall dovecot: auth: Debug: client out: OK   1   
user=chris
May  5 16:34:29 firewall dovecot: auth: Debug: master in: REQUEST   
2607546369  13001   1   0bcf2e3a108cd9cd18eaff4b7de9c428
May  5 16:34:29 firewall dovecot: auth: Debug: passwd(chris,127.0.0.1): lookup
May  5 16:34:29 firewall dovecot: auth: Debug: master out: USER 2607546369  
chris   system_groups_user=chrisuid=514 gid=100 home=/home/chris
May  5 16:34:29 firewall dovecot: imap-login: Login: user=, 
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=13002, secured
May  5 16:34:29 firewall dovecot: imap(chris): Disconnected: Logged out 
bytes=11/334
May  5 16:34:29 firewall sendmail[13003]: u45FYTtd013003: localhost.localdomain 
[127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Looks like a rainloop issue. Apparently it isn't speaking to sendmail 
correctly.






The webmail server and our mail server are the same system. The firewall is 
open for port 143.

It is only send from Dovecot that fails authentication, all other outgoing mail 
is sent correctly.

Does anyone have any idea where else I can look for clues as to why there is 
this behaviour?

Suplementary question: what does the “Sign me” check box on the webmail log in 
page do?

Many thanks.

Chris

Dovecot/Rainloop 2.0.13-1_129.el5

[Chris Smith]

I configured Dovecot on our mail server under Centos 5.3 (I think) some while 
ago now (about 2 years) and, to the best of my knowledge,it had been working 
correctly all that time.

However, one of the team wanted to use webmail while away from base and found 
that, although he could receive emails OK, he was unable to reply or send fresh 
emails. When he pressed Send he got a message “Authentication failed" in a 
pop-up box.

He assured me that sending mail had been working and I was certain that I had 
tested that aspect when I was setting Dovecot up, at least for local mail.

I tried to send email from my Dovecot account and had the same problem.

Our MTA is sendmail and that is not configured to authenticate on outgoing 
mail, The configuration for sendmail hasn’t changed at least since the last 
update in 16 March 2015 (sendmail 8.13.8-10.el5_11).

Dovecot uses php-5.5.5 in this set up.

The relevant entry in /var/log/maillog when I attempt to send an email from 
Dovecot is:

May  5 16:34:29 firewall dovecot: auth: Debug: auth client connected (pid=13001)
May  5 16:34:29 firewall dovecot: auth: Debug: client in: AUTH  1   PLAIN   
service=imapsecured lip=127.0.0.1   rip=127.0.0.1   lport=143   
rport=51861 resp=AGNocmlzADB1dFkwdUcwNDkh
May  5 16:34:29 firewall dovecot: auth: Debug: pam(chris,127.0.0.1): lookup 
service=dovecot
May  5 16:34:29 firewall dovecot: auth: Debug: pam(chris,127.0.0.1): #1/1 
style=1 msg=Password: 
May  5 16:34:29 firewall dovecot: auth: Debug: client out: OK   1   
user=chris
May  5 16:34:29 firewall dovecot: auth: Debug: master in: REQUEST   
2607546369  13001   1   0bcf2e3a108cd9cd18eaff4b7de9c428
May  5 16:34:29 firewall dovecot: auth: Debug: passwd(chris,127.0.0.1): lookup
May  5 16:34:29 firewall dovecot: auth: Debug: master out: USER 2607546369  
chris   system_groups_user=chrisuid=514 gid=100 home=/home/chris
May  5 16:34:29 firewall dovecot: imap-login: Login: user=, 
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=13002, secured
May  5 16:34:29 firewall dovecot: imap(chris): Disconnected: Logged out 
bytes=11/334
May  5 16:34:29 firewall sendmail[13003]: u45FYTtd013003: localhost.localdomain 
[127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA


The webmail server and our mail server are the same system. The firewall is 
open for port 143.

It is only send from Dovecot that fails authentication, all other outgoing mail 
is sent correctly.

Does anyone have any idea where else I can look for clues as to why there is 
this behaviour?

Suplementary question: what does the “Sign me” check box on the webmail log in 
page do?

Many thanks.

Chris

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[Gedalya]

On 05/05/2016 01:33 PM, Gedalya wrote:
> you just might be able to set that up to test for the right conditions *when* 
> to do this, and then proceed to remove the header

Maybe using PCRE negative lookaheads

/^Subject: (?!google-calendar-notification)/DUNNO
/^From: (?!google)/DUNNO
/^Auto-Submitted:/IGNORE

maybe something vaguely like this?? didn't test this anywhere outside of my 
message compose window

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[Gedalya]

On 05/05/2016 01:02 PM, deoren wrote:
> On 5/5/2016 10:42 AM, Gedalya wrote:
>> On 05/05/2016 01:00 AM, deoren wrote:
>>> Goal:
>>>
>>> 1) Setup a Google Calendar entry for a biweekly task
>>> 2) Configure the email notification schedule
>>> 3) When the email notification from Google arrives have Sieve send a
>>> notification to an alias I have setup for my cell provider's email to
>>> text messaging gateway
>>> 4) Receive text message
>>>
>>> ...
>>>
>> If you can't do it with dovecot / pigeonhole then consider doing something 
>> in the MTA like removing the Auto-Submitted header before delivery
>
> Thank you for taking the time to read my email and offer suggestions!
>
> I was starting to think the same thing. I've been thinking about using a 
> local alias to pipe to a script to handle generating my own notifications for 
> Google Calendar emails. I also thought about creating some sort of 
> filter/milter to just strip out the header for those emails before letting 
> the Sieve filter handle the rest, but I've not yet had a chance to research 
> just how to go about that.
>
>> or of course you can just send your notification out of there.
>
> Like I mentioned above or is there a better way to go about it?
>
>> Which MTA are you using?
>>
>
> I'm using Postfix 2.11.x + Dovecot 2.2.x to handle our mail.
>
> Thanks again for your help!

So yea if you're on postfix I don't know of better/other terms to think of this 
in.
In exim, you could send out a notification and/or strip/add/modify headers 
without any external script or writing any "code" per se, just within exim's 
config file.
Although writing a milter for postfix isn't all that complicated either.
Postfix has [ http://www.postfix.org/header_checks.5.html ], you can use that 
to remove a header (IGNORE), you just might be able to set that up to test for 
the right conditions *when* to do this, and then proceed to remove the header. 
Gotta run now so I can't put more thought into it at the moment but do post if 
you figure it out :D

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[deoren]

On 5/5/2016 10:42 AM, Gedalya wrote:

On 05/05/2016 01:00 AM, deoren wrote:

Goal:

1) Setup a Google Calendar entry for a biweekly task
2) Configure the email notification schedule
3) When the email notification from Google arrives have Sieve send a
notification to an alias I have setup for my cell provider's email to
text messaging gateway
4) Receive text message

...


If you can't do it with dovecot / pigeonhole then consider doing something in 
the MTA like removing the Auto-Submitted header before delivery


Thank you for taking the time to read my email and offer suggestions!

I was starting to think the same thing. I've been thinking about using a local 
alias to pipe to a script to handle generating my own notifications for Google 
Calendar emails. I also thought about creating some sort of filter/milter to 
just strip out the header for those emails before letting the Sieve filter 
handle the rest, but I've not yet had a chance to research just how to go about 
that.


or of course you can just send your notification out of there.


Like I mentioned above or is there a better way to go about it?


Which MTA are you using?



I'm using Postfix 2.11.x + Dovecot 2.2.x to handle our mail.

Thanks again for your help!

Re: Cannot connect to Dovecot IMAP or POP

[aki . tuomi]

 >   ssl_dh_parameters_length = 2048
> 
> Probably not related to your problem, but this will cause wildly variable
> dovecot initialization times, as temp key generation of this  length
> can result in a lot of candidate primailty testing.
> 

The key generation is done once and stored to disk. Then reused until eternity.

---
Aki Tuomi

Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?

[Gedalya]

On 05/05/2016 01:00 AM, deoren wrote:
> Goal:
>
> 1) Setup a Google Calendar entry for a biweekly task
> 2) Configure the email notification schedule
> 3) When the email notification from Google arrives have Sieve send a
> notification to an alias I have setup for my cell provider's email to
> text messaging gateway
> 4) Receive text message
>
> I know there are other products which likely handle this better, but I'm
> specifically attempting to replicate old behavior by getting text
> message reminders when a specific Google Calendar event occurs.
>
> The problem I'm having is that Sieve is attempting to help by NOT
> sending a notification for emails that it finds are automatically
> generated. I didn't found a lot of information when I searched for
> additional details, but I didn't find an earlier message thread on this
> list that led me to believe that the default behavior is likely chosen
> as some sort of safety net to prevent common issues from occurring.
>
> What I would like to do is override this behavior at some level (per
> rule, per user, system-wide, whatever) to allow for Sieve notifications
> when emails matching a specific pattern are detected regardless of
> whether they are auto-generated or not.
>
> I already found mention in the documentation[1] that the editheader
> extension refuses to remove the Auto-Submitted header, so setting up a
> per user or global rule to do just that wouldn't help. I also haven't
> come upon a way to simply modify the value for the Auto-Submitted
> header, so that doesn't look to work in this situation either.
>
> Does anyone know of a way to accomplish this? Thanks in advance for your
> help!
>
> [1] http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Editheader

If you can't do it with dovecot / pigeonhole then consider doing something in 
the MTA like removing the Auto-Submitted header before delivery, or of course 
you can just send your notification out of there.
Which MTA are you using?