![]() ![]() ![]() |
|
One thing I have tried which has worked to an extent...
I setup a hmailserver instance and set the email client to point to this for SMTP and have hmail forward the mail on to the upline smtp server, this allows me to tag on a signature at the end of the email message which is getting past the spam block.
Unfortunately when configuring this in the invoicing software the signature is not being applied, I suspect it is encoding the email in something other than plain text or html/rich text that hmail is looking for.
I also set a global signature in gmail which works when using the web client or imap but when sending via SMTP this is stripped away. back to square one.
Anyone else tried to tackle this issue this way before and has a better solution?
Does anyone reading this thread use or know of anyone using the Synergy software for their business?
I have run into a wall with their support who are saying they only have one instance of this issue (which is me) but I am confident this will be happening with everyone who is sending to Xtra addresses. Their support team is now refusing to talk any further about the issue unless I cough up $85 per 15min for them to tell me what i already know.
It's a long shot but I need someone else who can test this for me.
For those that want further information:
I called 0800 287 463 first, Option 4 then 5 then 2
I was asked to provide the following:
1) Copy of Email you are sending - Click File > Save As
2) Bounceback Message – Screenshot or Copy
3) List of Email accounts unable to send to (if there are many please restrict to at least 5) – Is it all emails @ xtra.co.nz or just some ?
4) Have you tried emailing without any attatchments, does it send?
5) When did you begin having issues sending to @xtra email addresses?
We were sending through AWS Simple Email Service. We were sending appointment confirmation emails etc, not marketing content. We're not a spark/xtra customer. Emails sent through our web application were bouncing, but the same general content (text, no images, no attachment) sent via the same SMTP server (AWS) from Thunderbird wasn't bouncing.
SMX said: "This has been reset now. It looks like the sender is using some sort of email marketing software." but whatever they did fixed it for us.
Yeah no luck here.
Did some more testing last night, I found a way to have the Invoicing package interface with outlook, which causes a new message windows from outlook to appear when sending mail from the invoice package, we can then customise the message such as adding a signature - I though this would be enough to bypass the spam filter but unfortunately no..
The client also has a static IP so I checked that for blacklisting - Does not appear on any black lists.
Found out another user of the same invoicing package is sending emails to xtra addresses without issue.
What I found absolutely BIZZARRE is that I can send the message through outlook rather than the invoicing package directly, it will fails with possible spam content bounceback - I can then copy paste the contents of this message into a new message in Outlook and send and it goes through OK "sometimes" this is hit or miss also.
Between a rock and a hard place here as the software vendor is blaming Spark (Rightfully so) and Spark are blaming the software vendor (Rightfully so as thier software is not customisable enough to bypass filter)
I phoned the number above once more last night, the only other solution they can offer is have the receiver add the sender to the safe senders list - I was unable to find this in the spark webmail? I also dont think this is an acceptable solution for a business with many clients...
Is there anyone who this can be escalated further to hio77? Or if anyone else has any ideas on how we can circumvent this?
Found another interesting development - Sending WoF reminders ar now also being flagged, the bounceback message is saying "This messages was blocked due to Norweigan language detected".
At this point I canot explain it as the mail templates this software uses cannot be altered but others using the same software are sending to xtra email addresses without issues, It seems this particular customer is being flagged somewhere?
Is there anyone around here who I can talk to about this further?
We've been having significant difficulties with sending to @xtra.co.nz addresses recently also, getting the 'Message content rejected as spam' type response for almost every message sent. This has been going on for a month or more. We've had no meaningful assistance trying to talk to people on the Spark support team. The vast majority of our emails are transactional (i.e. invoices / receipts etc). Our delivery and open rates to non-Xtra domains have not changed recently. We normally deliver through Amazon SES, but also use Sendgrid as a fallback, which as been no more successful. SPF records are correct, messages are DKIM signed, testing using the spam test capability from Litmus.com is completely successful.
bonkas:
hio77 - Are there any other avenues we can go down? I have logged another request with Spark, sent numerous emails, has been a week now and have 0 response.
is still on my plate and being passed back and forward, my day to day is exceptionally busy right now unfortunately.
As discussed, your case is unique in that the content is basically textbook email scammer formatted.
#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 having trouble sending business emails to customers with xtra email addresses.
As a work-around - if we add a little comment to the email body (the main content is an attached PDF reciept) then the messages passes the spam filter. This is not ideal.
Its only happened (again) in the last week or two.
We have full DKIM & SPF records etc. hosted with office365 online.
Another work around - just suggested and confirmed to work for us - is to get the xtra client to add you the sender on their whitelist of trusted emails.
bonkas:
Yeah have given the client this option but his answer was a flat out no when he realised he would have to contact 30+ of his clients.
"If you wish to receive email using our services, you must add all 10m users that may contact you to your whitelist."
Gavin / xpd / FastRaccoon / Geek of Coastguard New Zealand
lissie:
Another work around - just suggested and confirmed to work for us - is to get the xtra client to add you the sender on their whitelist of trusted emails.
This might be a useful approach for some, but to be honest with >50k unique Xtra recipients in the past month or two, and up to 15k in a day, it's not really viable for us to try and enforce this. Not to mention plenty of recipients wouldn't know how to do this, and hey if we sent them an email with instructions they wouldn't get it ;)
Now, a small percentage are legitimate bounces where people have typo'd their email, or not updated it if they no longer use that mailbox etc.
|
![]() ![]() ![]() |