Re: doveadm who reverse dns lookups
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 24 Jul 2018, Michael Grant wrote:
Perhaps this is a feature request...
It would be nice if the ‘doveadm who’ command printed out the reverse dns name
of where the user was logged in from.
Would it be possible to either add some option to doveadm who for this, or make
it the do it by default and add a ‘-n’ option (like many of the other programs
that look up ip addresses by default) and take a -n option to not do that?
Not sure if that would break some existing thing which is why I hesitate.
Might be safer to add, say, a -r option to do the rDNS lookup.
Hmm, use the Unix construction kit:
doveadm who| perl -np -MSocket -e 'sub addr { my $i = shift; my $iaddr =
inet_aton($i); return gethostbyaddr($iaddr, AF_INET) || $i; }
s/((?:\d+\.){3}\d+)/addr($1)/eg'
- --
Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEVAwUBW1gMSsQnQQNheMxiAQJaLgf/UYjZaKZU4yUN9YdGhFdq+4+6GKk/UFpG
tT99rNSwYVnk1rBwaW07fkDMV0HcuFmB6gDpDx6D2hVW/yNJWvi1PQTb+GZvbB9P
QRXamrB0WRVBcq5v4FM7QuNiMW921pJ6MWt03vDzhPHSMd/y99B3ZCz2gbMQuUVG
rj3X+YxhMoQUGTgvPEsZ2TGbRE5VNWojUEbCnlSUGOuRtwKMrmaahzKGHsrf8Dub
fzNrEJ8mxrySgC79+2FdLInv+YiguE3Xv6rN2c1tygC7sDeETfloe0GL3kWnUw4L
bhhf+mcpzyqoutfcGCM9ggHieXBQk9xKsMBhftT3dAZ/f3Rok/eZHA==
=2JK3
-END PGP SIGNATURE-
doveadm who reverse dns lookups
Perhaps this is a feature request... It would be nice if the ‘doveadm who’ command printed out the reverse dns name of where the user was logged in from. Would it be possible to either add some option to doveadm who for this, or make it the do it by default and add a ‘-n’ option (like many of the other programs that look up ip addresses by default) and take a -n option to not do that? Not sure if that would break some existing thing which is why I hesitate. Might be safer to add, say, a -r option to do the rDNS lookup. However, it would definitely save me a step in figuring out where someone was logged in from to know if it’s legit. Michael Grant
Re: doveadm expunge didn't clear Trash mailbox
On Mon, 23 Jul 2018, Michael Wagner wrote: here works a dovecot 2.2.27 on a raspberrypi and the behaviour is as expected. doveadm -f tab fetch -u "uid date.saved" mailbox Trash uid date.saved 314 2018-06-23 00:35:59 315 2018-06-23 12:39:10 316 2018-06-24 10:32:43 ... And I have a cron script that expunges the mails older than 30 days. /usr/bin/doveadm expunge -u mailbox Trash savedbefore 30d Hi Michael, Thanks for your observation. I think you probably use maildir format, yes? I think my problem stems from the fact I use mbox, so one file contains many messages, whereas maildir uses one file for each message. Dovecot, from my understanding, will use the message file's mtime for date.saved if it doesn't have it in the cached. This is probably why I am seeing multiple messages with the same value. What's confusing is that if I query a message's date.saved, that value -- whether from the cache or the mailbox's mtime -- remains in the cache, so the next query will give me that value. So running "doveadm fetch ... date.saved", will get the mailbox's mtime at the time I fetched those values. In order to get near accurate date.saved values, I would have to run "doveadm fetch ... date.saved" frequently. (I think this behaviour must have changed recently because this no longer works consistently.) However, if each message is stored in a separate file (like maildir does), then each message can have an accurate date.saved(=mtime). Once you have accurate date.saved, then the "expunge savedbefore" works correctly. Another reason I really ought to switch to maildir. Joseph Tam
Basic question about file permissions for sieve error log
Hello, I have an admittedly very basic question, but I am not able to get it to work. I store my global sieve script in: /etc/dovecot. I recently made a mistake in my global sieve script which causes Dovecot to attempt to log the errors in: /etc/dovecot/sieve-global.log In /var/log/dovecot.log I see: Jul 24 15:33:32 lmtp(t...@example.com): Error: ABVWGAx/V1uKLAAA1B5X9w: sieve: failed to open logfile (LOGGING TO STDERR): open(/etc/dovecot/sieve-global.log) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /etc/dovecot, we're not in group 122(dovecot), dir owned by 0:122 mode=0775) …but the group membership shows: $ sudo -u vmail groups vmail dovecot …and I restarted Dovecot, but the same error happens. What am I doing wrong ? Thanks, - J
Re: Dsync fails to connect to remote IMAP server
Adding ssl_client_ca_dir solved my problem. Now I can connect to the IMAP server. Thanks. pon., 23 lip 2018 o 13:53 Aki Tuomi napisał(a): > Hi! > > You need to add a ssl_client_ca_* setting even if you don't want the imapc > to verify the remote cert. I'll have to look into why this has been made a > requirement in the code, since it has to do what with how we do OpenSSL > initialization. > Aki > > On 21.07.2018 12:59, Andrzej Polatyński wrote: > > Hi, > > I'm trying to migrate from an old courier IMAP server to Dovecot 2.3.1 > (8e2f634). The old server uses self signed SSL certificate. > > I'm using the following configuration: > > imapc_host = 10.1.1.3 > imapc_user = %u > imapc_features = rfc822.size fetch-headers > imapc_port = 993 > imapc_ssl = imaps > imapc_ssl_verify = no > mail_prefetch_count = 20 > mail_shared_explicit_inbox = no > Launching dsync with the command: > > doveadm -o mail_fsync=never -o imapc_password=PASSWORD -Dv backup -R -u > USER@DOMAIN imapc: > > In the output logs I get messages like below: > > dsync(USER@DOMAIN): Error: imapc(10.1.1.3:993): Couldn't initialize SSL > context: Can't verify remote server certs without trusted CAs > (ssl_client_ca_* settings) > dsync(USER@DOMAIN): Debug: imapc(10.1.1.3:993): Created new connection > dsync(USER@DOMAIN): Debug: imapc(10.1.1.3:993): Looking up IP address > (reconnect_ok=true, last_connect=1532016643) > dsync(USER@DOMAIN): Debug: imapc(10.1.1.3:993): Connecting to 10.1.1.3:993 > dsync(USER@DOMAIN): Info: imapc(10.1.1.3:993): Connected to 10.1.1.3:993 > (local 172.17.0.5:51972) > dsync(USER@DOMAIN): Error: imapc(10.1.1.3:993): No SSL context > dsync(USER@DOMAIN): Debug: imapc(10.1.1.3:993): Disconnected > Am I missing some configuration parameters? > > > -- > Regards, > Andrew > > > -- Pozdrawiam, Andrzej
Re: dovecot sometimes sends non-default SSL cert if IMAP client won't send SNI
Well. At least I know now the cn overlaps. That should not be a problem but is at least something to pursue. ---Aki TuomiDovecot oy Original message From: Martin Johannes Dauser Date: 24/07/2018 18:03 (GMT+02:00) To: dovecot@dovecot.org Subject: Re: dovecot sometimes sends non-default SSL cert if IMAP client won't send SNI Sure, and thanks for trying to help! These are the two correct answers when SNI is included. The certificates are fully chained. Both certificates carry the same subject mail.cs.sbg.ac.at but differ in Subject Alternative Name (SAN). X509v3 Subject Alternative Name: DNS:mail.cs.sbg.ac.at, DNS:smtp.cs.sbg.ac.at, DNS:imap.cs.sbg.ac.at, DNS:pop.cs.sbg.ac.at X509v3 Subject Alternative Name: DNS:mail.cs.sbg.ac.at, DNS:mail.cosy.sbg.ac.at, DNS:smtp.cosy.sbg.ac.at, DNS:imap.cosy.sbg.ac.at, DNS:pop.cosy.sbg.ac.at I thought of attaching a file with 13 outputs of command $ openssl s_client -showcerts -connect 141.201.4.5:993 but this would certainly exceed the limit of 40kb. Anyway, except for the SSL handshake the outputs exactly meet the two examples a few lines below. Statistics: Only connections 10,11,13 showed the default certificate. So running only a few connections might end up with 100% false certs -- or the other way round. OpenSSL itself is always happy, as both certificates fit to the (r)DNS records of mail.cs.sbg.ac.at/141.201.4.5. Would it help you to run dovecot in debug mode? ### $ openssl s_client -showcerts -connect 141.201.4.5:993 -servername imap.cs.sbg.ac.at CONNECTED(0003) --- Certificate chain 0 s:/C=AT/ST=Salzburg/L=Salzburg/O=University of Salzburg/OU=Department of Computer Science/CN=mail.cs.sbg.ac.at i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3 -BEGIN CERTIFICATE- MIIGjDCCBXSgAwIBAgIQApnSP3xZbyr6dGTMvuxaSDANBgkqhkiG9w0BAQ0FADBk MQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJ QW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExGDAWBgNVBAMTD1RFUkVOQSBTU0wg Q0EgMzAeFw0xNzAxMjQwMDAwMDBaFw0yMDAxMjgxMjAwMDBaMIGZMQswCQYDVQQG EwJBVDERMA8GA1UECBMIU2FsemJ1cmcxETAPBgNVBAcTCFNhbHpidXJnMR8wHQYD VQQKExZVbml2ZXJzaXR5IG9mIFNhbHpidXJnMScwJQYDVQQLEx5EZXBhcnRtZW50 IG9mIENvbXB1dGVyIFNjaWVuY2UxGjAYBgNVBAMTEW1haWwuY3Muc2JnLmFjLmF0 MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAus33Jb+HE64oJvBEwpeh 7cwyMAknhE5k/49eUG7/E0j2ffEo1APzxYooZ1hlHcf7meH7h1KYD3lSXw5RX0Mi KtuUHSUIqYE1U3+pyussB11r18ucHk8MoFQqPnJDeuSPaHozmdQtJJHRVDabddHz 5l4RVEUduUjzl7vnfFrBhbHV/LpYcLMsNgdlg5I0TXU99Y8paMeF32cWiR2dCeyN t2AajjMpHYRDaJ9DGed8nWOeqK0YRQuaEGF68VBVdygDcOQ0eBflwYEjJChJHhN4 UsQSmwoXYj5ZRvyhcAxxPDYveNhM4oVox67Nvw1AgHz/spaWgJVMKrTU4hFDYcnO 0F6KkumLke0t4IvoLEU7ScAm6d3ttQ5ZBbSIX811kWHC/ddu12AhRiq3y5fN2o3n 6pbRrqljyg4Mu0Tj9UEuwC8bJnCJreo32HQwo82vD1xU8jPUci4UoD21PfkjFssm qbtwwWs1KAIvX52U79u6CC7hvsPNtCiMK0K6/9jg8OyKMraBWvIUV6YxgnuJZ4Mi so/OD6uqdpqCYuq5LLZVAVcBu/vGTzfcckkz71nN2eZSO870rnxyHeTWmepQv4nc gxN49JeReO4zZMio6eC5N9D+SYc5Ae5mS8qyHe/gur6VmbmbWk/vRt/m75lcGLgR A4FRqRvu+GIWNh0uCP9SlkUCAwEAAaOCAgIwggH+MB8GA1UdIwQYMBaAFGf9iCAU J5jHCdIlGbvpURFjdVBiMB0GA1UdDgQWBBR6nRddyu+D1h42fba+bgkBi6OipzBU BgNVHREETTBLghFtYWlsLmNzLnNiZy5hYy5hdIIRc210cC5jcy5zYmcuYWMuYXSC EWltYXAuY3Muc2JnLmFjLmF0ghBwb3AuY3Muc2JnLmFjLmF0MA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwawYDVR0fBGQwYjAv oC2gK4YpaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL1RFUkVOQVNTTENBMy5jcmww L6AtoCuGKWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFTU0xDQTMuY3Js MEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMG4GCCsGAQUFBwEBBGIwYDAk BggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMDgGCCsGAQUFBzAC hixodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVEVSRU5BU1NMQ0EzLmNydDAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBDQUAA4IBAQA6Xbkobv3hQAr532wf0NsZ kYErQebiMLCrKDAhtLc7Z/bO/srUgOs0x9uoIU5ErjLnPcWrPK0eFQevjZ+6CUry NgAcf6f1z9g1IejuapXb6F41YAteJzo+QkvAtQFkOaq9AADXNo6iIOIDyE1M8hWW W0gcwx6h4+UUSLac0LN/i+Q2LcHa6fg/kH59Yt2oIzkJrVRSHn11R8iUHiLgW3X2 XL9BgCZHqI8t3OaJpXLHmvA0pKDIvjFK9+CDcXZWQbZyLlMzGxVyrZfK+rBjL05h QQ3CTy9JJ3/1//AD1mSgog3qSejMQ7ZK01ZZv4lDoEU8ADGFA6VKlV/CiaYz5Ztk -END CERTIFICATE- 1 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA -BEGIN CERTIFICATE- MIIE+zCCA+OgAwIBAgIQCHC8xa8/25Wakctq7u/kZTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv b3QgQ0EwHhcNMTQxMTE4MTIwMDAwWhcNMjQxMTE4MTIwMDAwWjBkMQswCQYDVQQG EwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFt MQ8wDQYDVQQKEwZURVJFTkExGDAWBgNVBAMTD1RFUkVOQSBTU0wgQ0EgMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMV2Dw/ZQyk7bG3RR63eEL8jwnio Snc18SNb4EweQefCMQC9iDdFdd25AhCAHo/tZCMERaegOTuBTc9jP8JJ/yKeiLDS lrlcinQfkioq8hLIt2hUtVhBgUBoBhpPhSn7tU08D08/QJYbzqjMXjX/ZJj1dd10
Re: dovecot sometimes sends non-default SSL cert if IMAP client won't send SNI
Sure, and thanks for trying to help! These are the two correct answers when SNI is included. The certificates are fully chained. Both certificates carry the same subject mail.cs.sbg.ac.at but differ in Subject Alternative Name (SAN). X509v3 Subject Alternative Name: DNS:mail.cs.sbg.ac.at, DNS:smtp.cs.sbg.ac.at, DNS:imap.cs.sbg.ac.at, DNS:pop.cs.sbg.ac.at X509v3 Subject Alternative Name: DNS:mail.cs.sbg.ac.at, DNS:mail.cosy.sbg.ac.at, DNS:smtp.cosy.sbg.ac.at, DNS:imap.cosy.sbg.ac.at, DNS:pop.cosy.sbg.ac.at I thought of attaching a file with 13 outputs of command $ openssl s_client -showcerts -connect 141.201.4.5:993 but this would certainly exceed the limit of 40kb. Anyway, except for the SSL handshake the outputs exactly meet the two examples a few lines below. Statistics: Only connections 10,11,13 showed the default certificate. So running only a few connections might end up with 100% false certs -- or the other way round. OpenSSL itself is always happy, as both certificates fit to the (r)DNS records of mail.cs.sbg.ac.at/141.201.4.5. Would it help you to run dovecot in debug mode? ### $ openssl s_client -showcerts -connect 141.201.4.5:993 -servername imap.cs.sbg.ac.at CONNECTED(0003) --- Certificate chain 0 s:/C=AT/ST=Salzburg/L=Salzburg/O=University of Salzburg/OU=Department of Computer Science/CN=mail.cs.sbg.ac.at i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3 -BEGIN CERTIFICATE- MIIGjDCCBXSgAwIBAgIQApnSP3xZbyr6dGTMvuxaSDANBgkqhkiG9w0BAQ0FADBk MQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJ QW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExGDAWBgNVBAMTD1RFUkVOQSBTU0wg Q0EgMzAeFw0xNzAxMjQwMDAwMDBaFw0yMDAxMjgxMjAwMDBaMIGZMQswCQYDVQQG EwJBVDERMA8GA1UECBMIU2FsemJ1cmcxETAPBgNVBAcTCFNhbHpidXJnMR8wHQYD VQQKExZVbml2ZXJzaXR5IG9mIFNhbHpidXJnMScwJQYDVQQLEx5EZXBhcnRtZW50 IG9mIENvbXB1dGVyIFNjaWVuY2UxGjAYBgNVBAMTEW1haWwuY3Muc2JnLmFjLmF0 MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAus33Jb+HE64oJvBEwpeh 7cwyMAknhE5k/49eUG7/E0j2ffEo1APzxYooZ1hlHcf7meH7h1KYD3lSXw5RX0Mi KtuUHSUIqYE1U3+pyussB11r18ucHk8MoFQqPnJDeuSPaHozmdQtJJHRVDabddHz 5l4RVEUduUjzl7vnfFrBhbHV/LpYcLMsNgdlg5I0TXU99Y8paMeF32cWiR2dCeyN t2AajjMpHYRDaJ9DGed8nWOeqK0YRQuaEGF68VBVdygDcOQ0eBflwYEjJChJHhN4 UsQSmwoXYj5ZRvyhcAxxPDYveNhM4oVox67Nvw1AgHz/spaWgJVMKrTU4hFDYcnO 0F6KkumLke0t4IvoLEU7ScAm6d3ttQ5ZBbSIX811kWHC/ddu12AhRiq3y5fN2o3n 6pbRrqljyg4Mu0Tj9UEuwC8bJnCJreo32HQwo82vD1xU8jPUci4UoD21PfkjFssm qbtwwWs1KAIvX52U79u6CC7hvsPNtCiMK0K6/9jg8OyKMraBWvIUV6YxgnuJZ4Mi so/OD6uqdpqCYuq5LLZVAVcBu/vGTzfcckkz71nN2eZSO870rnxyHeTWmepQv4nc gxN49JeReO4zZMio6eC5N9D+SYc5Ae5mS8qyHe/gur6VmbmbWk/vRt/m75lcGLgR A4FRqRvu+GIWNh0uCP9SlkUCAwEAAaOCAgIwggH+MB8GA1UdIwQYMBaAFGf9iCAU J5jHCdIlGbvpURFjdVBiMB0GA1UdDgQWBBR6nRddyu+D1h42fba+bgkBi6OipzBU BgNVHREETTBLghFtYWlsLmNzLnNiZy5hYy5hdIIRc210cC5jcy5zYmcuYWMuYXSC EWltYXAuY3Muc2JnLmFjLmF0ghBwb3AuY3Muc2JnLmFjLmF0MA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwawYDVR0fBGQwYjAv oC2gK4YpaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL1RFUkVOQVNTTENBMy5jcmww L6AtoCuGKWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFTU0xDQTMuY3Js MEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMG4GCCsGAQUFBwEBBGIwYDAk BggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMDgGCCsGAQUFBzAC hixodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVEVSRU5BU1NMQ0EzLmNydDAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBDQUAA4IBAQA6Xbkobv3hQAr532wf0NsZ kYErQebiMLCrKDAhtLc7Z/bO/srUgOs0x9uoIU5ErjLnPcWrPK0eFQevjZ+6CUry NgAcf6f1z9g1IejuapXb6F41YAteJzo+QkvAtQFkOaq9AADXNo6iIOIDyE1M8hWW W0gcwx6h4+UUSLac0LN/i+Q2LcHa6fg/kH59Yt2oIzkJrVRSHn11R8iUHiLgW3X2 XL9BgCZHqI8t3OaJpXLHmvA0pKDIvjFK9+CDcXZWQbZyLlMzGxVyrZfK+rBjL05h QQ3CTy9JJ3/1//AD1mSgog3qSejMQ7ZK01ZZv4lDoEU8ADGFA6VKlV/CiaYz5Ztk -END CERTIFICATE- 1 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA -BEGIN CERTIFICATE- MIIE+zCCA+OgAwIBAgIQCHC8xa8/25Wakctq7u/kZTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv b3QgQ0EwHhcNMTQxMTE4MTIwMDAwWhcNMjQxMTE4MTIwMDAwWjBkMQswCQYDVQQG EwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFt MQ8wDQYDVQQKEwZURVJFTkExGDAWBgNVBAMTD1RFUkVOQSBTU0wgQ0EgMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMV2Dw/ZQyk7bG3RR63eEL8jwnio Snc18SNb4EweQefCMQC9iDdFdd25AhCAHo/tZCMERaegOTuBTc9jP8JJ/yKeiLDS lrlcinQfkioq8hLIt2hUtVhBgUBoBhpPhSn7tU08D08/QJYbzqjMXjX/ZJj1dd10 VAWgNhEEEiRVY++Udy538RV27tOkWUUhn6i+0SftCuirOMo/h9Ha8Y+5Cx9E5+Ct 85XCFk3shKM6ktTPxn3mvcsaQE+zVLHzj28NHuO+SaNW5Ae8jafOHbBbV1bRxBz8 mGXRzUYvkZS/RYVJ+G1ShxwCVgEnFqtyLvRx5GG1IKD6JmlqCvGrn223zyUCAwEA AaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkG CCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQu Y29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGln
