Re: Are people trying to relay mail through my system?
On 2023-09-25, Greg Wooledge wrote: > > The preferred policy nowadays is to perform all possible checks *during* > the initial SMTP conversation. If a message fails to meet acceptance > criteria for any reason, it should be rejected during that initial > conversation. Generating a bounce message almost always ends up sending > spam to an innocent third party address, which the malicious sender has > forged. > > How this relates to fetchmail and exim, specifically, I can't say. These > aren't tools I'm deeply familiar with. But if you can do it, try to > arrange it so that any message that can't be accepted gets dropped into > a black hole, rather than generating a bounce message. > > I guess this is what you're alluding to? https://starcat.dp.ua/doc/exim4/FAQ-html/FAQ_7.html 7. POLICY CONTROLS Q0701: How do I block unwanted messages from outside my host? A0701: Exim uses Access Control Lists (ACLs) for controlling incoming mail from other hosts. A whole chapter in the reference manual is devoted to describing how they work. A wide variety of conditions can be imposed on incoming messages. The default Exim run time configuration contains an example of an ACL which blocks all relaying, and messages whose senders cannot be verified. This example is heavily commented and worth studying. Q0702: I don't want to block spam entirely; how can I inspect each message before deciding whether or not to deliver it? A0702: Wherever possible, inspection and rejection is best done automatically in an ACL, that is, before the message is accepted. If you want to verify manually each message that is classified as spam by an automatic check, you can arrange for a system filter to freeze such messages after they have been accepted. If, after inspection, you decide not to deliver the message, it is safest to discard it, using the -Mrm option. Use of the -Mg option to force a bounce carries the risk of “collateral spam” if the sender address is faked (as it usually is in spam).
Re: Are people trying to relay mail through my system?
On 9/25/23 17:11, Greg Wooledge wrote: On Mon, Sep 25, 2023 at 04:49:52PM -0600, Rick Macdonald wrote: Lastly, do I understand correctly that the root of this whole issue is simply misformed headers in the original spam mail that I receive at my Dreamhost account? Oh, and does all this lead to the "Frozen Message" emails I receive (described in a prior email)? I'm not an exim expert, but it seems the fundamental issue here is that your actual receiving MTA (Dreamhost) accepted these messages, but your local exim MTA refused to accept them. Fetchmail kept trying to move the messages from the former to the latter, which failed each time, and caused exim to generate a new bounce message. Each time. The same issue would have arisen in any situation where the first MTA and the second MTA have differing acceptance criteria. Could be syntax errors, could be antispam policy, could be anything that's different between the two MTAs. One of the big revelations in email administration in the last few decades is that the original SMTP design, in which messages were accepted liberally, with bounces generated after the fact if deliveries were not possible, was flawed. It led to many kinds of abuse by malicious senders. The preferred policy nowadays is to perform all possible checks *during* the initial SMTP conversation. If a message fails to meet acceptance criteria for any reason, it should be rejected during that initial conversation. Generating a bounce message almost always ends up sending spam to an innocent third party address, which the malicious sender has forged. How this relates to fetchmail and exim, specifically, I can't say. These aren't tools I'm deeply familiar with. But if you can do it, try to arrange it so that any message that can't be accepted gets dropped into a black hole, rather than generating a bounce message. Thanks Greg. Your summary matches my new understanding. I looked at the Dreamhost mail options and don't see where I can change anything, so the next time I get an email stuck there I'll try adding the fetchmail --nosoftbounce option which should quietly delete the bad message on the server, and stop any future bounce messages. Rick
Re: Are people trying to relay mail through my system?
On Mon, Sep 25, 2023 at 04:49:52PM -0600, Rick Macdonald wrote: > Lastly, do I understand correctly that the root of this whole issue is > simply misformed headers in the original spam mail that I receive at my > Dreamhost account? Oh, and does all this lead to the "Frozen Message" emails > I receive (described in a prior email)? I'm not an exim expert, but it seems the fundamental issue here is that your actual receiving MTA (Dreamhost) accepted these messages, but your local exim MTA refused to accept them. Fetchmail kept trying to move the messages from the former to the latter, which failed each time, and caused exim to generate a new bounce message. Each time. The same issue would have arisen in any situation where the first MTA and the second MTA have differing acceptance criteria. Could be syntax errors, could be antispam policy, could be anything that's different between the two MTAs. One of the big revelations in email administration in the last few decades is that the original SMTP design, in which messages were accepted liberally, with bounces generated after the fact if deliveries were not possible, was flawed. It led to many kinds of abuse by malicious senders. The preferred policy nowadays is to perform all possible checks *during* the initial SMTP conversation. If a message fails to meet acceptance criteria for any reason, it should be rejected during that initial conversation. Generating a bounce message almost always ends up sending spam to an innocent third party address, which the malicious sender has forged. How this relates to fetchmail and exim, specifically, I can't say. These aren't tools I'm deeply familiar with. But if you can do it, try to arrange it so that any message that can't be accepted gets dropped into a black hole, rather than generating a bounce message.
Re: Are people trying to relay mail through my system?
On 9/25/23 14:58, Rick Macdonald wrote: Some of the mail in the queue is up to 4 days old. I'm going to clear it all out to see what new arrives in this state. I've made a bit of progress. First, I deleted the almost 6000 messages in the mail queue: # mailq | grep 1q | cut -c11-26 | xargs exim4 -Mrm Then I noticed that I was still getting more, but always the same 4 messages. I checked on the Dreamhost server where I pull my mail from and sure enough found those 4 messages "stuck" there. I deleted the 4 from Dreamhost, and now all is quiet for the moment. These 4 messages were all spam. I think the mail in the "mailq" kept growing because fetchmail was repeatedly trying but failing to retrieve the same messages over and over. I see a fetchmail option that might help, but I'm wondering if I might then lose some non-spam problematic mail that fetchmail can't fetch? *--nosoftbounce* (since v6.3.10, Keyword: set no softbounce, since v6.3.10) Hard bounce mode. All permanent delivery errors cause messages to be deleted from the upstream server, see "no softbounce" below. *--softbounce* (since v6.3.10, Keyword: set softbounce, since v6.3.10) Soft bounce mode. All permanent delivery errors cause messages to be left on the upstream server if the protocol supports that. Default to match historic fetchmail documentation, to be changed to hard bounce mode in the next fetchmail release. I'm running fetchmail v6.4.37. It appears that --softbounce is still the default. Since they intend to change the default someday to --nosoftbounce, maybe this option isn't as dangerous as it sounds to me? Lastly, do I understand correctly that the root of this whole issue is simply misformed headers in the original spam mail that I receive at my Dreamhost account? Oh, and does all this lead to the "Frozen Message" emails I receive (described in a prior email)? Rick
Re: Are people trying to relay mail through my system?
On 9/25/23 14:25, Andy Smith wrote: Hi Rick, Your system has rejected a spam email, not because it worked out it was spam, but because it was syntactically invalid. That's good, but unfortunately your system decided to helpfully tell the (spam) sender what had happened, by trying to send this bounce message back: On Mon, Sep 25, 2023 at 12:24:52PM -0600, Rick Macdonald wrote: # exim4 -Mvb 1qkOYj-001Hnf-2V 1qkOYj-001Hnf-2V-D --foo-mani-padme-hum-306716-2546159-1695559801 Content-Type: text/plain This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. Reason: General SMTP/ESMTP error. The following address(es) failed: rickm@localhost SMTP error: 550 header syntax --foo-mani-padme-hum-306716-2546159-1695559801 Content-Type: message/delivery-status Reporting-MTA: dns; timshel Final-Recipient: rfc822; rickm@localhost Last-Attempt-Date: Sun, 24 Sep 2023 06:50:01 -0600 (MDT) Action: failed Status: 5.0.0 Diagnostic-Code: 550 header syntax --foo-mani-padme-hum-306716-2546159-1695559801 Content-Type: text/rfc822-headers X-Original-To: ri...@timshel.ca Delivered-To: x2959...@pdx1-sub0-mail-mx207.dreamhost.com Received: from tulsa.turntext.co (unknown [104.234.25.229]) by pdx1-sub0-mail-mx207.dreamhost.com (Postfix) with ESMTP id 4RtbVJ37KPz6m2v for ; Sat, 23 Sep 2023 23:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=turntext.co; h=Mime-Version:Content-Type:Date:From:Reply-To:Subject:To:Message-ID; i=wornkneecartil...@turntext.co; bh=CBxd431jRA2owpgtRRwIfhh07HQ=; b=gHSMnk0fIYnLGQMVojCZV3z41dNcSDXALZjYjGOQIeWpdDRnH1sBJQfHSP1kzPxUfJa/crsQxxk0 EEY0hk6SjSg1YMK0YDqaT3OXZpz67fAgfVqbB+/ZLA7peSq+mggzKwXIfesN5AC+H7c6pFd6rOii E7T+FwmD2FKVnP6z0is= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=turntext.co; b=FZY5bgp2/ypBd4Xc/Efzs345ind+OlkYi2NY3G5/m9tEesrUIeIGeE3JR8wlb2+gDhJDNA2BmzYx 53+nwYoiSBgyl/seZvILf1Ojhxg2y0YQWVwzF4LYDunZHfOV8RsiXxhHwL+xjbcTK3zPuKvdOjRF 1yRVz4iZe7AkjSr5Veo=; Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="21ceb14ceae19fd582462d70f2ee8d8a" Date: Sat, 23 Sep 2023 23:19:41 -0700 From: "Knee Hurts?" Reply-To: "Knee Hurts?" One of those two are probably the headers that your Exim objects to, since they have spaces in the local parts of the address without quoting. The whole emails are of course, unwanted spam. Your other problem, and the reason you have noticed this, is that your smarthost does not want to accept these helpful bounce messages that you are generating. They are using a temporary failure code (451) but their mention of the "AUP" string leads me to believe that they may suspect the messages are spam or spam-related and want nothing to do with them. Either way, they are useless messages and you should stop trying to send them. If my system is trying to reply tho them, should I stop it from trying to reply? (Of course I don't know how to do that!) You can remove them from your mail queue with: # eim4 -Mrm You can get the ids from the "mailq" command or reading your logs. You can specify multiple ids per command line. After doing that you may want to look into how you can avoid sending bounce messages to emails that your system doesn't want to accept. These bounce messages are happening outside of the original SMTP connection (which was between the sender and the MX for your domain) and are generally "too little, too late". Additionally, it seems like you may be sending them as rickm@localhost, which is not helpful even when they are justified. I'm afraid I'm not familiar with your setup so wouldn't know how to configure that. The mailq command shows many of the following: 16m 2.6K 1qks1r-005B1x-2l <> 6626-879-8427-40-rickm=timshel...@mail.purecuresol.co 15m 3.1K 1qks2o-005BHh-0S <> bounce+c764ac.103fa-rickm=timshel...@inputhealth.com 15m 2.6K 1qks2o-005BI0-2K <> 6595-611-17423-903-rickm=timshel...@mail.turntext.co 15m 2.7K 1qks2p-005BIG-0u <> 6613-452-119912-590-rickm=timshel...@mail.ikariacool.co 15m 2.6K 1qks2p-005BIL-2m <> 6626-879-8427-40-rickm=timshel...@mail.purecuresol.co ...etc... 2m 2.7K 1qksFP-005Hqj-0e <> *** frozen *** 6613-452-119912-590-rickm=timshel...@mail.ikariacool.co 2m 2.6K 1qksFP-005Hqs-2U <> *** frozen *** 6626-879-8427-40-rickm=timshel...@mail.purecuresol.co 1m 3.1K 1qksGL-005IAq-2A <> *** frozen *** bounce+c764ac.103fa-rickm=timshel...@inputhealth.com 1m 2.6K 1qksGM-005IBF-0n <> *** frozen *** 6595-611-17423-903-rickm=timshel...@mail.turntext.co 1m 2.7K 1qksGM-005IBh-2h <> *** frozen *** 6613-452-119912-590-rickm=timshel...@mail.ikariacool.co 1m 2.6K 1qksGN-005IBo-1O <> *** frozen *** 6626-879-8427-40-rickm=timshel...@mail.purecuresol.co I wasn't going to ask about this, but it's looking like this is
Re: Are people trying to relay mail through my system?
On 9/25/23 12:42, Michael Kjörling wrote: The following address(es) failed: rickm@localhost SMTP error: 550 header syntax So something running on your local system almost certainly tried to send mail to either "rickm" or "rickm@localhost", and that triggered queuing the non-delivery notice which you're seeing evidence of in your outgoing mail logs. Do you have something like fetchmail set up in multidrop mode, any forwarding procmail rules, spam filtering, or anything similar, especially ones that would be triggered by something being sent to... Not multi-drop mode, no forwarding procmail rules: only delivery to mail folders (and a few to /dev/null). I did find that I had Thunderbird Return Receipts turned on for some cases. I thought it was set to "always ask me". I've used Thunderbird forever, and it's asked me maybe once. However, I see now something that I missed understanding: If I'm not in the To or Cc of the message: Ask me These spam emails would have me in the To field. Could this be the origin of these reply attempts? I've now set it to "Never", but based on your comments and Andy's, this doesn't seem to be the source of the messages? Rick
Re: Are people trying to relay mail through my system?
On Mon, Sep 25, 2023 at 08:25:48PM +, Andy Smith wrote: > You can remove them from your mail queue with: > > # eim4 -Mrm typo of "exim4" -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Are people trying to relay mail through my system?
Hi Rick, Your system has rejected a spam email, not because it worked out it was spam, but because it was syntactically invalid. That's good, but unfortunately your system decided to helpfully tell the (spam) sender what had happened, by trying to send this bounce message back: On Mon, Sep 25, 2023 at 12:24:52PM -0600, Rick Macdonald wrote: > # exim4 -Mvb 1qkOYj-001Hnf-2V > > 1qkOYj-001Hnf-2V-D > --foo-mani-padme-hum-306716-2546159-1695559801 > Content-Type: text/plain > > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. > > Reason: General SMTP/ESMTP error. > > The following address(es) failed: > rickm@localhost > SMTP error: 550 header syntax > > --foo-mani-padme-hum-306716-2546159-1695559801 > Content-Type: message/delivery-status > > Reporting-MTA: dns; timshel > > Final-Recipient: rfc822; rickm@localhost > Last-Attempt-Date: Sun, 24 Sep 2023 06:50:01 -0600 (MDT) > Action: failed > Status: 5.0.0 > Diagnostic-Code: 550 header syntax > > --foo-mani-padme-hum-306716-2546159-1695559801 > Content-Type: text/rfc822-headers > > X-Original-To: ri...@timshel.ca > Delivered-To: x2959...@pdx1-sub0-mail-mx207.dreamhost.com > Received: from tulsa.turntext.co (unknown [104.234.25.229]) > by pdx1-sub0-mail-mx207.dreamhost.com (Postfix) with ESMTP id > 4RtbVJ37KPz6m2v > for ; Sat, 23 Sep 2023 23:20:56 -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=turntext.co; > h=Mime-Version:Content-Type:Date:From:Reply-To:Subject:To:Message-ID; > i=wornkneecartil...@turntext.co; > bh=CBxd431jRA2owpgtRRwIfhh07HQ=; > > b=gHSMnk0fIYnLGQMVojCZV3z41dNcSDXALZjYjGOQIeWpdDRnH1sBJQfHSP1kzPxUfJa/crsQxxk0 > EEY0hk6SjSg1YMK0YDqaT3OXZpz67fAgfVqbB+/ZLA7peSq+mggzKwXIfesN5AC+H7c6pFd6rOii > E7T+FwmD2FKVnP6z0is= > DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=turntext.co; > > b=FZY5bgp2/ypBd4Xc/Efzs345ind+OlkYi2NY3G5/m9tEesrUIeIGeE3JR8wlb2+gDhJDNA2BmzYx > 53+nwYoiSBgyl/seZvILf1Ojhxg2y0YQWVwzF4LYDunZHfOV8RsiXxhHwL+xjbcTK3zPuKvdOjRF > 1yRVz4iZe7AkjSr5Veo=; > Mime-Version: 1.0 > Content-Type: multipart/alternative; > boundary="21ceb14ceae19fd582462d70f2ee8d8a" > Date: Sat, 23 Sep 2023 23:19:41 -0700 > From: "Knee Hurts?" > Reply-To: "Knee Hurts?" One of those two are probably the headers that your Exim objects to, since they have spaces in the local parts of the address without quoting. The whole emails are of course, unwanted spam. Your other problem, and the reason you have noticed this, is that your smarthost does not want to accept these helpful bounce messages that you are generating. They are using a temporary failure code (451) but their mention of the "AUP" string leads me to believe that they may suspect the messages are spam or spam-related and want nothing to do with them. Either way, they are useless messages and you should stop trying to send them. > If my system is trying to reply tho them, should I stop it from trying to > reply? (Of course I don't know how to do that!) You can remove them from your mail queue with: # eim4 -Mrm You can get the ids from the "mailq" command or reading your logs. You can specify multiple ids per command line. After doing that you may want to look into how you can avoid sending bounce messages to emails that your system doesn't want to accept. These bounce messages are happening outside of the original SMTP connection (which was between the sender and the MX for your domain) and are generally "too little, too late". Additionally, it seems like you may be sending them as rickm@localhost, which is not helpful even when they are justified. I'm afraid I'm not familiar with your setup so wouldn't know how to configure that. > I should explain that my domain and email address are hosted at Dreamhost. I > use fetchmail to pull it from there to the IMAP server that I run on my > Linux machine. So I think that means these reply attempts occur when > fetchmail passes mail to my local machine. I've been adding more and more > rules to my procmail filtering, but I don't know if these reply attempts are > before or after procmail processes my rules. These appear to be because fetchmail attempted to deliver messages to you that were syntactically invalid, so your Exim rejected them and generated a bounce message to the sender to be helpful. You never saw the messages and procmail was not involved as Exim did not get as far as doing a delivery attempt. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Are people trying to relay mail through my system?
On 25 Sep 2023 12:24 -0600, from rickm...@shaw.ca (Rick Macdonald): > # exim4 -Mvl 1qkOYj-001Hnf-2V > > 2023-09-24 06:50:01 Received from <> H=(timshel) [::1] P=smtp S=2662 ::1 is IPv6 localhost. So whatever caused that particular message to be sent is almost certainly local to your system. Good. > 2023-09-25 06:41:16 6595-611-17423-903-rickm=timshel...@mail.turntext.co > R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net > [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> > SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT Looks like your ISP's smarthost doesn't want null envelope return addresses. 4xx is supposed to be temporary, but seems to me like they are doing it as a pseudo-permanent-error response. > # exim4 -Mvh 1qkOYj-001Hnf-2V ... > --helo_name timshel > -host_address [::1]:34848 > -interface_address [::1]:25 Again, seems to me like confirmation that the email with that particular ID originated locally on your host, not on the network. Which is good, because it means your SMTP server is likely not being abused as an open relay. > The following address(es) failed: > rickm@localhost > SMTP error: 550 header syntax So something running on your local system almost certainly tried to send mail to either "rickm" or "rickm@localhost", and that triggered queuing the non-delivery notice which you're seeing evidence of in your outgoing mail logs. Do you have something like fetchmail set up in multidrop mode, any forwarding procmail rules, spam filtering, or anything similar, especially ones that would be triggered by something being sent to... > X-Original-To: ri...@timshel.ca I know that fetchmail at least used to have a way to set it up to take the local part from the recipient email address and forward that to the local MTA/MDA for delivery. If usernames don't match exactly, that's an easy way to go astray and potentially cause backscatter, especially if you're also set up to use your ISP's outgoing SMTP server as a smarthost. And from Rick: >> I note that the destination addresses on these messages are of the form: >> >> <6626-879-8427-40-rickm=timshel...@mail.purecuresol.co> Indeed, good catch. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Are people trying to relay mail through my system?
On 9/25/23 08:29, Michael Kjörling wrote: On 24 Sep 2023 20:58 -0600, from rickm...@shaw.ca (Rick Macdonald): My /var/log/.exim4/log file is flooded with messages such as shown below. I'm not trying to send mail to any of those .co or .com addresses. I use my ISP (shaw.ca cable provider) as a smarthost. Are people trying to use my system as a relay? The log snippet you show doesn't include enough information to tell for certain where those emails were originally accepted from, but given what you wrote I wouldn't dismiss the possibility out of hand. I've sent some more log info just now in a reply to Andy Smith. If so, can I block them without cutting myself off from remote access to the IMAP server I run on my system? You don't seem to be exposing any SMTP server to the outside world, so I don't know what might reasonably be going on. Otherwise blocking off TCP ports 25 and 587 would probably have been a good place to start. Sorry if I sound lame. I set this up over 20 years ago and haven't done anything to it since. If you set it up in the early 2000s and haven't done anything since then, there's certainly a non-zero probability that it's set up as an open relay. But although that's a potential problem, it would only be a _big_ problem if it was accessible from outside of your network, which does not _immediately_ appear to be the case. Ports 25 and 587 are not forwarded by my ASUS router. They may well have been back in the day. However, on a semi-unrelated note, you might want to make sure that the firmware and software is up to date on everything you _do_ expose to the Internet. It looks like ASUS' web server has had stack-smashing vulnerabilities previously (not sure if the RT-AC66U is affected), and whatever is running through Restlet Framework on port 23424 reports a version of server software that hasn't been updated since 2014. And that's just some of what I plausibly found barely looking. Well spotted! Port 23424 was for a server that I stopped running just last week. I have now removed it from my port forwarding. Thanks Michael! Rick
Re: Are people trying to relay mail through my system?
On 9/25/23 10:03, Andy Smith wrote: Hi Rick, On Sun, Sep 24, 2023 at 08:58:04PM -0600, Rick Macdonald wrote: 2023-09-24 20:48:37 1qkRDH-001Zqh-1Z == 6626-879-8427-40-rickm=timshel...@mail.purecuresol.co R=smarthost T=remote_smtp_smarthost defer (-54): retry time not reached for any host for 'mail.purecuresol.co' There isn't anything shown except delivery attempts so we can';t see how these messages got in to your system. You can see all logs related to this message with: # exim4 -Mvl 1qkOYj-001Hnf-2V and view its headers and body with "-Mvh" and "-Mvb" respectively. That might give you some more hints. Thanks Andy! Here are those lists: # exim4 -Mvl 1qkOYj-001Hnf-2V 2023-09-24 06:50:01 Received from <> H=(timshel) [::1] P=smtp S=2662 2023-09-24 06:50:05 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 06:50:08 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 06:50:08 6595-611-17423-903-rickm=timshel...@mail.turntext.co R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 07:38:45 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 07:38:48 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 07:38:48 6595-611-17423-903-rickm=timshel...@mail.turntext.co R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 07:56:28 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 07:56:31 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 07:56:31 6595-611-17423-903-rickm=timshel...@mail.turntext.co R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 08:37:50 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 08:37:53 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 08:37:53 6595-611-17423-903-rickm=timshel...@mail.turntext.co R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 09:23:46 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 09:23:49 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 09:23:49 6595-611-17423-903-rickm=timshel...@mail.turntext.co R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 10:54:59 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 10:55:02 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 10:55:02 6595-611-17423-903-rickm=timshel...@mail.turntext.co R=smarthost T=remote_smtp_smarthost defer (-45) H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 12:50:28 H=shawmail.glb.shawcable.net [64.59.136.142]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT 2023-09-24 12:50:32 H=shawmail.glb.shawcable.net [64.59.128.135]: SMTP error from remote mail server after MAIL FROM:<> SIZE=3752: 451 <> server temporarily unavailable. AUP#MXRT
Re: Are people trying to relay mail through my system?
Hi Rick, On Sun, Sep 24, 2023 at 08:58:04PM -0600, Rick Macdonald wrote: > 2023-09-24 20:48:37 1qkRDH-001Zqh-1Z == > 6626-879-8427-40-rickm=timshel...@mail.purecuresol.co R=smarthost > T=remote_smtp_smarthost defer (-54): retry time not reached for any host for > 'mail.purecuresol.co' There isn't anything shown except delivery attempts so we can';t see how these messages got in to your system. You can see all logs related to this message with: # exim4 -Mvl 1qkOYj-001Hnf-2V and view its headers and body with "-Mvh" and "-Mvb" respectively. That might give you some more hints. I note that the destination addresses on these messages are of the form: <6626-879-8427-40-rickm=timshel...@mail.purecuresol.co> and your name is Rick Macdonald, so it seems possible to me that they have sent you an email with their envelope sender set to <6626-879-8427-40-rickm=timshel...@mail.purecuresol.co> which implies they might have sent it TO (an address for you encoded in their envelope sender so they can track bounces), which might be you. Perhaps your system is trying to send a response to a mail you have received. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Are people trying to relay mail through my system?
On 24 Sep 2023 20:58 -0600, from rickm...@shaw.ca (Rick Macdonald): > My /var/log/.exim4/log file is flooded with messages such as shown below. > I'm not trying to send mail to any of those .co or .com addresses. I use my > ISP (shaw.ca cable provider) as a smarthost. > > Are people trying to use my system as a relay? The log snippet you show doesn't include enough information to tell for certain where those emails were originally accepted from, but given what you wrote I wouldn't dismiss the possibility out of hand. > If so, can I block them > without cutting myself off from remote access to the IMAP server I run on my > system? You don't seem to be exposing any SMTP server to the outside world, so I don't know what might reasonably be going on. Otherwise blocking off TCP ports 25 and 587 would probably have been a good place to start. IMAP and SMTP solve completely different problems and last I looked Exim didn't even talk IMAP, so even blocking off one should have zero effect on the other. > Sorry if I sound lame. I set this up over 20 years ago and haven't done > anything to it since. If you set it up in the early 2000s and haven't done anything since then, there's certainly a non-zero probability that it's set up as an open relay. But although that's a potential problem, it would only be a _big_ problem if it was accessible from outside of your network, which does not _immediately_ appear to be the case. However, on a semi-unrelated note, you might want to make sure that the firmware and software is up to date on everything you _do_ expose to the Internet. It looks like ASUS' web server has had stack-smashing vulnerabilities previously (not sure if the RT-AC66U is affected), and whatever is running through Restlet Framework on port 23424 reports a version of server software that hasn't been updated since 2014. And that's just some of what I plausibly found barely looking. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
