[spamdyke-users] Does one blacklisted address kill the delivery?
Apologies if this question has been asked before, or the answer should be obvious. If Spamdyke detects a blacklisted address in the list of recipients, does it kill the entire connection (thus preventing the message being delivered to any recipient), or does it accept the message for the non-blacklisted recipients? I ask this because many spammers will send spam to a batch of addresses, which may contain a mix of bogus and legitimate addresses. The presence of a bogus address in the list of recipients is often a reliable clue that the message is spam, so it might be useful if spamdyke would kill the whole message in that case. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamtrap-like setup
Dossy Shiobara wrote: Could use a .qmail file for each of those spamtrap addresses which passes the message off to a script which plucks out the sender's IP address (from the appropriate Received: header) and appends it to your ip-blacklist-file. Because spammers may send mail from legitimate hosts (rather than botnets) you may need to whitelist some IP ranges so that you don't inadvertently blacklist Gmail or Hotmail (in which case, things will suddenly get very quiet in your mailbox). I'd recommend AGAINST using the sender email address as it could result in a denial of service if someone simply forges a legitimate email address as the sender address. Pretty much any automated blacklisting is fraught with problems, for exactly this reason. Rather than auto-blacklisting, you might use the presence of one of your spamtrap addresses among the recipients of a message as evidence that the message is spam. Spammers often 'batch' messages, so that their message is sent to several addresses at the same domain in a single transaction. If one of the targeted addresses is only known to spammers, you can dump the whole message. I suggested this as a feature of Spamdyke a while back and Sam said that he might consider adding it in future. I don't know if there's any interim way of implementing this strategy using other tools. Angus On 6/22/11 9:33 AM, Eleftherios Chamakiotis wrote: What I want is this: whenever a message is delivered to one of these addresses, the sender should be automatically added to the blacklist_senders file (or something similar to the same effect). -- Dossy Shiobara | He realized the fastest way to change do...@panoptic.com | is to laugh at your own folly -- then you http://panoptic.com/ | can let go and quickly move on. (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] ip-blacklist not matching
Apologies in advance for what is undoubtedly going to turn out to be a D'oh! error on my part, but I'm running out of ideas here. I'm trying to block incoming mail from French snowshoe spammer multi-fax.fr, who sends mail from a range of IP addresses and changes domain names every day to try to avoid detection. In my IP blacklist file at '/home/vpopmail/spamdyke/ip-blacklist', I have entries: 195.43.150.170 195.43.150.171 194.43.150.172 and so forth. The file contains just 40 lines (so I'm not hitting any upper limits on file size). My spamdyke configuration file at '/etc/spamdyke.conf' contains the line: ip-blacklist-file=/home/vpopmail/spamdyke/ip-blacklist The configuration file does not contain any other 'ip-blacklist-file=' entries, and 'ip-blacklist-entry' is commented out. Spamdyke itself is being invoked with: /usr/local/bin/spamdyke -f /etc/spamdyke.conf … and I know that the correct config file is being read, because it's creating its graylists at the appropriate place. Graylisting and blacklisting work splendidly, by the way. However, the French are still getting through. Here's a 'Received' line from a message: Received: from mx.lirmat.net (195.43.150.172) by mail.mydomain.com with SMTP; 12 Jan 2012 03:15:02 -0500 and here's what the logs have to say about it: /var/log/maillog:Jan 12 03:15:02 s1 spamdyke[16941]: ALLOWED from: 2420428z18...@bounce.lirmat.net to: u...@mydomain.com origin_ip: 195.43.150.172 origin_rdns: mx.lirmat.net auth: (unknown) encryption: (none) I was running Spamdyke 4.1.0, I've just upgraded to Spamdyke 4.2.1. Can anyone think of a reason why IP blacklisting might not be working? Thanks for any help or suggestions, Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] ip-blacklist not matching
Sebastian Grewe wrote: Just a quick question: have you considered using RDNS blacklist instead? Then you wouldn't need that many IPs for the same mail host. Thanks for the suggestion. But this particular spammer has a different invented domain name for each IP that they use (vedalcom.net, lirmat.net, opcal.net, lermu.net etc etc), so - unless I misunderstand something about how rDNS works - I'd just have to end up listing and blocking those names. I may end up blocking an entire /24, simply because it seems that they have most of the IPs in it, and no legitimate traffic that I can see ever comes from there. That would shorten my blacklist file nicely. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Recipient blacklist vs. RDNS checks
Watching the logs on my new mail server, I'm having the pleasure of seeing spamdyke knocking lots of incoming spam on the head. In most cases, the incoming messages are getting taken out by RBL_MATCH, SENDER_NO_MX or RDNS_MISSING rules. A lot of the messages would eventually fail anyway because they're being sent to non-existent recipients. My question is, should I bother adding those non-existent recipients to the recipient blacklist file? Does Spamdyke do less work/take less time to reject a message if it finds the recipient in a blacklist than if it has to do an RBL or RDNS check? I imagine that simple string-matching should be faster and more efficient than doing a network-check (RBL or RDNS), but it probably depends on the order in which Spamdyke does the checks, and whether it re-reads the blacklist file for each message it processes. Any recommendations? Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DDOS Help
On Sep 1, 2012, at 11:17 AM, J.R. Lillard j...@hyphen.org wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. Are the spammers attempting to deliver spam to their server, or to relay spam through it? On my server, SMTP submission requires authentication (if it didn't, I'd be running an open relay) so I see fairly regular attempts by spammers to guess usernames and passwords. While I think it would take them a very very long time indeed to get anywhere, I don't want to give them the opportunity, so I run fail2ban. fail2ban simply watches the VPOPMail logs and, after a certain number of failed attempts from a given IP, simply adds that IP to the iptables firewall, at which point the spammer's packets just get null-routed and it's all over. fail2ban can actually be configured to watch a variety of logs for a variety of conditions, so even if your problem isn't identical, it might be possible to set up fail2ban watch spamdyke's logs and ban anything that gets DENIED_RDNS_MISSING. That would certainly accomplish the drop invalid connections measure suggested by their ISP. I think you can just 'yum install fail2ban' and take it from there. You'll need to read up a bit on how to set up fail2ban's jails, but it's not that complex. If it turns out that spamdyke won't do what you want, try fail2ban. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
BC wrote: Yes. I realize that the impact of the delay is infrequent, but when it happens, it's really annoying, and it impacts productivity. In my case, it usually happens when an email confirmation or notification of some sort is required to do something. This is the absolute worst time for there to be a delay, as it interrupts that process. If you have control over the server, then you should be able to whitelist the domain from which you expect the confirmation email to come. An alternative might be to create a special form of your email address for anything likely to require a confirmation or verification (something like 'youraddress+subscripti...@yourdomain.com'?) and add that to Spamdyke's recipient whitelist so that anything sent to it doesn't get graylisted. That's more risky, because it strips off spamdyke's protection for anything that might get sent to that address (and experience has shown that sooner or later spammers _will_ discover your email address, even if you use it only for things that you think are safe), but it might resolve your problem in the short term. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] RBLs
On Mar 8, 2014, at 6:52 AM, Gary Gendel g...@genashor.com wrote: Almost all of my uncaught spam comes from two domains: colocrossing.com hostnoc.net Color me unsurprised. I even think I know which spammer you're referring to. HostNoc/BurstNet has long had a reputation of being a spam-friendly hosting service. Lately, they seem to be the preferred provider for one of the most prolific and effective spammers I've seen. This particular spammer is exploiting 'syndicated marketing' programs on a massive scale, and they make a point of varying every possible aspect of their messages to systematically work around filtering - From lines, Subject lines, hostnames, message text, even their URL schemes are heavily randomized and changing constantly. Every single feature of the message that could be the target for a filter is changed continuously. Their hosting services (something like 50% of their domains were in HostNoc space, last time I looked) further facilitate things by letting them constantly switch IPs (snowshoe spamming). These guys have put some real thought into getting past filters and blacklists, and it works. So I'd bet that when you talk about uncaught spam, it's theirs. HostNoc also host other similar spam operations, but this outfit is both the most prolific and the hardest to filter. Incidentally, I have a personal axe to grind with HostNoc. I used to be a BurstNet customer until one of their tame spammers moved into the IP block where I had my IPs and pumped out so much crap that the entire block got blacklisted. I spent a few weeks trying to get BurstNet to do something, such as simply allocate me new IPs in a non-contaminated block. They stalled me for a while with vague responses, then took to ignoring me completely, so I switched to a new provider. It sounds like hyperbole, but I really now believe that HostNoc care more about supporting the spammers (who apparently rent a _lot_ of servers) than their legitimate customers. TL;DR: if you null-route every IP that HostNoc owns, it will make a dramatic difference to the amount of spam you see. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] RBLs
BC wrote: On 3/8/2014 7:03 AM, Angus McIntyre wrote: TL;DR: if you null-route every IP that HostNoc owns, it will make a dramatic difference to the amount of spam you see. To what does the TL;DR refer? TL;DR is Internet slang for 'Too Long; Didn't Read'. As it's used now, it's a way for someone who has written a long post to provide a very brief summary of what they said (usually no more than a single line) for the benefit of anyone skim-reading the post. Sometimes the summary may be a humorous simplification of whatever was said. ... How are you null-routing all those IPs? With spamdyke somehow? I'm not actually null-routing HostNoc IPs (but believe me, I've been tempted). You could probably use spamdyke to block mail coming from HostNoc customers, because spamdyke's ip blacklisting allows you to blacklist entire address ranges as well as individual addresses. However, when people talk of 'null-routing' an address, it means configuring your firewall (such as an iptables firewall) to simply drop any incoming packets from that source. It's the most absolute form of rejection possible. The other host literally cannot connect to your system in any way, because you've told the firewall Ignore everything coming from here. Basically, my TL;DR was saying If you refuse to accept any communication whatsoever from this entire chunk of the Internet, it wouldn't be a bad thing. And I was partly joking ... but only partly. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Fwd: Search for High Speed Internet options near you
On Jun 3, 2014, at 11:25 AM, David dmilho...@wletc.com wrote: How in the world do I stop these annoying emails. according to the headers they change the From: Subject: and the domains and ips change as well. It looks like an affiliate spammer. They typically rent a block of IP addresses from one or more hosting providers, then start pumping out spam with syndicated marketing links in it, and get paid when suckers click on the links. I don't recognize this particular one's style, but the bad news is that they tend to be really hard to filter. As you've found out, they constantly change domain names (they probably use domain-kiting to ensure that they never have to pay for names), they constantly change IPs (so-called snowshoe spamming, aided by compliant ISPs), they use hashbuster text in their messages to get past or poison statistical filters, and they constantly change their subjects, from lines, and in some cases even their URL formats. Unfortunately, Spamdyke isn't a lot of help against these guys. They are actually delivering from real mailservers (as opposed to botnet PCs), so graylisting won't help. They generally have their DNS set up correctly, so rDNS checks won't reject them. They change names and IPs so fast that RBLs struggle to keep up. They are among the hardest spammers to block. I suggest that you collect samples of the spam that you're receiving and then analyze them. It's possible that you may be able to identify a small number of IP blocks used by the spammer and block those, although they change IPs and hosting services continually to avoid that. A more productive approach may be to try to identify patterns in the URLs that they use and write a SpamAssassin rule to recognize them. The URL in the sample you sent is very long and complex, which means that you have quite a good chance of writing a regex that would recognize their spams but wouldn't generate false positives on legitimate emails. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Wildcard blacklists for envelope sender
One user on my server has attracted the attention of a spammer who seems
to use a very particular pattern for their sporged 'From' addresses. The
relevant lines in the log look like:
spamdyke[14011]: ALLOWED from: spamtopic-user=mydomain@spamdomain.com
to: u...@mydomain.com origin_ip ...
'spamdomain.com' and 'spamtopic' change continuously, so I can't block on
those. However, the pattern of what I take to be the envelope sender can
always be captured with:
[a-z]+-user=mydomain.com@[a-z-]+\.[a-z]{2,}
I believe that no legitimate message should ever match that pattern.
I don't have any samples of the spammy messages themselves, which are
forwarded offsite (this is why I want to kill them: they're forwarded to a
Gmail address, and Gmail gets cranky if you send it too much spam). So I
don't know if that same bogus address is also used in the 'From' header.
I know that header blacklists support wildcards; I don't think that sender
blacklists do. But I suspect that the envelope sender isn't counted as a
'header'.
Is there a way I can use spamdyke to filter these messages?
Thanks in advance for any tips or suggestions.
Angus
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Help me to understand 503 MAIL first
On 2015-06-22 11:55, Alessio Cecchi via spamdyke-users wrote: one sender (and only this one) is unable to send email to my users, this is the error in spamdyke log: Jun 22 05:47:37 mx01 spamdyke[1066]: DENIED_OTHER from: i...@domain.net to: j...@domain.com origin_ip: 98.18.75.3 origin_rdns: static-98-18-75-3.optusnet.com.au auth: (unknown) encryption: TLS reason: 503_MAIL_first_(#5.5.1) The sender said that is unable to send email only to me so the problem is mine ... How can I solve this problem or how can I demonstrate that is a sender problem? My understanding is that 503 MAIL first occurs when the other side is using badly implemented software that sends SMTP commands out of order. Normally, the SMTP transaction should go something like (with Spamdyke's responses indented for clarity): HELO bar.com 220 baz.com MAIL FROM: u...@bar.com 250 OK RCPT TO: u...@baz.com 250 OK and so on. If the other side starts with: RCPT TO: u...@baz.com Then Spamdyke will respond: 503 MAIL first (#5.5.1) In other words, Spamdyke is saying You should have sent the command MAIL first. I believe that this is what's happening in your case. From my reading of: https://tools.ietf.org/html/rfc821#page-37 Spamdyke is actually right to do this. A client that leads off with an out-of-order command is not following the SMTP protocol. Because SMTP is a stateful protocol, sending out-of-order commands could lead an MTA to end up in an inconsistent state, and mail could be lost. I don't know exactly what the other user's client is sending, but from my experimentation it looks most likely that it's sending RCPT before anything else. If it sent another command, such as DATA, or an unrecognized command such as QUUX, Spamdyke would give a different error. Because this is a fairly fundamental error on the part of the remote client, I would not expect it to be possible to configure Spamdyke to handle this case. Obviously, if he's able to deliver mail to other destinations, then other MTAs must be more forgiving. Nevertheless, it looks to me as if Spamdyke is following RFC821, and his software is not. Sam Clippinger can probably confirm whether or not this is the case, and whether there's anything you can do about it. But it looks to me as if the other guy's software is broken, and it's his problem, not yours. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Fail2ban integration
What log file are those messages from? Are they from '/var/log/maillog'? If so, you might look at /var/log/qmail/smtp/current to see if it offers anything you can use. On my system, spamdyke lines in that log include: origin_ip: 1.2.3.4 so if these attacks cause text to be written to that file -- and the signature is sufficiently distinctive -- then perhaps fail2ban could leverage that. Angus On 2016-07-22 19:17, Gary Gendel via spamdyke-users wrote: Sam, Is there a way to get spamdyke to log invalid authorizations in a manner that fail2ban can use? My host has been hit continuously with brute-force attacks. Unfortunately, the logs only have: Jul 22 18:54:43 tardis spamdyke[26727]: [ID 702911 mail.info] FILTER_AUTH_REQUIRED Jul 22 18:54:50 tardis spamdyke[26727]: [ID 702911 mail.info] ERROR(exec_checkpassword_argv()@exec.c:206): authentication failure (bad username/password, vchkpw uses this to indicate SMTP access is not allowed): verizon Jul 22 18:56:01 tardis spamdyke[26727]: [ID 702911 mail.info] ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found Jul 22 18:57:16 tardis spamdyke[26736]: [ID 702911 mail.info] FILTER_AUTH_REQUIRED Jul 22 18:57:23 tardis spamdyke[26736]: [ID 702911 mail.info] ERROR(exec_checkpassword_argv()@exec.c:206): authentication failure (bad username/password, vchkpw uses this to indicate SMTP access is not allowed): verizon Jul 22 18:58:37 tardis spamdyke[26736]: [ID 702911 mail.info] ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found Jul 22 18:59:59 tardis spamdyke[26743]: [ID 702911 mail.info] FILTER_AUTH_REQUIRED Jul 22 19:00:10 tardis spamdyke[26743]: [ID 702911 mail.info] ERROR(exec_checkpassword_argv()@exec.c:206): authentication failure (bad username/password, vchkpw uses this to indicate SMTP access is not allowed): verizon Jul 22 19:01:21 tardis spamdyke[26743]: [ID 702911 mail.info] ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found Jul 22 19:02:32 tardis spamdyke[26876]: [ID 702911 mail.info] FILTER_AUTH_REQUIRED Jul 22 19:02:38 tardis spamdyke[26876]: [ID 702911 mail.info] ERROR(exec_checkpassword_argv()@exec.c:206): authentication failure (bad username/password, vchkpw uses this to indicate SMTP access is not allowed): verizon Jul 22 19:03:50 tardis spamdyke[26876]: [ID 702911 mail.info] ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found \Jul 22 19:05:11 tardis spamdyke[26891]: [ID 702911 mail.info] FILTER_AUTH_REQUIRED Jul 22 19:05:16 tardis spamdyke[26891]: [ID 702911 mail.info] ERROR(exec_checkpassword_argv()@exec.c:206): authentication failure (bad username/password, vchkpw uses this to indicate SMTP access is not allowed): verizon They seem to have a huge list of account names to try and I've got thousands of attempts just for today. Unfortunately, without any IP address in the message I can't have fail2ban automatically block these. Gary ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Error unable to write to SSL/TLS stream
I think spamdyke implements greylisting by sending a 421 Temporary Failure code on first connection. That might be what's happening here. Greylisting is off by default, but if you have it turned on you could set `graylist-level` to `none` to turn it off. If you want to keep it on but just fix it for that specific domain, you should be able to configure exceptions by adding appropriate `graylist-exception-ip-entry` or `graylist-exception-rdns-entry` entries. Incidentally, I tend to favor disabling greylisting these days. The original intention was to protect against spam clients that couldn't recognize the 421 error as indicating a temporary condition: they'd try once, get an error code, and go away. But from what I see in my own server logs, many -- most? -- spam clients these days just keep attempting redeliveries until either something gets delivered or they hit some threshold number of retries. Greylisting is no help against those. Angus Alessio Cecchi via spamdyke-users wrote on 3/3/21 12:22 PM: > Hi, > > when a specific company send an email to us we receive the messages many > times, but only if they insert into recipients about 50 email address of > the same domain, if they sent the same email to only one recipients all > works fine. > > After some investigation, with "full-log-dir" enabled, we discovered > that our qmail send a "421 timeout" to remote server but when the email > is already accepted, so the remote server try again and so on. > > Debug log, please note the delay from the last . and the error, five > minutes and note that "421 timeout" error was sent before of "250 ok" > from qmail: > > > > [...] > 03/02/2021 12:03:00 FROM REMOTE TO CHILD: 3 bytes TLS > . > > 03/02/2021 12:08:01 LOG OUTPUT TLS > ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The > operation failed due to an I/O error, Connection reset by peer > ERROR(output_writeln()@log.c:104): unable to write 37 bytes to file > descriptor 1: Connection reset by peer > > 03/02/2021 12:08:01 FROM SPAMDYKE TO REMOTE: 37 bytes TLS > 421 Timeout. Talk faster next time. > > 03/02/2021 12:08:01 LOG OUTPUT TLS > TIMEOUT from: u...@company.biz to: u...@partnercompany.biz origin_ip: > 40.107.3.43 origin_rdns: > mail-eopbgr30043.outbound.protection.outlook.com auth: (unknown) > encryption: TLS reason: TIMEOUT > > 03/02/2021 12:10:06 FROM CHILD, FILTERED: 28 bytes TLS > 250 ok 1614683406 qp 12548 > > 03/02/2021 12:10:06 - TLS ended and closed > > 03/02/2021 12:10:06 CLOSED > > > > So I set the timeout from 600 to 1200 in qmail-smtpd, remove > "idle-timeout" from spamdyke, and disable the softlimit, the error > change but the problem is still present: > > > > > 03/02/2021 13:59:27 FROM REMOTE TO CHILD: 3 bytes TLS > . > > 03/02/2021 14:06:34 LOG OUTPUT TLS > ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The > operation failed due to an I/O error, Connection reset by peer > ERROR(output_writeln()@log.c:104): unable to write 26 bytes to file > descriptor 1: Connection reset by peer > > 03/02/2021 14:06:34 FROM CHILD TO REMOTE: 26 bytes TLS > 250 ok 1614690394 qp 765 > > 03/02/2021 14:06:34 LOG OUTPUT TLS > ALLOWED from: u...@company.biz to: u...@partnercompany.biz origin_ip: > 40.107.0.68 origin_rdns: mail-eopbgr00068.outbound.protect > ion.outlook.com auth: (unknown) encryption: TLS reason: > 250_ok_1614690394_qp_765 > [...] > ALLOWED from: us...@company.biz to: us...@partnercompany.biz origin_ip: > 40.107.0.68 origin_rdns: > mail-eopbgr00068.outbound.protection.outlook.com auth: (unknown) > encryption: TLS reason: 250_ok_1614690394_qp_765 > ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The > operation failed due to an I/O error, Unexpected EOF found > > 03/02/2021 14:06:34 - TLS ended and closed > > 03/02/2021 14:06:34 CLOSED > > > > Any suggestions? > > Thanks > > -- > Alessio Cecchi > Postmaster @ http://www.qboxmail.it > https://www.linkedin.com/in/alessice > > > > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > https://spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org https://spamdyke.org/mailman/listinfo/spamdyke-users
