![]() ![]() ![]() |
|
chevrolux:hio77: The only path to resoultion here is ensuring your content isnt scammy looking for starters.
After that there is a process the faults helpdesk will help you through that loops back to smx for validation and correction where possible.
The path to resolution is SMX need to stop being bloody ridiculous with their spam filtering.
These emails aren't being dropped by the big boys like Microsoft and Google. So SMX just need to pull their head out of theirs asses and realise they can't guarantee the 99.999999999% filtering they love to claim.
I wonder if they are doing something different for Xtra ? I've been using SMX for 10+ years now(I think, its been a long time) for inbound and outbound mail and we rarely have issues.
xpd:
No offense, but Spark just need to do a Vodafone and get out of the email game.........
If only this were an option. Vodafone took an insane amount of heat over it and lost quite a few customers over it from my understanding.
When I was with Spark and helped with the xtra migration from Yahoo to SMX I took bets on how many would sign up day 1 and after the first week / month. Every time I lost the bet as my numbers were WAY under the numbers who actually signed up to move. Many hundreds of thousands of customers still use their xtra.co.nz email.
I can't see it being shutdown ever.
BarTender:Vodafone featured in the TDR report, ofcourse their name was redacted but it was clear who the provider was....
xpd:
No offense, but Spark just need to do a Vodafone and get out of the email game.........
If only this were an option. Vodafone took an insane amount of heat over it and lost quite a few customers over it from my understanding.
When I was with Spark and helped with the xtra migration from Yahoo to SMX I took bets on how many would sign up day 1 and after the first week / month. Every time I lost the bet as my numbers were WAY under the numbers who actually signed up to move. Many hundreds of thousands of customers still use their xtra.co.nz email.
I can't see it being shutdown ever.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Update - After spending 15 mins on hold, I was finally put through to someone in the "Core" team.
Told them the problem, and she said she had heard of a few of these lately.
Have sent through emails and SMTP logs to this person, and she is going to raise it with SMX.
I did mention they should look at some sort of blanket change, otherwise they will continue to get a bunch more complaints.
We'll see what happens
OP here.
In the end, I worked out that it was my mail server's IP address that was blacklisted; but it seems only for receivers who had not added me as a 'safe sender' . I could send emails to my family, but not to anyone else.
I also tried going direct to SMX with the issue, but was rebuffed and told to talk to Spark, but after 15 mins on hold I gave up and moved my mail server to a new IP. Problem "solved".
At the time, the only RBL my mail server was listed in was UCEPROTECTL2, not because my IP address was blacklisted, but because similar IP addresses were blacklisted (grr). Maybe SMX checks that RBL.
Mike.
Many email providers do use the RBLs. But I didn't think they did it based on similar IPs or ranges.
guyl:
Update - After spending 15 mins on hold, I was finally put through to someone in the "Core" team.
Told them the problem, and she said she had heard of a few of these lately.
Have sent through emails and SMTP logs to this person, and she is going to raise it with SMX.
I did mention they should look at some sort of blanket change, otherwise they will continue to get a bunch more complaints.
We'll see what happens
"Core" team folk are the closest to it, If anyone knows what to do with these cases, these folk will.
They are specially trained in the Spark Business mail product and as such, deal closely with SMX.
All other agents have a path, but it simply goes through a tier 2 team to ensure all the details SMX need are in there - this normally adds a delay of an hour or so to get getting to SMX (so 99.9% of the time the experience really is the same)
A overall change is something that would be nice, there are a few different ways this could go so i can't really say too much other than; It's being worked on.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
mattwnz:
Many email providers do use the RBLs. But I didn't think they did it based on similar IPs or ranges.
I've seen ranges blacklisted. 123.123..123.xxx as a made up example. Not ideal
Peppery: I'm having issues with one of my clients hitting this. They're sending from a Gsuite domain that has correct SPF records set up and are consistently getting "554 5.7.1 Message rejected due to possible spam content". The messages themselves are just text and don't seem spammy at all. Sort of stumped with what to do from this point.
Contact helpdesk, they will go through standard tier one process (taking an example of content and raising to T2 who will validate and pass to SMX to fingerprint.)
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
I'm also seeing this error that's happened almost over night. Customer did an invoice run as they have always done and all their @xtra.co.nz messages got blocked. Contacted the Spark helpdesk but nothing seems to have happened still blocking today.
Oct 5 14:25:07 cetus postfix/smtp[34552]: EC5D6224E5: to=<(redacted)@xtra.co.nz>, relay=mx.xtra.co.nz[210.55.143.33]:25, delay=3.9, delays=0.01/0.02/3.4/0.51, dsn=5.7.1, status=bounced (host mx.xtra.co.nz[210.55.143.33] said: 554 5.7.1 Message rejected due to possible spam content (in reply to end of DATA command))
3 days in a row I've contacted Spark support and still no forward movement.
I'd welcome any suggestions.
hio77:
Peppery: I'm having issues with one of my clients hitting this. They're sending from a Gsuite domain that has correct SPF records set up and are consistently getting "554 5.7.1 Message rejected due to possible spam content". The messages themselves are just text and don't seem spammy at all. Sort of stumped with what to do from this point.
Contact helpdesk, they will go through standard tier one process (taking an example of content and raising to T2 who will validate and pass to SMX to fingerprint.)
Dont get your hopes up too high with this approach... 4-5 months and counting here.
I'm locking this as we're doubling up - Please refer to the other existing thread here: https://www.geekzone.co.nz/forums.asp?forumid=39&topicid=239616
Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)
Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.
|
![]() ![]() ![]() |