Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Are people trying to relay mail through my system?
189 views
Skip to first unread message
Rick Macdonald
Sep 24, 2023, 11:00:05 PM9/24/23
to
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? If so, can I block them
without cutting myself off from remote access to the IMAP server I run
on my system?
Sorry if I sound lame. I set this up over 20 years ago and haven't done
anything to it since.
2023-09-24 20:48:37 1qkRDH-001Zqh-1Z ==
6626-879-8427-40-rickm=timsh...@mail.purecuresol.co R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'mail.purecuresol.co'
2023-09-24 20:48:37 1qkOYj-001Hnf-2V ==
6595-611-17423-903-rickm=timsh...@mail.turntext.co R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'mail.turntext.co'
2023-09-24 20:48:37 1qkLEb-000vn2-2D ==
bounce+c764ac.103fa-rickm=timsh...@inputhealth.com R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'inputhealth.com'
2023-09-24 20:48:37 1qk8eb-00HQEW-2o ==
bounce+c764ac.103fa-rickm=timsh...@inputhealth.com R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'inputhealth.com'
2023-09-24 20:48:37 1qkRGA-001aA2-2k ==
6613-452-119912-590-rickm=timsh...@mail.ikariacool.co R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'mail.ikariacool.co'
2023-09-24 20:48:37 1qkDDB-000ChQ-2S ==
bounce+c764ac.103fa-rickm=timsh...@inputhealth.com R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'inputhealth.com'
2023-09-24 20:48:37 1qkZIY-002gsG-0D ==
6613-452-119912-590-rickm=timsh...@mail.ikariacool.co R=smarthost
T=remote_smtp_smarthost defer (-54): retry time not reached for any host
for 'mail.ikariacool.co'
Rick
Michael Kjörling
Sep 25, 2023, 10:40:05 AM9/25/23
to
On 24 Sep 2023 20:58 -0600, from rick...@shaw.ca (Rick Macdonald):
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?”
> 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
> 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?
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?
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.
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?”
Andy Smith
Sep 25, 2023, 12:10:07 PM9/25/23
to
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=timsh...@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=timsh...@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=timsh...@mail.purecuresol.co> which
implies they might have sent it TO <ri...@timshel.ca> (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
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=timsh...@mail.purecuresol.co R=smarthost
> T=remote_smtp_smarthost defer (-54): retry time not reached for any host for
> 'mail.purecuresol.co'
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=timsh...@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=timsh...@mail.purecuresol.co> which
implies they might have sent it TO <ri...@timshel.ca> (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
Rick Macdonald
Sep 25, 2023, 2:30:07 PM9/25/23
to
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=timsh...@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.
# 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=timsh...@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=timsh...@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=timsh...@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=timsh...@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=timsh...@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=timsh...@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
2023-09-24 12:50:32 6595-611-17423-903-rickm=timsh...@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 15:17:06 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 15:17: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 15:17:08 6595-611-17423-903-rickm=timsh...@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 18:51:18 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 18:51:21 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 18:51:21 6595-611-17423-903-rickm=timsh...@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-25 00:16:50 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-25 00:16:54 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-25 00:16:54 6595-611-17423-903-rickm=timsh...@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-25 06:41:13 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-25 06:41:16 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-25 06:41:16 6595-611-17423-903-rickm=timsh...@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
# exim4 -Mvh 1qkOYj-001Hnf-2V
1qkOYj-001Hnf-2V-H
Debian-exim 104 112
<>
1695559801 0
-received_time_usec .778123
-received_time_complete 1695559801.832337
--helo_name timshel
-host_address [::1]:34848
-interface_address [::1]:25
-received_protocol smtp
-body_linecount 53
-max_received_linelength 103
-host_lookup_failed
-tls_resumption A
XX
1
6595-611-17423-903-rickm=timsh...@mail.turntext.co
183P Received: from [::1] (helo=timshel)
by timshel with smtp (Exim 4.96)
id 1qkOYj-001Hnf-2V
for 6595-611-17423-903-rickm=timsh...@mail.turntext.co;
Sun, 24 Sep 2023 06:50:01 -0600
059 Subject: Mail delivery failed: returning message to sender
051F From: Mail Delivery System <MAILER-DAEMON@timshel>
057T To: 6595-611-17423-903-rickm=timsh...@mail.turntext.co
018 MIME-Version: 1.0
118 Content-Type: multipart/report; report-type=delivery-status;
boundary="foo-mani-padme-hum-306716-2546159-1695559801"
040I Message-Id: <E1qkOYj-001Hnf-2V@timshel>
038 Date: Sun, 24 Sep 2023 06:50:01 -0600
# 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: x295...@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 <ri...@timshel.ca>; 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=WornKnee...@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?" <Worn Knee Cart...@turntext.co>
Reply-To: "Knee Hurts?" <Worn Knee Cart...@turntext.co>
Subject: Instant Knee Pain Relief Trick
To: <ri...@timshel.ca>
Message-ID: <1xu8jk2c4inj2p2f-3y...@turntext.co>
--foo-mani-padme-hum-306716-2546159-1695559801--
>
> I note that the destination addresses on these messages are of the form:
>
> <6626-879-8427-40-rickm=timsh...@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=timsh...@mail.purecuresol.co> which
> implies they might have sent it TO <ri...@timshel.ca> (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.
to reply? (Of course I don't know how to do 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.
Rick
>
> Cheers,
> Andy
>
Rick Macdonald
Sep 25, 2023, 2:40:06 PM9/25/23
to
On 9/25/23 08:29, Michael Kjörling wrote:
> On 24 Sep 2023 20:58 -0600, from rick...@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.
>> 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
>> 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.
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.
last week. I have now removed it from my port forwarding.
Thanks Michael!
Rick
Michael Kjörling
Sep 25, 2023, 2:50:06 PM9/25/23
to
On 25 Sep 2023 12:24 -0600, from rick...@shaw.ca (Rick Macdonald):
be sent is almost certainly local to your system. Good.
> 2023-09-25 06:41:16 6595-611-17423-903-rickm=timsh...@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
...
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=timsh...@mail.purecuresol.co>
Indeed, good catch.
> # 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
>
> 2023-09-24 06:50:01 Received from <> H=(timshel) [::1] P=smtp S=2662
be sent is almost certainly local to your system. Good.
> 2023-09-25 06:41:16 6595-611-17423-903-rickm=timsh...@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
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
> -host_address [::1]:34848
> -interface_address [::1]:25
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
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=timsh...@mail.purecuresol.co>
Andy Smith
Sep 25, 2023, 4:30:07 PM9/25/23
to
On Mon, Sep 25, 2023 at 08:25:48PM +0000, Andy Smith wrote:
> You can remove them from your mail queue with:
>
> # eim4 -Mrm <id>
typo of "exim4"
> You can remove them from your mail queue with:
>
> # eim4 -Mrm <id>
typo of "exim4"
Andy Smith
Sep 25, 2023, 4:30:07 PM9/25/23
to
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:
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 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.
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:
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 <id>
You can get the ids from the "mailq" command or reading your logs.
# eim4 -Mrm <id>
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.
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.
Rick Macdonald
Sep 25, 2023, 4:40:06 PM9/25/23
to
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...
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
Rick Macdonald
Sep 25, 2023, 5:00:07 PM9/25/23
to
16m 2.6K 1qks1r-005B1x-2l <>
6626-879-8427-40-rickm=timsh...@mail.purecuresol.co
15m 3.1K 1qks2o-005BHh-0S <>
bounce+c764ac.103fa-rickm=timsh...@inputhealth.com
15m 2.6K 1qks2o-005BI0-2K <>
6595-611-17423-903-rickm=timsh...@mail.turntext.co
15m 2.7K 1qks2p-005BIG-0u <>
6613-452-119912-590-rickm=timsh...@mail.ikariacool.co
15m 2.6K 1qks2p-005BIL-2m <>
6626-879-8427-40-rickm=timsh...@mail.purecuresol.co
...etc...
2m 2.7K 1qksFP-005Hqj-0e <> *** frozen ***
6613-452-119912-590-rickm=timsh...@mail.ikariacool.co
2m 2.6K 1qksFP-005Hqs-2U <> *** frozen ***
6626-879-8427-40-rickm=timsh...@mail.purecuresol.co
1m 3.1K 1qksGL-005IAq-2A <> *** frozen ***
bounce+c764ac.103fa-rickm=timsh...@inputhealth.com
1m 2.6K 1qksGM-005IBF-0n <> *** frozen ***
6595-611-17423-903-rickm=timsh...@mail.turntext.co
1m 2.7K 1qksGM-005IBh-2h <> *** frozen ***
6613-452-119912-590-rickm=timsh...@mail.ikariacool.co
1m 2.6K 1qksGN-005IBo-1O <> *** frozen ***
6626-879-8427-40-rickm=timsh...@mail.purecuresol.co
I wasn't going to ask about this, but it's looking like this is related
to the problem...
I've been getting hundreds or thousands of "MAIL FROZEN" messages. I
eventually added a procmail rule to send the to /dev/null instead of the
TRASH folder. I guess I should try to understand and fix these as well.
Just now I changed /dev/null to a folder. I see over 20 per minute at
times! Here's the text of one:
Message 1qknJa-004Nen-0O has been frozen (delivery error message).
The sender is <>.
The following address(es) have yet to be delivered:
6595-611-17423-903-rickm=timsh...@mail.turntext.co: SMTP error from remote mail server after MAIL FROM:<> SIZE=3757: 550 <> sender rejected. AUP#CDRBL
>> 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.
to Michael about Thunderbird's Return Receipts can't be part of the problem.
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.
Rick
Rick Macdonald
Sep 25, 2023, 7:00:07 PM9/25/23
to
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?
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
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
Greg Wooledge
Sep 25, 2023, 7:20:05 PM9/25/23
to
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
> 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)?
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.
Rick Macdonald
Sep 25, 2023, 9:50:06 PM9/25/23
to
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
>
Curt
Sep 26, 2023, 10:40:07 AM9/26/23
to
On 2023-09-25, Greg Wooledge <gr...@wooledge.org> 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?
>
> 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.
>
>
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).
0 new messages