cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to reach relay.plus.net (ping)

FIXED
richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)

Thanks.

I will try again in a short while and see what happens.

 

Thanks again

 

Richard

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: Unable to reach relay.plus.net (ping)

Fix

@richardpruen - upon further analysis, it seems you are not only relaying email direct from your IP, but you also have a website hosted on your broadband connection that is configured to send emails?

The reason your IP was blacklisted looks to be the result of the vast amount of messages hitting our relay servers, and looking at the subject lines/from address, it's quite possible that it's your hosted website that's doing the damage. There have been tens of thousands of attempted messages relayed by you in the last month alone.

Assuming your actual email traffic is only a fraction of this, then you need to ensure that your website is fully up to date and secured, and that you are using anti-spam/bot measures where appropriate e.g. a lot of the traffic looks to be registration based.

The relay restriction has been lifted at our side, but if the traffic continues unabated, then your IP is very likely to get blocked again.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)

Hi, Yes the bulk of the email is generated by attempts to sign up for an account, most of those are indeed bots and not useful in the slightest. The site already uses captcha challenges and all accounts need to be verified by clicking an email link (this uses verification to weed out most of the attempted spam accounts, such as browser identification, GeoIP location and RBL and spammer lists of various sorts).

I am using the following MediaWiki extensions to block spam 

StopForumSpam

DnsBlacklistUrls = array( 'zen.spamhaus.org', 'dnsbl.tornevall.org' )

ConfirmEdit, ConfirmEdit/QuestyCaptcha

AbuseFilter

It is very hard to stop the bots from trying to sign up in the first place, they are deliberately made to look like legitimate users, and often the email address they input is false or undeliverable for some reason. That is the main anti-spam measure, having an email token that looks to have been opened by a real person. Feel free to browse the site, you won't see any spam at all, and it gets deleted fast when some makes it through (I deleted one page in the last 6 months for spam).

 

Further suggestions as to how to put a stop to such things, I will be all ears, because I would like to see less pointless traffic as well.

I do keep an eye on the DMARC reports, this is Google Sunday 23:59, to yesterday 23:59 (6 emails in total)

<source_ip>84.92.82.212</source_ip>
<count>6</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>

Logs show roughly 1,000 emails every 7 days (5,000 month), so if there are really tens of thousands something is awry somewhere?

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: Unable to reach relay.plus.net (ping)

I doubt DMARC reports will expose the problem. Our relays will not be able to send DMARC compliant email on your domain's behalf.
The example you quote was sent direct from your IP it seems, not our relays.
I could be confusing messages with events. It may be there are multiple events per email.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)


@bobpullen wrote:
I doubt DMARC reports will expose the problem. Our relays will not be able to send DMARC compliant email on your domain's behalf.
The example you quote was sent direct from your IP it seems, not our relays.
I could be confusing messages with events. It may be there are multiple events per email.

Here is a test email sent a while ago with DMARC, it works exactly as intended, via the relay. The domain SPF records include your own (plusnet's) SPF record, as authorised to send. The SPF record from DNS:

v=spf1 ip4:84.92.82.212 ip6:2001:470:18e4:0:91e6:d402:10ca:5ee7 include:plus.net ~all

the include:plus.net says anything you (plusnet) say is good as a sender is good for me too. You wouldn't be able to sign the mail with the domain key, but forwarding a signed mail, yes that's exactly how it's supposed to work.  

That was the whole point of setting up the system, that if any email was out there that failed DMARC I should be notified, it should be impossible to inject anything anywhere, since the key to sign the mail is only available to the machine running opendkim. I have done a pretty good check of every file on the systems that it could be, and they all come up clean, the only files modified are those that are expected, config files and things like caches and the like. 

I'm at a loss as to where 10s of thousands of emails could have come from, particularly as everything is configured to detect such a thing and notify me. Not to say something might not have gone wrong however it's very strange.  

Diagnotic email follows (note my single comment in italics)

--------------------------------------

From richard@pruen.co.uk Thu Jan 26 00:43:29 2023
Return-Path: <richard@pruen.co.uk>
X-Original-To: ping@tools.mxtoolbox.com
Delivered-To: tools@tools.mxtoolbox.com

note: The line below says it went via the relay
Received: from avasout-ptp-004.plus.net (avasout-ptp-004.plus.net [84.93.230.250])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by tools.mxtoolbox.com (Postfix) with ESMTPS id E14D5BBB27
for <ping@tools.mxtoolbox.com>; Thu, 26 Jan 2023 00:43:28 +0000 (UTC)
Received: from mail.pruen.co.uk ([84.92.82.212])
by smtp with ESMTP
id KqMQpjMdOZs1ZKqMRpNjnk; Thu, 26 Jan 2023 00:43:27 +0000
X-Clacks-Overhead: "GNU Terry Pratchett"
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.4 cv=Arr9YcxP c=1 sm=1 tr=0 ts=63d1ccaf
a=egILLAel5kBVDoTt8yiMPQ==:117 a=egILLAel5kBVDoTt8yiMPQ==:17
a=xqWC_Br6kY4A:10 a=RvmDmJFTN0MA:10 a=iv_rqJ84AAAA:8 a=uRCH99DYmu06ATMsAMUA:9
a=ycG1OLHhaeIA:10 a=TsRpiR_FW7sA:10 a=ZFwyr0ViM60xzzHpwwMA:9
a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=QEXdDO2ut3YA:10
a=9oMncRvxYPCKYecyUE0z:22
Received: from [IPv6:2001:470:18e4:0:1193:66c2:84ad:3636] (unknown [IPv6:2001:470:18e4:0:1193:66c2:84ad:3636])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature ECDSA (P-256))
(No client certificate requested)
by mail.pruen.co.uk (Postfix) with ESMTPSA id 0A558E0045F
for <ping@tools.mxtoolbox.com>; Thu, 26 Jan 2023 00:43:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pruen.co.uk;
s=raspberrypi2.pruen.co.uk; t=1674693806;
bh=nWFyzjdWnG0Lrzvtp7kOnU1LsGvkpPlFqtuT9zcYJR8=;
h=Subject:From:To:Date;
b=SyigjjVDf8/fXX/MIDfKW7g2tlHCDjYFyvwCUAtg6akS+C1i456SR9QCtC78TxXPL
E4SXzOa36JKDuJInhIvN8piUNBUuzfz1/3phSDeOXmibMsfg3mAIKGsagljf4v+E+2
Zy+8sKV92MPea9gEAGTfwfyDFy4s8GbN6fyj+/Kk=
Message-ID: <3f44462539e3974a6c6d147c26e8f64abe840d8a.camel@pruen.co.uk>
Subject: test
From: Richard Pruen <richard@pruen.co.uk>
To: ping@tools.mxtoolbox.com
Content-Type: multipart/alternative; boundary="=-e39g8PV5XYYOUJVpDPNs"
MIME-Version: 1.0
Date: Thu, 26 Jan 2023 00:40:27 +0000
User-Agent: Evolution 3.46.3
X-CMAE-Envelope: MS4xfBl5bgS+cE5LMsYh19nHQ3gT5eOIQbPa3rfO1VrQ1MUZSVGZfeIYrKo4MCRWe9LaRqPBfdP5TS0drmrsh8vgAJ8qQh01iTL+8Jq5REfH8XziX5eC6QXx
G9T6m9myC0EUjXOWlet9y5xN/8EE1eC0PaksAJ9Z4hMLC3Qcm0T+YbrKzCSEsEau0Ueaa5rAjIVxEQW7ABnWiUbOZcgwyeq/iJQ=

--=-e39g8PV5XYYOUJVpDPNs

-----------------------------------------------------

Currently, Spamhaus has removed my IP from the list of IPs that may not deliver mail directly, but must as requested go via relay.plus.net it will be re-added after a year, or when I request it. The Case ID: ST2774086 was used for the removal, and it was the only list this IP was on (policy black list) pbl.spamhaus.org

You are correct that I am currently delivering mail direct, that works out better for me, if a prospective user inputs an address without an MX record, or the server refuses the mail, then I can drop them right away, no need to wait for a bounce. However, I am happy to go back to delivering mail according to the policy, via relay.plus.net. Will wait till this is resolved before making any further changes and adding to the problems of finding out what is going on.

Just for fun 95 account creation requests today, an unusually large number... On the 1st Feb, 28 such requests would have generated emails (a more usual number).

Thanks for the help, and any ideas are gratefully received (from anyone) as to ways to identify the spammers earlier and reduce the number of emails. 

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: Unable to reach relay.plus.net (ping)


@richardpruen wrote:

@bobpullen wrote:
I doubt DMARC reports will expose the problem. Our relays will not be able to send DMARC compliant email on your domain's behalf.
The example you quote was sent direct from your IP it seems, not our relays.
I could be confusing messages with events. It may be there are multiple events per email.

You wouldn't be able to sign the mail with the domain key, but forwarding a signed mail, yes that's exactly how it's supposed to work.  


Fair point. Poorly worded on my part. It's DKIM alignment I was thinking of. That said, it's a bit of a moot point in retrospect. As you say, a lot of the destination email addresses are invalid. Also worth considering that not all valid recipients will provide DMARC feedback.

Sounds like you have done your due-diligence, however it seems it's unlikely to stop our relays from seeing hundreds of similar formatted messages being sent to all manner of spurious mail destinations. In essence, that's what's triggering the blocking.

How long have you had this site running in it's current config? If it's been a while, then you may have just been unlucky due to a short-lived burst of concentrated BOT activity. Might be worth seeing how things go from here-on-in? We can always revisit should it happen again.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)


@bobpullen wrote:

Sounds like you have done your due-diligence, however it seems it's unlikely to stop our relays from seeing hundreds of similar formatted messages being sent to all manner of spurious mail destinations. In essence, that's what's triggering the blocking.

How long have you had this site running in it's current config? If it's been a while, then you may have just been unlucky due to a short-lived burst of concentrated BOT activity. Might be worth seeing how things go from here-on-in? We can always revisit should it happen again.


Ok, I will switch mail delivery back to your relays and ask for the IP to go back on the PBL. Unless you prefer I try direct, that does save a bit of traffic, as it saves a bounce from your servers when the mail is rejected at the other end, It also allows me to drop the signup process earlier, there might be a bit of benefit there.  

The site has been running the same way since Sept 2020, I have tweaked the spam filtering of course maybe every few weeks, or otherwise, it would be overrun by now.

I will revert the changes later on today when I can get a free run at it, dealing with bounces (the need to avoid loops).

richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)

And blocked again pretty much straight away.

It is quite difficult to do much more pre-email token confirmation to verify it isn't some sort of bot. It seems like real people solving the captcha, there are signs in the logs that they are being forwarded to mobile-type browsers.

 

I will look at adding more DNS blacklists if there are any that will help, I have them set to block account creation for IPs that show up already on the ones already in use. 

 

There seems to be an increase in bot activity. A few hundred attempts at account creation in the last few days and quite a lot of the addresses look real but probably would bounce or be undeliverable. Not thousands of emails but hundreds, yes. 

 

If you can suggest anything that would help I am happy to try implementing it, but I have got all the recommended anti spam in place (from the MediaWiki user manual) and many of the 'extreme measures' they suggest as well. 

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: Unable to reach relay.plus.net (ping)

@richardpruen - only thing I can personally think of is investigating whether or not you can put the site behind Cloudflare or something similar. That tends to be pretty efficient at warding off traffic from 'bad' IPs etc.

Do you want me to enquire about unblocking access again?

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)

Hi, Thanks,

I had looked at Cloudflare, and that would work fine for a blog or something that mostly served static content, being a wiki the user-submitted content side needs to talk to the user directly, and since that is what is generating the mail, Cloudflare wouldn't be involved in that transaction, they would have to pass it directly to the server (visual editor requires a 2 way virtual REST connection for it to work, do autocomplete etc)... Net gain zero. 

It's a tricky one for sure.

It's getting hard to think what else to do, honestly, I am already running bind9, with GeoIP2 database for filtering, along with the RBL servers. I'm detecting 99.9% before they add any content to the site, and the 1 that did get through in the last 6 months got taken care of in a few hours, there are a few folks that do moderation/patrol edits. I have also made sure that the user has no way to change the content of the mail, it is just a token and link to verify the email address is valid. 

I'm also aware Plusnet business is going away, so I have to move somewhere else soon anyway.

I will do a bit more research into the MediaWiki manual and see what else might help. I don't think there is much more to be done unfortunately, seems like this is just overhead in determining if it is in fact a real person?

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: Unable to reach relay.plus.net (ping)

With Cloudflare I was thinking more along the lines of stopping certain nefarious traffic from hitting your site in the first place e.g. there's a web application firewall that allows you to block traffic from known BOTs and various challenge/response tools that can be used.

I recognise you're doing some of this stuff yourself, but leveraging Cloudlare as well wouldn't do any harm. I've only personally played around with a few of their features but they seem to work well.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

richardpruen
Dabbler
Posts: 14
Thanks: 1
Registered: ‎03-02-2023

Re: Unable to reach relay.plus.net (ping)

Hi, I looked into Cloudflare, and I can see little benefit other than they have aggregate data on more sites than are monitored by fail2ban users that use the reporting feature. That is what I am using right now as a reactive firewall, it uses reported lists of known bad IPs and monitors local logfiles, it catches or at least limits most DOS attacks (apachekiller, PHP huge posts, anything that trips the system to kill an apache thread for breaching limits) after a couple of goes (to rule out a random crash), it will drop the IP in a temporary black hole. Some things like fake google bots or obviously bad stuff go in the bit bucket right away.

The Cloudflare free options also are free because the product is paid for by the user tracking and attempting to link various tracking info into a user profile, the sale of that demographic data is the way they fund things.

It would require changes to the agreement and probably a page-blocking notice that the user agrees to such data collection, use and resale by third parties. I would actually rather not do that, and the gains seem small.

Right now no cookies are used that aren't required for the site to operate and google analytics only to a minimum level (monitoring site operability, basic info only no tracking is done at all). Thus a banner with info and a note that continuing is an agreement, no options are needed, as the only choice is what is required for operation, or leave. 

Attached are the hits numbers for this month so far, hard to say how many attempts got blocked, because once blocked nothing further is logged as the packets are dropped, I tried logging stuff, but multi-gigabyte logfiles aren't fun and some tools even refuse to load them. This happened only one time when a DDOS hit, and the kernel ran out of iptabes entries (IIRC 27,000 IP addresses were submitted to the blacklist via fail2ban)