Re: Trusting postfix client certs for relaying
> On Apr 18, 2021, at 10:30 PM, Viktor Dukhovni > wrote: > > On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote: > Each system is issued a certificate for its own domain. Perhaps a better example would be email Subject Alternative Names. >>> >>> That's not an example (use-case), it is a certificate field. What >>> is the use-case. With some specificity... >> >> If I were to run my own email server (I don’t, but I plan on doing >> so someday), my preferred means of authentication would be by client >> certificate. And I would want users to be able to send emails as a >> specific user if, and only if, I have issued them a certificate with >> the corresponding email address in the SAN. > > Though you didn't quite say it explicitly, it seems that you have in > mind an MSA (submission) use-case. And you'd like to associate the the > email addresses that users are allowed to use with their certificates > (possibly as email address SANs, but see below). > >> ... requiring authentication to even connect to the service avoids >> whole heaps of problems. > > That's only true if one neglects many practical details. > >> If the user doesn’t present a certificate, they aren’t going to even >> get an SMTP greeting, much less be able to send mail. > > Perhaps true on port 465, but not quite on 587, though of course > establishing STARTTLS on 587 and getting to "AUTH" can mandate the same > client cert requirements. > >> And that is extremely easy to validate: I just need to ensure that >> connections with no certificate, or with an invalid certificate, fail >> during TLS negotiation. > > Well, the key question is what's an "invalid certificate"? An no longer > authorised user may still be in posession of a certificate that has not > yet expired, and so one way or another you'll need to distinguish > certificates of authorised users from certificates of formerly > authorised users. > > I'd like to suggest that CRLs are by far the worst way to go about this, > and that therefore, you'll want a positive mapping (a table of > authorised certificates, mapping them to notional authorised users). Trying to get postfix to check an OCSP responder would be *hard*. Not that most “toy” CA’s (like ca.pl) have a worthwhile one in place. Since I started this thread, I found *one* possible workaround. (Remember, dayjob is using puppet). I am able to use puppet’s collected facts to build an access db, if that’s something I want to do. We already do something like this where the services on a running machine establish what a host’s monitoring profile will be. For demi, that may be your answer as well — since your CA keeps a list of what certs it has issued, perhaps pumping those into an access table of some sort (with a perl script or the like) may be helpful to you. That said, if what you’re trying to do is use certs to say: the cert issued to bob.domain.com will only allow sending from b...@domain.com, then except on your own mail server, nobody is going to be inspecting the headers for this. (That is to say, this isn’t S/MIME). If the result is that mail is rejected unless this matches, then you’re only increasing the load on yourself. -Dan >
Re: Trusting postfix client certs for relaying
On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote: > >> Each system is issued a certificate for its own domain. Perhaps a > >> better example would be email Subject Alternative Names. > > > > That's not an example (use-case), it is a certificate field. What > > is the use-case. With some specificity... > > If I were to run my own email server (I don’t, but I plan on doing > so someday), my preferred means of authentication would be by client > certificate. And I would want users to be able to send emails as a > specific user if, and only if, I have issued them a certificate with > the corresponding email address in the SAN. Though you didn't quite say it explicitly, it seems that you have in mind an MSA (submission) use-case. And you'd like to associate the the email addresses that users are allowed to use with their certificates (possibly as email address SANs, but see below). > ... requiring authentication to even connect to the service avoids > whole heaps of problems. That's only true if one neglects many practical details. > If the user doesn’t present a certificate, they aren’t going to even > get an SMTP greeting, much less be able to send mail. Perhaps true on port 465, but not quite on 587, though of course establishing STARTTLS on 587 and getting to "AUTH" can mandate the same client cert requirements. > And that is extremely easy to validate: I just need to ensure that > connections with no certificate, or with an invalid certificate, fail > during TLS negotiation. Well, the key question is what's an "invalid certificate"? An no longer authorised user may still be in posession of a certificate that has not yet expired, and so one way or another you'll need to distinguish certificates of authorised users from certificates of formerly authorised users. I'd like to suggest that CRLs are by far the worst way to go about this, and that therefore, you'll want a positive mapping (a table of authorised certificates, mapping them to notional authorised users). > Furthermore, client certificate authentication does not require any > form of credentials (other than the server’s own certificate) to be > stored on the server, nor does it require that the server have any > form of authentication database. Somewhat true, but the server still needs an authorisation database. Which means that the mapping from certificate to user name may as well happen outside the certificate, and will then be possible to manage without reissuing certificates every time a user's authorisation changes, ... There was some discussion on the Postfix list some time back about supporting the SASL TLS AUTH EXTERNAL mechanism with Dovecot. I don't recall where it went, but the idea would be to map client certificate fingerprints to SASL login names, the latter would then be communicated by Postfix to the dovecot SASL backend as the authenticated user name. The rest of the session can then pretend that SASL auth took place, and leverage the smtpd_sender_login_maps tables, check_sasl_access, reject_sender_login_mismatch, ... -- Viktor.
Re: Trusting postfix client certs for relaying
On 4/18/21 8:04 PM, Viktor Dukhovni wrote: > On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote: > Would it be possible to support trusting based on subject alt name? I would like a machine with a certificate for a.example.com to send mail from a.example.com domains. > > This rather mixes end-to-end properties (the message envelope sender is > a fixed element of a mult-hop SMTP relay chain) with hop-by-hop > properties (TLS client certificates). > > Permitting particular client certs is fine for MSA relay authorisation, > but is rather dubious for enforcing the envelope sender domain. > > Are then going to forbid the use of these sender domains unless the > client presents a corresponding certificate? Is this an a message > submission service or an inbound MTA? > >> Each system is issued a certificate for its own domain. Perhaps a >> better example would be email Subject Alternative Names. > > That's not an example (use-case), it is a certificate field. What > is the use-case. With some specificity... If I were to run my own email server (I don’t, but I plan on doing so someday), my preferred means of authentication would be by client certificate. And I would want users to be able to send emails as a specific user if, and only if, I have issued them a certificate with the corresponding email address in the SAN. Why client certificates? Because requiring authentication to even connect to the service avoids whole heaps of problems. If the user doesn’t present a certificate, they aren’t going to even get an SMTP greeting, much less be able to send mail. And that is extremely easy to validate: I just need to ensure that connections with no certificate, or with an invalid certificate, fail during TLS negotiation. Furthermore, client certificate authentication does not require any form of credentials (other than the server’s own certificate) to be stored on the server, nor does it require that the server have any form of authentication database. Finally, Postfix needs to run TLS and verify certificates anyway, so that it can securely relay mail. So client certificate authentication hardly increases the attack surface at all. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
What is the proper value in solrconfig.xml for dovecot?
I'm looking at config documentation for solr on dovecot: https://doc.dovecot.org/configuration_manual/fts/solr/ In the suggested solrconfig.xml file (https://raw.githubusercontent.com/dovecot/core/master/doc/solr-config-7.7.0.xml), it has the following line: 7.7.0 I'm running solr version 8.8.1, however. I'm wondering if I should change this line to: 8.8.1 Things seems to work fine with the 7.7.0 value but there is a comment in the config file that says: I'm not familiar with Lucene or Solr so I'm uncertain as to what to set this to. Thanks.
Re: Trusting postfix client certs for relaying
On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote: > >> Would it be possible to support trusting based on subject alt name? > >> I would like a machine with a certificate for a.example.com to send > >> mail from a.example.com domains. This rather mixes end-to-end properties (the message envelope sender is a fixed element of a mult-hop SMTP relay chain) with hop-by-hop properties (TLS client certificates). Permitting particular client certs is fine for MSA relay authorisation, but is rather dubious for enforcing the envelope sender domain. Are then going to forbid the use of these sender domains unless the client presents a corresponding certificate? Is this an a message submission service or an inbound MTA? > Each system is issued a certificate for its own domain. Perhaps a > better example would be email Subject Alternative Names. That's not an example (use-case), it is a certificate field. What is the use-case. With some specificity... -- Viktor.
Re: Trusting postfix client certs for relaying
On 4/18/21 2:39 PM, Wietse Venema wrote: > Demi Marie Obenour: It seems that There are knobs that let you list *individual certs* for allowing trusted relaying, but not *individual ca's*. Is there any way around this? >>> >>> Yes: handle that traffic with a dedicated smtpd instance that only >>> trusts your internal root. >>> >>> Postfix check_ccert_access currently supports matches based on >>> certificate fingerprint and public key fingerprint. The other >>> available attributes, issuer name and subject name, are too soft >>> for security decisions. >> >> Would it be possible to support trusting based on subject alt name? >> I would like a machine with a certificate for a.example.com to send >> mail from a.example.com domains. > > What is the trust model here? > > Wietse Each system is issued a certificate for its own domain. Perhaps a better example would be email Subject Alternative Names. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
known_tcp_ports (was: Postfix : corrupted SMTP transactions)
Wietse Venema: > As /etc/sevices [has become incompatibly different between platforms > and versions], the solution is to make Postfix less dependent on > that file. Well-known services such as submission, smtps, lmtp, > and smtp, aren't going to move to a different TCP port. Therefore, > I'm thinking of adding a new parameter. A default setting as below > should go a long way. > > known_tcp_ports = > submission = 587, > smtps = submissions = 465, > smtp = 25, > lmtp = 24 This is now implemented for Postfix 3.6. Wietse
Re: Trusting postfix client certs for relaying
Sent from my iPad > On Apr 17, 2021, at 14:16, Wietse Venema wrote: > Dan Mahoney (Gushi): >> All, >> >> The dayjob has a number of machines out in the wild that need to be able >> to send mail (mostly from cron jobs) home to the mothership. Not all have >> controllable reverse DNS. It's an issue with donated colo and transit. >> Doing a bunch of tunnels would work but it's a really stupid answer. >> >> We'd like to use client-certs as an auth mechanism. We're already >> deploying trusted client certs for use with puppet, so we have a full CA >> setup already in place. If we trust any cert signed by our puppetmaster's >> CA (which uses a root/intermediate/leaf setup for signing) we should be >> golden. >> >> However, reading the postfix docs >> (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see >> warnings that one should not use permit_tls_all_clientcerts for something >> like that. If an outside client were to connect with (say) a let's >> encrypt cert configured as a client cert (which we may want to *validate*, >> but *not permit for relaying*, that cert would allow relay) >> >> It seems that There are knobs that let you list *individual certs* for >> allowing trusted relaying, but not *individual ca's*. >> >> Is there any way around this? > > Yes: handle that traffic with a dedicated smtpd instance that only > trusts your internal root. > > Postfix check_ccert_access currently supports matches based on > certificate fingerprint and public key fingerprint. The other > available attributes, issuer name and subject name, are too soft > for security decisions. Yes, but “signed by this cert, which is on local disk” or “traceable back to this root cert, which is on local disk” is not. If the feature’s not there, it’s not there, but this feels possible. -Dan
Re: Trusting postfix client certs for relaying
Demi Marie Obenour: > >> It seems that There are knobs that let you list *individual certs* for > >> allowing trusted relaying, but not *individual ca's*. > >> > >> Is there any way around this? > > > > Yes: handle that traffic with a dedicated smtpd instance that only > > trusts your internal root. > > > > Postfix check_ccert_access currently supports matches based on > > certificate fingerprint and public key fingerprint. The other > > available attributes, issuer name and subject name, are too soft > > for security decisions. > > Would it be possible to support trusting based on subject alt name? > I would like a machine with a certificate for a.example.com to send > mail from a.example.com domains. What is the trust model here? Wietse
Re: Trusting postfix client certs for relaying
On 4/17/21 5:15 PM, Wietse Venema wrote: > Dan Mahoney (Gushi): >> All, >> >> The dayjob has a number of machines out in the wild that need to be able >> to send mail (mostly from cron jobs) home to the mothership. Not all have >> controllable reverse DNS. It's an issue with donated colo and transit. >> Doing a bunch of tunnels would work but it's a really stupid answer. >> >> We'd like to use client-certs as an auth mechanism. We're already >> deploying trusted client certs for use with puppet, so we have a full CA >> setup already in place. If we trust any cert signed by our puppetmaster's >> CA (which uses a root/intermediate/leaf setup for signing) we should be >> golden. >> >> However, reading the postfix docs >> (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see >> warnings that one should not use permit_tls_all_clientcerts for something >> like that. If an outside client were to connect with (say) a let's >> encrypt cert configured as a client cert (which we may want to *validate*, >> but *not permit for relaying*, that cert would allow relay) >> >> It seems that There are knobs that let you list *individual certs* for >> allowing trusted relaying, but not *individual ca's*. >> >> Is there any way around this? > > Yes: handle that traffic with a dedicated smtpd instance that only > trusts your internal root. > > Postfix check_ccert_access currently supports matches based on > certificate fingerprint and public key fingerprint. The other > available attributes, issuer name and subject name, are too soft > for security decisions. > > Wietse Would it be possible to support trusting based on subject alt name? I would like a machine with a certificate for a.example.com to send mail from a.example.com domains. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: connect then disconnect; backscatter?
On 18.04.21 07:55, li...@lazygranch.com wrote: I need to learn postscreen eventually for other spammers. mostly bots, but thanks to dnsbl scoring, spammers too. The thing with fail2ban or the similar sshguard is I have a huge block list for the webserver. It has been my experience that these dynamic blockers that just add a few IPs every few minutes have a huge CPU load because the OS creates what I assume is a very efficient database of IP space to block. if you use linux, try using ipsets for that. They should provide the most efficient solution for this kind of blocking. the only more efficient solution is afaik nullrouting them with rp_filter, but that disables all packets from such IP I have configured fail2ban with ipset and found it very efficient and easy to maintain with other firewalling system. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges.
Re: connect then disconnect; backscatter?
On Sun, 18 Apr 2021 21:29:26 +1200 Nick Tait wrote: > On 18/04/21 7:32 pm, li...@lazygranch.com wrote: > > And so it goes. I suppose if this really bugs me I can block the > > server in firewalld. I've yet to see it actually deliver mail. Or > > complain to the data center. > > https://serveroffer.lt > > Firewalling is definitely the best solution to the problem you're > having, because it will keep your mail logs clear of this sort of > noise. It can feel a bit like whack-a-mole though, and there are > tools around that help with this (although I don't personally have > experience with them), such as fail2ban? > > Even if you choose to manage the firewall rules manually, I'd suggest > you devise some sort of regime where the rules you add aren't > permanent. E.g. I set a timestamp in the comment when I create the > rule, and then after 6 months if there is no current activity from > that IP address I delete the rule again. There are several reasons > for doing this: > > 1. It stops the number of firewall rules growing indefinitely. (Each > rule has a cost in terms of processing.) > 2. If the IP address gets reassigned to a legitimate user, you aren't > penalising them indefinitely for someone else's misbehaviour. > > Nick. > > P.S. Although it isn't suitable for use on your submission port (465 > / 587), in case you aren't aware of it already, check out postscreen: > http://www.postfix.org/POSTSCREEN_README.html > I need to learn postscreen eventually for other spammers. The thing with fail2ban or the similar sshguard is I have a huge block list for the webserver. It has been my experience that these dynamic blockers that just add a few IPs every few minutes have a huge CPU load because the OS creates what I assume is a very efficient database of IP space to block. Creating this database sends my CPU load to 100% and brings the virtual private server (one CPU) to a halt. Firewalld once it has this database set up is very efficient regarding CPU. It does use a fair amount of memory which isn't unexpected given the size of my IP space I block. I reviewed the "rich rules" (a firewalld thing) and noted a have a few IPs on permanent block that I can't remember why so definitely setting up a reminder scheme is needed. I find it pretty offensive that Spectrum/Charter has me on 100% blocking due to the VPS, so I don't take blocking an IP address lightly. Their customers aren't pleased with the blocking either. Spectrum/Charter is alone with this brick wall nonsense. The closest another company comes to this is AT where you need to request to be whitelisted. It takes a week but they do get around to it.
Re: possibly stupid question about tls
Francesc Pe?alvez: > thanks was that, I had smtp_tls_loglevel but not smtpd_tls_loglevel. > Another thing, as is that from the host that sent the mail the > connection appears as: > > Trusted TLS connection established The client trusts the server certificate. > ?but in the log of the host that receives it, it appears as: > > Anonymous TLS connection established from The server has no client certificate. Wietse
Re: possibly stupid question about tls
thanks was that, I had smtp_tls_loglevel but not smtpd_tls_loglevel. Another thing, as is that from the host that sent the mail the connection appears as: Trusted TLS connection established but in the log of the host that receives it, it appears as: Anonymous TLS connection established from El 18/04/2021 a las 15:25, Yassine Chaouche escribió: Here's how I test : $ openssl s_client -connect my.mail.server:submission -starttls smtp the logs show Apr 18 14:18:04 messagerie postfix/smtpd[26383]: connect from unknown[192.168.100.241] Apr 18 14:18:04 messagerie postfix/smtpd[26383]: disconnect from unknown[192.168.100.241] Apr 18 14:18:35 messagerie postfix/submission/smtpd[26513]: connect from unknown[192.168.211.84] Apr 18 14:18:35 messagerie postfix/submission/smtpd[26513]: Anonymous TLS connection established from unknown[192.168.211.84]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 18 14:18:41 messagerie postfix/submission/smtpd[26513]: lost connection after STARTTLS from unknown[192.168.211.84] Apr 18 14:18:41 messagerie postfix/submission/smtpd[26513]: disconnect from unknown[192.168.211.84] Config is : smtpd_tls_loglevel = 1 (in main.cf) Yassine. Le 4/18/21 à 2:13 PM, Yassine Chaouche a écrit : Le 4/18/21 à 12:21 PM, Francesc Peñalvez a écrit : I can only see TO connections but not FROM connections and I would like to see both Can you show us how your logs look like when you make a TLS connection to your server ? Yassine smime.p7s Description: Firma criptográfica S/MIME
Re: possibly stupid question about tls
Here's how I test : $ openssl s_client -connect my.mail.server:submission -starttls smtp the logs show Apr 18 14:18:04 messagerie postfix/smtpd[26383]: connect from unknown[192.168.100.241] Apr 18 14:18:04 messagerie postfix/smtpd[26383]: disconnect from unknown[192.168.100.241] Apr 18 14:18:35 messagerie postfix/submission/smtpd[26513]: connect from unknown[192.168.211.84] Apr 18 14:18:35 messagerie postfix/submission/smtpd[26513]: Anonymous TLS connection established from unknown[192.168.211.84]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 18 14:18:41 messagerie postfix/submission/smtpd[26513]: lost connection after STARTTLS from unknown[192.168.211.84] Apr 18 14:18:41 messagerie postfix/submission/smtpd[26513]: disconnect from unknown[192.168.211.84] Config is : smtpd_tls_loglevel = 1 (in main.cf) Yassine. Le 4/18/21 à 2:13 PM, Yassine Chaouche a écrit : Le 4/18/21 à 12:21 PM, Francesc Peñalvez a écrit : I can only see TO connections but not FROM connections and I would like to see both Can you show us how your logs look like when you make a TLS connection to your server ? Yassine
Re: possibly stupid question about tls
Le 4/18/21 à 12:21 PM, Francesc Peñalvez a écrit : I can only see TO connections but not FROM connections and I would like to see both Can you show us how your logs look like when you make a TLS connection to your server ? Yassine
Re: possibly stupid question about tls
I can only see TO connections but not FROM connections and I would like to see both El 18/04/2021 a las 12:59, Jaroslaw Rafa escribió: Dnia 18.04.2021 o godz. 12:44:41 Francesc Peñalvez pisze: I have postfix configured to log outgoing tls connections: Untrusted TLS connection established to smtp-mx.x but is it possible to log in the same way the incoming connections? It logs for me with default settings in Debian. Here is conection from Postfix list server for your message: Apr 18 12:45:31 rafa postfix/smtpd[1653]: Anonymous TLS connection established from camomile.cloud9.net[168.100.1.3]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) smime.p7s Description: Firma criptográfica S/MIME
Re: possibly stupid question about tls
Dnia 18.04.2021 o godz. 12:44:41 Francesc Peñalvez pisze: > I have postfix configured to log outgoing tls connections: > > Untrusted TLS connection established to smtp-mx.x > > but is it possible to log in the same way the incoming connections? It logs for me with default settings in Debian. Here is conection from Postfix list server for your message: Apr 18 12:45:31 rafa postfix/smtpd[1653]: Anonymous TLS connection established from camomile.cloud9.net[168.100.1.3]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
possibly stupid question about tls
I have postfix configured to log outgoing tls connections: Untrusted TLS connection established to smtp-mx.x but is it possible to log in the same way the incoming connections? smime.p7s Description: Firma criptográfica S/MIME
Re: connect then disconnect; backscatter?
On 18/04/21 7:32 pm, li...@lazygranch.com wrote: And so it goes. I suppose if this really bugs me I can block the server in firewalld. I've yet to see it actually deliver mail. Or complain to the data center. https://serveroffer.lt Firewalling is definitely the best solution to the problem you're having, because it will keep your mail logs clear of this sort of noise. It can feel a bit like whack-a-mole though, and there are tools around that help with this (although I don't personally have experience with them), such as fail2ban? Even if you choose to manage the firewall rules manually, I'd suggest you devise some sort of regime where the rules you add aren't permanent. E.g. I set a timestamp in the comment when I create the rule, and then after 6 months if there is no current activity from that IP address I delete the rule again. There are several reasons for doing this: 1. It stops the number of firewall rules growing indefinitely. (Each rule has a cost in terms of processing.) 2. If the IP address gets reassigned to a legitimate user, you aren't penalising them indefinitely for someone else's misbehaviour. Nick. P.S. Although it isn't suitable for use on your submission port (465 / 587), in case you aren't aware of it already, check out postscreen: http://www.postfix.org/POSTSCREEN_README.html
Re: connect then disconnect; backscatter?
On Sat, 17 Apr 2021 18:25:47 -0400 (EDT) Wietse Venema wrote: > li...@lazygranch.com: > > > You should enable SASL auth in master.cf NOT main.cf, and ONLY for > > > a service that needs SASL auth. > > > > > > Otherwise you're turning it on for the server-to-server port (25) > > > where it is not doing any good. > > > > > > Wietse > > > > > > > OK now it makes sense to comment out the line in the main.cf. I knew > > sasl had to be enabled somewhere. As it turns out I had put all the > > lines in master.cf for the submission 587 but neglected to comment > > out this line in the main.cf. > > > > I did a reload/restart and the mail still works. I will give that > > spammer an hour and see what shows up. The password guesser would > > hit the server about every 20 minutes. All my passwords are high > > entropy 20 characters computer generated. > > Even with SASL turned off you will see that some bots try SASL auth. > But with SASL turned they can't use this to verify passwords. > > Wietse And so it goes. I suppose if this really bugs me I can block the server in firewalld. I've yet to see it actually deliver mail. Or complain to the data center. https://serveroffer.lt Apr 18 04:11:53 mydomain postfix/smtpd[18308]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 18 04:11:53 mydomain postfix/smtpd[18308]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Apr 18 04:44:43 mydomain postfix/smtpd[18400]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 18 04:44:44 mydomain postfix/smtpd[18400]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Apr 18 05:17:38 mydomain postfix/smtpd[18467]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 18 05:17:39 mydomain postfix/smtpd[18467]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Apr 18 05:50:34 mydomain postfix/smtpd[18524]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 18 05:50:35 mydomain postfix/smtpd[18524]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Apr 18 06:23:32 mydomain postfix/smtpd[18626]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 18 06:23:33 mydomain postfix/smtpd[18626]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Apr 18 06:56:24 mydomain postfix/smtpd[18715]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 18 06:56:25 mydomain postfix/smtpd[18715]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3
