[Dovecot] simple steps with sieve
Today is my first day with sieve, so be gentle :) I'm trying to set up a pretty webmail interface to our Dovecot 1.2.4 server using roundcube. The managesieve config + roundcube 'managesieve' plugin work fine, and I'm able to use roundcube's UI to generate .dovecot.sieve files.
We use winbind + LDAP lookups to do some exotic mail rewriting... ultimately user.name@domain.com gets rewritten to 'ar-cloh@localhost', and in /home/AD/ar-cloh/.dovecot.sieve there is only this:
require ["vacation"]; # rule:[gdh_test] if anyof (header :contains "Subject" "test") { vacation "test away"; }
When I send an email to the user, I see this in the mail.log
Oct 19 15:39:43 ar-smtp-1 dovecot: deliver(ar-cloh): sieve: msgid=1255963176.14420.31.camel@gdh-work: discarding vacation response for message implicitly delivered to ar-cloh@ar-smtp-1
I don't understand; sending a vacation for implicitly-delivered messages sounds exactly like what I want - is there any way to say 'do this anyway' ?
gdh
On 10/19/2009 05:03 PM Gavin Hamill wrote:
Today is my first day with sieve, so be gentle :) I'm trying to set up a pretty webmail interface to our Dovecot 1.2.4 server using roundcube. The managesieve config + roundcube 'managesieve' plugin work fine, and I'm able to use roundcube's UI to generate .dovecot.sieve files.
We use winbind + LDAP lookups to do some exotic mail rewriting... ultimately user.name@domain.com gets rewritten to 'ar-cloh@localhost', and in /home/AD/ar-cloh/.dovecot.sieve there is only this:
require ["vacation"]; # rule:[gdh_test] if anyof (header :contains "Subject" "test") { vacation "test away"; }
When I send an email to the user, I see this in the mail.log
Oct 19 15:39:43 ar-smtp-1 dovecot: deliver(ar-cloh): sieve: msgid=1255963176.14420.31.camel@gdh-work: discarding vacation response for message implicitly delivered to ar-cloh@ar-smtp-1
I don't understand; sending a vacation for implicitly-delivered messages sounds exactly like what I want - is there any way to say 'do this anyway' ?
gdh
You are missing the 'addresses:' list in your vacation script. See http://wiki.dovecot.org/LDA/Sieve#Vacation_auto-reply-1 for more details.
Regards, Pascal
The trapper recommends today: fabaceae.0929217@localdomain.org
On Mon, 2009-10-19 at 17:21 +0200, Pascal Volk wrote:
You are missing the 'addresses:' list in your vacation script. See http://wiki.dovecot.org/LDA/Sieve#Vacation_auto-reply-1 for more details.
Interesting; thank you.
I can confirm that it works fine when I specify the exact address - however is it possible to use a wildcard, and further, assume the wildcard implicitly?
I'm just trying to reduce the migration pain on behalf of the users whose current experience with Outlook is Tools -> Out of Office -> Enable.
Cheers, Gavin.
On 10/19/2009 05:32 PM Gavin Hamill wrote:
I can confirm that it works fine when I specify the exact address - however is it possible to use a wildcard, and further, assume the wildcard implicitly?
The :addresses argument accepts only additional mail addresses that a user might have. (http://tools.ietf.org/html/rfc5230#section-4.5) Which of your users has the address *doe@*? ;-) I believe there is no wildcard support. In my opinion wildcard addresses would also make no sense.
I'm just trying to reduce the migration pain on behalf of the users whose current experience with Outlook is Tools -> Out of Office -> Enable.
Hm, I can't find Outlook in the repos. :-D
Regards, Pascal
The trapper recommends today: fabaceae.0929217@localdomain.org
On Mon, 2009-10-19 at 17:59 +0200, Pascal Volk wrote:
The :addresses argument accepts only additional mail addresses that a user might have. (http://tools.ietf.org/html/rfc5230#section-4.5) Which of your users has the address *doe@*? ;-) I believe there is no wildcard support. In my opinion wildcard addresses would also make no sense.
OK now I understand...
Postfix receives mails in firstname.lastname@domain.com format, and does an LDAP lookup to Active Directory to determine the 'flastname' login-name format (for delivery to /home/AD/flastname/Maildir/).
It would then seem that we'd need a method to do a reverse lookup at Dovecot's 'deliver' time and determine the valid To: addresses from LDAP. Does this sound vaguely possible without major engineering work?
I'm just trying to reduce the migration pain on behalf of the users whose current experience with Outlook is Tools -> Out of Office -> Enable.
Hm, I can't find Outlook in the repos. :-D
Ha :) Work with me here; I'm trying to pull people /away/ from the beast so the experience needs to be as drool-proof as possible as people leave their comfort zone :)
gdh
Gavin wrote:
Postfix receives mails in firstname.lastname@domain.com format, and does an LDAP lookup to Active Directory to determine the 'flastname' login-name format (for delivery to /home/AD/flastname/Maildir/).
It would then seem that we'd need a method to do a reverse lookup at Dovecot's 'deliver' time and determine the valid To: addresses from LDAP. Does this sound vaguely possible without major engineering work?
I have exactly the same problem, though with a slightly different setup.
Ubuntu 8.04 LTS Dovecot 1.2.6 Sieve 0.1.12 Postfix 2.5.1 OpenExchange 6.12.0.0-5
I'm currently evaluating software for an upgrade to our hosting platform and postfix/dovecot is the current solution in testing. As this is currently a test system I'm in a position to seriously mess around with things to try and find a solution. The solution is not necessarily in dovecot, but may require changes in postfix config or perhaps use of procmail or some other delivery mechanism in place of deliver. I can't rely on changes in the client as we need to be open enough to permit the user to choose the mail client.
We have multiple domains hosted on the same system. Users are stored in LDAP to allow use of a single account for multiple access methods and software solutions. Usernames are in the format user@domain (effectively the email address) to provide simplicity for the user and differentiation of different users with the same names in different domains.
So we have exactly the same issue - vacation responses appear from user-domain@hostservername.
If there's no way around this it's going to mean looking for another solution, which is a real shame as postfix/dovecot does everything else I need absolutely perfectly (including shared mailbox folders with ACL/IMAP_ACL) quickly and cleanly with a minimum of configuration nightmares, and it's a killer waste of time to have to start evaluation of other solutions for such a minor flaw.
I've found two workarounds so far; it's possible to pass ORIGINAL_RECIPIENT to deliver using postfix but this then causes problems with messages to system aliases; if there's a group alias on the system the response will apparently come from the group alias and not the individual, this is regardless of any "address:" value in the sieve script.
Alternatively it's possible to specify "from:" in the sieve script but this assumes you have a client that's configured to do this. To date, I haven't found one that does.
So this means either living with the system group alias problem, manual editing, or a hack involving a script that checks for changed sieve scripts and updates them with the appropriate "from:" value in the vacation stanza.
I find it really hard to believe that Gavin and I are the only ones to hit this issue. That said I've probably been hacking at this particular system too long and am missing something very obvious....!
Peter.
-----Original Message----- From: dovecot-bounces+dovecot=peter-b.org@dovecot.org [mailto:dovecot-bounces+dovecot=peter-b.org@dovecot.org] On Behalf Of Gavin Hamill Sent: 19 October 2009 19:13 To: Dovecot Mailing List Subject: Re: [Dovecot] simple steps with sieve
On Mon, 2009-10-19 at 17:59 +0200, Pascal Volk wrote:
The :addresses argument accepts only additional mail addresses that a user might have. (http://tools.ietf.org/html/rfc5230#section-4.5) Which of your users has the address *doe@*? ;-) I believe there is no wildcard support. In my opinion wildcard addresses would also make no sense.
OK now I understand...
I'm just trying to reduce the migration pain on behalf of the users whose current experience with Outlook is Tools -> Out of Office -> Enable.
Hm, I can't find Outlook in the repos. :-D
Ha :) Work with me here; I'm trying to pull people /away/ from the beast so the experience needs to be as drool-proof as possible as people leave their comfort zone :)
gdh
Peter Borg wrote:
I find it really hard to believe that Gavin and I are the only ones to hit this issue. That said I've probably been hacking at this particular system too long and am missing something very obvious....!
You're definitely not the only one. Finding a good solution is difficult however. The intention of this check within the vacation action is to prevent spurious vacation responses to for example Bcc:'ed deliveries (and perhaps multi-drop aliases).
Thus far I have seen the following suggestions to solve this problem:
Do some sort of a dict lookup that yields all valid aliases for the user's account or alternatively a lookup that checks whether an address is a valid alias for an account (if many or wildcard aliases exist). A problem with this solution is that potentially many recipients exist and that each would need to be looked up (up to some limit preferably).
Ask the MTA somehow for the same result as in (1) to make sure alias resolution is identical (execute the real alias processing). I am not sure which MTA's even support something like that. Also has the lookup load of (1).
Allow configuring some sort of external binary that is run to get the same result as in (1). Has the lookup load of (1).
Store the list of possible recipient addresses alongside the sieve script, no need to look them up that way.
Let the MTA provide deliver with the original recipient address as the -a parameter. This will cause multi-drop aliases to be reported as sender in messages produced by Deliver or Sieve.
Adjust Deliver/Sieve to accept the original recipient as a separate parameter.
Allow wildcards in the :addresses parameter of the vacation action. This is non-standard and then would only work for Dovecot. It gives the user full control, which is not always desirable (but hard to prevent anyway). It does not solve the problem properly for everyone. I'd rather not deviate from the standard.
Any other ideas? I don't really like any of the solutions above, perhaps nr 6.
Regards,
Stephan.
On Tue, 2009-10-20 at 17:34 +0200, Stephan Bosch wrote:
- Adjust Deliver/Sieve to accept the original recipient as a separate parameter.
I think more like "alias-normalized recipient" or something like that, since "original recipient" would be what -a parameter does and that doesn't really help.
That would solve it from Dovecot's side, but does it actually help, meaning can any MTA give such a parameter? :)
On Tue, 2009-10-20 at 12:28 -0400, Timo Sirainen wrote:
On Tue, 2009-10-20 at 17:34 +0200, Stephan Bosch wrote:
- Adjust Deliver/Sieve to accept the original recipient as a separate parameter.
I think more like "alias-normalized recipient" or something like that, since "original recipient" would be what -a parameter does and that doesn't really help.
That would solve it from Dovecot's side, but does it actually help, meaning can any MTA give such a parameter? :)
If we go down that road, we'll probably need at least two seperate inputs, one for the alias-normalised, and one for the publicly advertised email address.
Hence, when the autoreply is generated, it comes from firstname.lastname@somerealdomain.com rather than ar-flastname@localhost or whatever it's become normalised to.
That said, it's at least one step further down the road to a working solution.
At the moment I'm hacking at roundcube's sieverules plugin to try and draw up the functionality without requiring any changes in the MTA/LDA, but a more generic solution would be very welcome since it'd provide protection from the next inevitable roundcube security hole.
.. alternatively a plaintext dict of "fromaddress alias1 aliasN" would be clumsy but easily scriptable to update from any LDAP/MySQL/sqlite database...
Cheers, Gavin.
On Tue, 2009-10-20 at 18:48 +0100, Gavin Hamill wrote:
If we go down that road, we'll probably need at least two seperate inputs, one for the alias-normalised, and one for the publicly advertised email address.
Hence, when the autoreply is generated, it comes from firstname.lastname@somerealdomain.com rather than ar-flastname@localhost or whatever it's become normalised to.
That's something I had just today decided to do anyway.
On Tue, 2009-10-20 at 17:34 +0200, Stephan Bosch wrote:
Peter Borg wrote:
I find it really hard to believe that Gavin and I are the only ones to hit this issue. That said I've probably been hacking at this particular system too long and am missing something very obvious....!
You're definitely not the only one. Finding a good solution is difficult however. The intention of this check within the vacation action is to prevent spurious vacation responses to for example Bcc:'ed deliveries (and perhaps multi-drop aliases).
For my own situation, I solved this issue entirely from the 'roundcube' webmail package. Help on the roundcubeforums site suggested changes to the 'sieverules' plugin so :addresses would always be included in a vacation rule. I extended this to the :from parameter.
Also used roundcube's new_user_identity plugin to populate the primary identity of a 'ar-wbim' username with 'wim.bim@ourdomain.com' so that the :from and :addresses are using the canonical format
Fairly ugly, but it works for us. I'll document the changes if I get a moment.
Cheers, Gavin.
I've been looking at various client fixes to add :from, but ultimately the better solution would be in sieve/managesieve as although I have a single webmail solution I'm also offering imap access.
A really simple solution (for me) would be for sieve to copy the :address to :from. I may even implement this as a hack and recompile...
Still doesn't fix responses to expanded system aliases. That's a whole different problem though, I suspect.
Peter.
-----Original Message----- From: dovecot-bounces+dovecot=peter-b.org@dovecot.org [mailto:dovecot-bounces+dovecot=peter-b.org@dovecot.org] On Behalf Of Gavin Hamill Sent: 22 October 2009 11:03 To: Stephan Bosch Cc: 'Dovecot Mailing List' Subject: Re: [Dovecot] simple steps with sieve
On Tue, 2009-10-20 at 17:34 +0200, Stephan Bosch wrote:
Peter Borg wrote:
I find it really hard to believe that Gavin and I are the only ones to hit this issue. That said I've probably been hacking at this particular system too long and am missing something very obvious....!
You're definitely not the only one. Finding a good solution is difficult however. The intention of this check within the vacation action is to prevent spurious vacation responses to for example Bcc:'ed deliveries (and perhaps multi-drop aliases).
For my own situation, I solved this issue entirely from the 'roundcube' webmail package. Help on the roundcubeforums site suggested changes to the 'sieverules' plugin so :addresses would always be included in a vacation rule. I extended this to the :from parameter.
Also used roundcube's new_user_identity plugin to populate the primary identity of a 'ar-wbim' username with 'wim.bim@ourdomain.com' so that the :from and :addresses are using the canonical format
Fairly ugly, but it works for us. I'll document the changes if I get a moment.
Cheers, Gavin.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 20 Oct 2009, Stephan Bosch wrote:
Finding a good solution is difficult
Yes! and there is no general solution for every setup, I guess.
however. The intention of this check within the vacation action is to prevent spurious vacation responses to for example Bcc:'ed deliveries (and perhaps multi-drop aliases).
But _why_ is BCC spurious? There are spurious BCC, but not in general. If I BCC a message to somebody, I want to know an out-of-office state. Just like for any CC or TO recipient.
Thus far I have seen the following suggestions to solve this problem:
- Do some sort of a dict lookup that yields all valid aliases for the user's account or alternatively a lookup that checks whether an address is a valid alias for an account (if many or wildcard aliases exist). A problem with this solution is that potentially many recipients exist and that each would need to be looked up (up to some limit preferably).
When I consider some automagic to get all aliases per account, I wonder how do I stop Sieve from using this automagic? So I surround the vacation with an if conditional, e.g. to respond only to 5 out of my 386 possible addresses.
Dunno how a dict can be working internally, but can Dovecot dicts perform wildcard checks?
- Ask the MTA somehow for the same result as in (1) to make sure alias resolution is identical (execute the real alias processing). I am not sure which MTA's even support something like that. Also has the lookup load of (1).
because of the "not sure" this variant won't work.
- Allow configuring some sort of external binary that is run to get the same result as in (1). Has the lookup load of (1).
This loads off the problem to the admin. Not too bad, IMHO. And would include variant 2)
- Store the list of possible recipient addresses alongside the sieve script, no need to look them up that way.
Problem with (quote from variant 1) ): "if many or wildcard aliases exist"
- Let the MTA provide deliver with the original recipient address as the -a parameter. This will cause multi-drop aliases to be reported as sender in messages produced by Deliver or Sieve.
Same problem as 2). sendmail does not pass along envelop recipients, if more than one recipient is specified, for example.
Also, what is the "original recipient address", the envelope address? If so, you call BCC's non-spurious now. It also won't help with: "if many or wildcard aliases exist"
- Adjust Deliver/Sieve to accept the original recipient as a separate parameter.
Looks like the same as 5), or am I mistaken.
- Allow wildcards in the :addresses parameter of the vacation action. This is non-standard and then would only work for Dovecot. It gives the user full control, which is not always desirable (but hard to prevent anyway). It does not solve the problem properly for everyone. I'd rather not deviate from the standard.
Hmm, so an combination of:
a) standard-conform: verify "to"/"cc" recipients against the current user's _implicit_ alias lists, e.g. dict, external binary, or plain file; here you can even do regex matching
and
b) non-standard-conform: add a ":accept-all-addresses" modifier to vacation and let the user select on To/Cc adresses via if condition.
BTW: Splitting hair: IMHO sec 4.5/4.6 of RFC 5230 does not specify the notation of an "address". So "@example.net" could be as valid as "localpart@" or anything else.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSuggbHWSIuGy1ktrAQJ4cggAhAXOHHv1fiDxON7hbnr2j6PDMo9t0odK dxTtGLOI6UXMsFEOv6Tx/3cnMfxJF7viaC7NCH5YYmKkCjDRm0DkMBqNnIkpMFfF XyzZCUa9FYTEYLjDtFPQtJrkVeh3YUueTxhw0ZvkWSh5he/Y5R0vA5i1PLJyP2uk F4hF1+894bzXWwaLR1chv3BEQQkzKY5W82L5TY2R8bSIej+SQFDouJflbHi/oM9F Hrjg2ezbRVqSj4nnmNwReHQnajAUW/QnE0VRl/cncW7svxmMMJhiXe22kZw+/VWy nthaci7sUW17toy8VY5cPIU66oEqo8ILGUG+IbVveKMau/NdRMic0A== =knhz -----END PGP SIGNATURE-----
On Wed, 2009-10-28 at 11:43 +0100, Steffen Kaiser wrote:
however. The intention of this check within the vacation action is to prevent spurious vacation responses to for example Bcc:'ed deliveries (and perhaps multi-drop aliases).
But _why_ is BCC spurious? There are spurious BCC, but not in general. If I BCC a message to somebody, I want to know an out-of-office state. Just like for any CC or TO recipient.
At least one problem is email lists created using aliases. Like everyone@company.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 28 Oct 2009, Timo Sirainen wrote:
But _why_ is BCC spurious? There are spurious BCC, but not in general. If I BCC a message to somebody, I want to know an out-of-office state. Just like for any CC or TO recipient.
At least one problem is email lists created using aliases. Like everyone@company.com.
Even in this case, why not? I'm probably also not interested in the DSNs like "over quota" or something like that generated by the MTA. Actually, it would be nice if MTAs would pass through ESMTP RCPT's NOTIFY parameter (RFC 3461 sec 4.1), so the user could control the reply.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSuiRw3WSIuGy1ktrAQIFxAgAqVSPhBB2wrAl42B+yi9e9Jz9vL9KbtPD +2dbvpyp+3iNeM+0DZoZ3rgUgIBZ/HMRrL6jb/SNmia7W0qyHDmMViw9+BMM2UTC WenPdz/k4VU80RtE/7glVPUl+v6+wiwpom115wUSaBxuV3YZeIfUL6KrHCb8a6vh zc5Ebby4noqnpIQamyLLHVPded9ib748sgFDnbRoD2CEqsyXiNwf4EzaGgrQ9zQ3 jQbJ9HSIx93U5n4YZoKL/blyD1/K2V8xQ5roW+/QOkxzBM1w8HIhvwEVBjiZqJZQ QLjyX+oQCHpIehyJPB3jwNgVh+i837RYI68G7x8REwGeMg65aNGJ6A== =2KrB -----END PGP SIGNATURE-----
On Wed, Oct 28, 2009 at 2:47 PM, Steffen Kaiser < skdovecot@smail.inf.fh-brs.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 28 Oct 2009, Timo Sirainen wrote:
But _why_ is BCC spurious? There are spurious BCC, but not in general.
If I BCC a message to somebody, I want to know an out-of-office state. Just like for any CC or TO recipient.
At least one problem is email lists created using aliases. Like everyone@company.com.
Even in this case, why not? I'm probably also not interested in the DSNs like "over quota" or something like that generated by the MTA. Actually, it would be nice if MTAs would pass through ESMTP RCPT's NOTIFY parameter (RFC 3461 sec 4.1), so the user could control the reply.
Bye,
- -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSuiRw3WSIuGy1ktrAQIFxAgAqVSPhBB2wrAl42B+yi9e9Jz9vL9KbtPD +2dbvpyp+3iNeM+0DZoZ3rgUgIBZ/HMRrL6jb/SNmia7W0qyHDmMViw9+BMM2UTC WenPdz/k4VU80RtE/7glVPUl+v6+wiwpom115wUSaBxuV3YZeIfUL6KrHCb8a6vh zc5Ebby4noqnpIQamyLLHVPded9ib748sgFDnbRoD2CEqsyXiNwf4EzaGgrQ9zQ3 jQbJ9HSIx93U5n4YZoKL/blyD1/K2V8xQ5roW+/QOkxzBM1w8HIhvwEVBjiZqJZQ QLjyX+oQCHpIehyJPB3jwNgVh+i837RYI68G7x8REwGeMg65aNGJ6A== =2KrB -----END PGP SIGNATURE-----
I realize this thread is a bit out of date, but I recently sent a patch to the list to achieve similar behavior with a vacation tag ":x_any_address". The "x" is because its a crazy extension, and because the letter X is cool.
There are a lot of cases where turning this behavior (responding regardless of the recipient) is bad behavior. E.g. everyone@company.com. But then it is up to the organization to have a policy of not using :x_any_address, just like it is up to them to not use :addresses ["everyone@company.com"]. I can pick a good default for my users, and unfortunately right now what they expect is :x_any_address.
The thing I like about my patch is that, for my users, it can ultimately be configurable to the most likely 3 cases:
- only send VAR for the proper account
- send VAR for a user specified list of accounts
- always send VAR regardless of recipient (but still following other recommendations in rfc 3834)
The thing I don't like about my patch is: Maintaining it! There might be a better name for this tag. The confusion of having both :x_any_address and :addresses <string list> turned on at the same time
Cheers
On Tue, 2009-10-20 at 12:28 +0100, Peter Borg wrote:
So we have exactly the same issue - vacation responses appear from user-domain@hostservername.
Do you think it would be enough to just add a new -r <sender> parameter to deliver and all user's From: fields would use it? (I guess probably only vacation for now.)
Gavin Hamill wrote:
On Mon, 2009-10-19 at 17:21 +0200, Pascal Volk wrote:
You are missing the 'addresses:' list in your vacation script. See http://wiki.dovecot.org/LDA/Sieve#Vacation_auto-reply-1 for more details.
Interesting; thank you.
I can confirm that it works fine when I specify the exact address - however is it possible to use a wildcard, and further, assume the wildcard implicitly?
It's not supposed to blindly autorespond to everything that crosses its path, i.e. mailing lists not directly addressed to you. Thus you have to specify the list of addresses.
~Seth
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 19 Oct 2009, Seth Mattinen wrote:
It's not supposed to blindly autorespond to everything that crosses its path, i.e. mailing lists not directly addressed to you. Thus you have to
Mailing lists have "precedence: bulk"
specify the list of addresses.
Also, if I send someone a BCC, why won't I get the out-of-office reply?
This :address modifier is very very clumsy, esp. because you can easily have the same effect using an "if" condition.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSugWmnWSIuGy1ktrAQJvzwgAoAGQ8kGfcCbpt1zNZu+qDrf75auB4AfK hIQbAUwqK+ltsXmtD5XQBfdEVZolrKcw0x+sl3HjB73yVdZtYKZvsWRl1rMmUO7Y Bu7fjotcbpzwYgANAMkcM0DAXOJU8dq/QBvLU63Da/yBypbuc3Vu+2UfXk2/ADQ8 EZP98ow4hu39EDQ+h2vTD9qfp6W0xWNUlmWaTBUe7COBj5bR3emlIxTi2lrbLbM4 CCU91p7JuePbnvDwx/i4jMOEKMcbsi4Rckn12lhz4mLzX808rLMBnUCdpTF44yci ulcd9ZGrwx2hKA47c4ybsJsFcRCX1p9ZuOtt58h0xwILElMicjBbWw== =xSLt -----END PGP SIGNATURE-----
participants (8)
-
Gavin Hamill
-
Mark Washenberger
-
Pascal Volk
-
Peter Borg
-
Seth Mattinen
-
Steffen Kaiser
-
Stephan Bosch
-
Timo Sirainen