Josef Liška schreef:

But it sends vacation messages with null envelope sender, which is in my opinion undesirable, because many vacation messages are caught in spam filters.

I think there could be same sender on envelope. In dovecot-sieve/src/sieve-cmu.c around line 380 is a call to smtp_client_open(src->addr, NULL, &f); NULL could be replaced with src->fromaddr

[...]

Summary: I expect messages sent by vacation recipe should have envelope from same as user's e-mail address. This is then writen to Return-Path: header by receiving MTA

NULL envelope from is used, resulting (in my case) to Return-Path: <> rewriten by postfix to Return-Path: <MAILER-DAEMON> by receiving MTA Interesting. I've seen a very similar suggestion yesterday. However, as I explained in the previous post, the use of a non-null envelope from field is discouraged by the Sieve vacation RFC (5230) and also by a more generic RFC (3834) describing the do's and dont's regarding auto-responders:

http://www.dovecot.org/list/dovecot/2008-August/032799.html

It puzzles me why spam filters would reject messages with a <> return path, which is a very common an valid use of the SMTP protocol. What spam filter are we talking about anyway?

Regards,

Stephan.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Josef, This is exactly same situation in our environment as well. I had to make the same change as you stated. Our central virus/spam email gateway also cans any message with out a valid from address in the mail headers. I would think most virus/spam systems will do the same. I understand the concept of having the from empty, namely to keep another automated system from replying back to your vacation reply, but what do we do to keep our vacation replies being canned by anti-spam systems?? Maybe this should be a option in the configuration file to let the Admin decide whether to fill in the from address field, or a "donot-reply@domain.com" default, or just empty?

Josef Liška wrote:

I am using this simple sieve script to do "vacation":

require ["fileinto", "vacation"]; if exists "X-Spam-Flag" { stop; } vacation :days 1 :subject "Out of office reply" :addresses ["<email address hidden>", "<email address hidden>" ] "I am on vacation until 2008-08-07. If you have something urgent, please contact: Jan Novak <email address hidden> ";

I use sql lookups for users and passwords. For some reason the default location ~/.dovecot-sieve did not work for some reason. However I prefer to put sieve scripts to /var/lib/sieve and when I added additional field to lookup with this location it started to work.

But it sends vacation messages with null envelope sender, which is in my opinion undesirable, because many vacation messages are caught in spam filters.

I think there could be same sender on envelope. In dovecot-sieve/src/sieve-cmu.c around line 380 is a call to smtp_client_open(src->addr, NULL, &f); NULL could be replaced with src->fromaddr

Maybe some more patching may be necesary. I found similar patch for cyrus-imapd at http://oss.digirati.com.br/mail/cyrus.html <http://oss.digirati.com.br/mail/cyrus.html>

My current system:

1. Ubuntu 8.04.1

jl@mail:~$ dovecot --version 1.0.15

It is a backported package from ubuntu intrepid ibex. However the same applies for dovecot 1.0.10 which is in ubuntu 8.04.

Summary: I expect messages sent by vacation recipe should have envelope from same as user's e-mail address. This is then writen to Return-Path: header by receiving MTA

NULL envelope from is used, resulting (in my case) to Return-Path: <> rewriten by postfix to Return-Path: <MAILER-DAEMON> by receiving MTA

C. J. Keist Email: cj.keist@colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIoZ2UA29OFr7C6jcRAgz8AKCpNJtUd1eGamCIqmIbGB025G1diQCfYBUT OTvTBgnWmGwsvJiX2fz4AyU= =XBNO -----END PGP SIGNATURE-----