[Dovecot] Vacation message and DMARC validation
Greetings,
I have found an issue in the interaction between sieve vacation messages and the SPF, DKIM and DMARC email validation systems.
For example, let's say we have a message coming from a@a.com to b@b.com at a server imap.mydomain.com. The account b@b.com has a vacation rule in sieve, and that generates an autoresponse to a@a.com. Our problem begins with the definition of section-5.1 in RFC5230 https://tools.ietf.org/html/rfc5230#section-5.1. It says that the envelope-from in vacation messages should be set to <>. This is the behavior currently implemented in Dovecot.
We have recently added DMARC's authentication to our e-mail servers. DMARC needs one of the two authentication to pass, either SPF or DKIM. SPF works, but not the way DMARC needs it to. DMARC needs a valid SPF record that also matches the "From:" header. In this message, there are no envelope-from, so there are no domain to validate. This is the reason we use SRS to rewrite envelope-from (to do that we use the server address).
The last option is to use DKIM authentication.
We have clustered SMTP servers. So, in order to make a DKIM signature, the vacation message needs to be sent to the right server. That is, the server where the key to account b@b.com is available.
To do that, we are implementing a modification to Dovecot source allowing the use of the envelope-from. The modified envelope-from will be used with the Postfix option "sender_dependent_relayhost_maps" in order to choose the right cluster. This does not break RFC5230, because the use of null sender is only a recommendation.
I would like to know if a patch to the main project would be appreciated. Could you also please confirm if there are any future plans involving this feature, like an optional configuration for custom envelope-from?
Thanks in advance,
Gerson Moraes Digirati
Op 5-9-2013 21:55, Gerson Moraes schreef:
I would like to know if a patch to the main project would be appreciated. Could you also please confirm if there are any future plans involving this feature, like an optional configuration for custom envelope-from?
Since it is not direct a violation of the specification, I can accept such a feature. What exactly do you need? Is it enough if it uses the recipient address or do you want to be able to set it freely to a server-wide static address?
Regards,
Stephan.
Op 5-9-2013 21:55, Gerson Moraes schreef:
I would like to know if a patch to the main project would be appreciated. Could you also please confirm if there are any future plans involving this feature, like an optional configuration for custom envelope-from?
Since it is not direct a violation of the specification, I can accept such a feature. What exactly do you need? Is it enough if it uses the recipient address or do you want to be able to set it freely to a server-wide static address?
It is enough to use the recipient address. It will make DKIM validation work.
Regards, Gerson
On 9/10/2013 9:20 PM, Gerson Moraes wrote:
Op 5-9-2013 21:55, Gerson Moraes schreef:
I would like to know if a patch to the main project would be appreciated. Could you also please confirm if there are any future plans involving this feature, like an optional configuration for custom envelope-from?
Since it is not direct a violation of the specification, I can accept such a feature. What exactly do you need? Is it enough if it uses the recipient address or do you want to be able to set it freely to a server-wide static address?
It is enough to use the recipient address. It will make DKIM validation work.
Implemented:
http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/4924724b7f4f
Regards,
Stephan.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gerson Moraes wrote:
I would like to know if a patch to the main project would be appreciated. Could you also please confirm if there are any future plans involving this feature, like an optional configuration for custom envelope-from?
how do you prevent loops, e.g. both sides have an autoresponder activated? Does the custom env-from is dropped by the MTA, if it arrives from the outside? IMHO, one should not assume that another side does honor Preference: bulk/auto.
Steffen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEVAwUBUi+CK13r2wJMiz2NAQLTDQgAwtMy0en9r30rdliywECXCE7Fr0Rt6bFM 9BQcxnVZ5T3YJRxGoNJ1Za/hxwzQzULtO/a3VhBJ4g4fwyfuf2zuF9W2ZM7bQxR5 ECTLwrXxH/TwBO9MwurwVzk6AY7cpKs8LrfnVEt1qB1m7bRnJU/OPA6rVCsXzOsv cIqJRvJ5jw+1StCgsiyutMWAhdd8BWS76BnoswmLchCxiimLIJM8hMVa1meT0+Dx r2YcDVq/Z+B2r1f8MZ3vStnSjWsQabfHdg6gUETZhHCdgJ+A7BUDjb19K9VRGNQ+ Jqt25bNFRekwIFZYnqch7wZqjZddWjd5vM1fNZtZ9gUnsRTmxKuwLw== =H5eP -----END PGP SIGNATURE-----
Hi Stephan,
how do you prevent loops, e.g. both sides have an autoresponder activated? We use the parameter "days" available for setting the frequency of vacation messages. For example, if "days" is set to 1, only one auto-response will be generated for the same e-mail per day. So, it prevents loops correctly. Does the custom env-from is dropped by the MTA, if it arrives from the outside? IMHO, one should not assume that another side does honor Preference: bulk/auto. I did not understand what you meant. Can you give an example?
Regards, Gerson
participants (3)
-
Gerson Moraes
-
Steffen
-
Stephan Bosch