Hi, We have started receiving complaints from several of our customers for whom we are the MX for their domain. Some addresses in the domain are delivered locally, some are relayed to other mailboxes e.g. gmail and xtra. It seems that there are folks who still believe that SPF is a good thing and have ‘-all’ on their record. Xtra it would appear is now enforcing the rejection on email we relay to them. We are placed in an awkward position. Our customer wants us to fix something that we are not really able to. The SPF policy belongs to the sender and Xtra are doing the rejection. I have come across another add on technology for postfix called SRS for rewriting senders but that seems to be broken from all accounts as well. Is anyone else having these sort of issues, is there something I should be doing in the ‘relay’ process that will prevent the rejections I’d love to hear. Glen -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph +64 6 357 8168, Mob +64 27 542 4015 “Specialising in providing low-cost professional Internet Services since 1997"
On 8/02/2017, at 12:53 PM, Brian Gibbons
wrote: Relaying email is the perfect recipe to get blacklisted, the solution is fix the problem by hosting the email locally and have end user collect email from multiple hosts.
Never been an issue before now and have been doing this for 20 years. Maybe I am using the wrong terminology abcd(a)mydomain.nz mailto:abcd(a)mydomain.nz is delivered locally - no problem efgh(a)mydomain.nz mailto:efgh(a)mydomain.nz is forwarded/redirected/relayed to efgh(a)xtra.co.nz mailto:efgh(a)xtra.co.nz - only a problem when SPF has a hard fail set Most of our customers want email to work this way. The end users are in most case NOT prepared to have complicated email setups.
Easiest solution I've found is for the problematic sender domains - you'll
have to get the users to set the sites to send the e-mail directly to the
end address rather than the domain that's relaying.
Thankfully there's only a few big ones of note. Twitter is a prime culprit
that I've noticed :)
Cheers,
Blair
On 8 February 2017 at 13:11, Glen Eustace
On 8/02/2017, at 12:53 PM, Brian Gibbons
wrote: Relaying email is the perfect recipe to get blacklisted, the solution is fix the problem by hosting the email locally and have end user collect email from multiple hosts.
Never been an issue before now and have been doing this for 20 years. Maybe I am using the wrong terminology
abcd(a)mydomain.nz is delivered locally - no problem efgh(a)mydomain.nz is forwarded/redirected/relayed to efgh(a)xtra.co.nz - only a problem when SPF has a hard fail set
Most of our customers want email to work this way. The end users are in most case NOT prepared to have complicated email setups.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
The xtra.co.nz domain doesn't seem to have a DKIM or SPF record attached to
it, in fact there isn't any txt record on the domain.
But I believe that is coming once the migration has been completed.
On Wed, Feb 8, 2017 at 1:16 PM, Blair Harrison
Easiest solution I've found is for the problematic sender domains - you'll have to get the users to set the sites to send the e-mail directly to the end address rather than the domain that's relaying.
Thankfully there's only a few big ones of note. Twitter is a prime culprit that I've noticed :)
Cheers, Blair
On 8 February 2017 at 13:11, Glen Eustace
wrote: On 8/02/2017, at 12:53 PM, Brian Gibbons
wrote: Relaying email is the perfect recipe to get blacklisted, the solution is fix the problem by hosting the email locally and have end user collect email from multiple hosts.
Never been an issue before now and have been doing this for 20 years. Maybe I am using the wrong terminology
abcd(a)mydomain.nz is delivered locally - no problem efgh(a)mydomain.nz is forwarded/redirected/relayed to efgh(a)xtra.co.nz - only a problem when SPF has a hard fail set
Most of our customers want email to work this way. The end users are in most case NOT prepared to have complicated email setups.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
On 8/02/2017, at 1:24 PM, Peter Lambrechtsen
wrote: The xtra.co.nz http://xtra.co.nz/ domain doesn't seem to have a DKIM or SPF record attached to it, in fact there isn't any txt record on the domain.
This isn’t a case of an SPF on xtra.co.nz http://xtra.co.nz/ but SPFs from senders that end up with final delivery being an Xtra mailbox.
Any indication of them bouncing messages with no SPF at all?
Cheers
JT
From: "Glen Eustace"
On 8 February 2017 at 13:33, Glen Eustace
On 8/02/2017, at 1:24 PM, Peter Lambrechtsen
wrote: The xtra.co.nz domain doesn't seem to have a DKIM or SPF record attached to it, in fact there isn't any txt record on the domain.
This isn’t a case of an SPF on xtra.co.nz but SPFs from senders that end up with final delivery being an Xtra mailbox.
(expanded from ): host mx.xtra.co.nz[210.55.143.33] said: 550 5.7.1 Message rejected due to SPF policy (in reply to end of DATA command) where senders domain has -all on its SPF record.
Certainly had at least one case recently with a customer who hosts with
Mesh|net using SMTP via snap to an xtra address, that went via orcon and
failed.
They had the Snap MXs in SPF etc (*+include:**snap.net.nz*
http://snap.net.nz/* -all )* but not orcon or xtra. It looked like Xtra
was looking at the Orcon EHLO and failing.
Changed their SPF to *~all* and seems to work with the softfail - "Results
- softfail domain owner discourages use of this host" - but something is
broken.
Jo Booth - Mesh|net
*Connecting Communities*
Jo(a)Mesh.net.nz
Hi Glen. Sorry for top posting, not replying to anything in particular in this message, but the thread in general. I had intended to send this a while back when the thread was active but forgot, and, now the weird-ass late message from Jeremy brought it back to my attention. Anyway, email forwarding can mean several different things, I’m not sure if the terminology is well defined, but effective there are 3 main ways you can do it: 1) Rewrite envelope recipient 2) Rewrite envelope recipient and sender 3) Rewrite envelope recipient and sender, and header To (and optionally From) It is well understood that SPF does not work well with (1). I’m surprised that this is the first time you have encountered this - perhaps you have other customers who have hit it silently. My recommendation if you’re building a mail product with the option for forwarding, is to: 1) Rewrite envelope recipient (obviously) 2) Rewrite envelope sender to the original envelop recipient (i.e. your customer’s email address in your system) with an additional tag so it is clear that email to that address (bounces) are not to be forwarded. 3) Catch bounces back from the destination server, and act on them in some way. Perhaps you temporarily disable forwarding, and queue mail up, then re-try it from time to time. Perhaps you have a way to alert the customer through some alternative email address or other means. Make sure you don’t re-forward those bounces to your customer - this is what the tag in (2) is for.
On 8/02/2017, at 12:46 PM, Glen Eustace
wrote: Hi,
We have started receiving complaints from several of our customers for whom we are the MX for their domain. Some addresses in the domain are delivered locally, some are relayed to other mailboxes e.g. gmail and xtra.
It seems that there are folks who still believe that SPF is a good thing and have ‘-all’ on their record. Xtra it would appear is now enforcing the rejection on email we relay to them. We are placed in an awkward position. Our customer wants us to fix something that we are not really able to. The SPF policy belongs to the sender and Xtra are doing the rejection.
I have come across another add on technology for postfix called SRS for rewriting senders but that seems to be broken from all accounts as well.
Is anyone else having these sort of issues, is there something I should be doing in the ‘relay’ process that will prevent the rejections I’d love to hear.
Glen -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph +64 6 357 8168, Mob +64 27 542 4015
“Specialising in providing low-cost professional Internet Services since 1997"
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
On 2/04/2017, at 2:07 PM, Nathan Ward
wrote: My recommendation if you’re building a mail product with the option for forwarding, is to: 1) Rewrite envelope recipient (obviously)
This was done as soon as I was made aware of the SRS stuff for Postfix and to date seems to have ‘fixed’ the issue for us. I am still of the opinion that SPF is broken but seem to be fairly alone holding that opinion. I suppose if I had encountered issues with relaying earlier I might have become aware of SRS sooner but as I hadn’t I didn’t. Old story that one doesn’t know what one doesn’t know. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph +64 6 357 8168, Mob +64 27 542 4015 “Specialising in providing low-cost professional Internet Services since 1997"
On 2 Apr. 2017 12:32, "Glen Eustace"
+1 to Martin this week. I've got folk getting IRD messages being bounced. Personally the only thing I really find of use in my mail stack is grey listing, for stopping spam. I've just about stripped the rest out and just let people deal with the noise as they see fit. LIke others here, I don't find SFP useful and more often than not I find it causes people a headake as no one really understands it properly (my self included) and are often very unwilling to even engage to attempt to fix it. Even tracking down the mail admin for a company can be time consuming to the point of pointlessness. D On 2/04/2017 3:28 PM, Martin Kealey wrote:
On 2 Apr. 2017 12:32, "Glen Eustace"
mailto:geustace(a)godzone.net.nz> wrote: I am still of the opinion that SPF is broken but seem to be fairly alone holding that opinion.
Well I somewhat share your opinion.
I don't think that SPF /per-se/ is broken, but typical implementations definitely /are/ broken.
I do think that applying SPF to /inbound/ relays is definitely broken. A service provider should allow customers to nominate their own inbound relays, and customer service should not be spouting obvious nonsense such as "the sender should fix their SPF".
-MK
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) www.thinkdesignprint.co.nz skype: don.gould.nz
On 5 April 2017 at 13:57, Don Gould
+1 to Martin this week.
I've got folk getting IRD messages being bounced.
Personally the only thing I really find of use in my mail stack is grey listing, for stopping spam. I've just about stripped the rest out and just let people deal with the noise as they see fit.
I'm actually surprised you are finding greylisting still useful. My experience at a previous posting was that we had to pretty much give up on it as it was causing terrible delays specifically with Google mail. Their mail system would re-send from another IP which meant mail only got through once enough servers were greylisted. We'd whitelist the servers, sure, and then we'd receive complaints about a similarly large company with the same behavior. Not to mention the maintenance required on the whitelist. That coupled with the amount of spamming that actually obeyed greylisting meant it's days were numbered as an effective measure. But oh man, I sure do remember the day we first implemented it - the amount of spam greylisting cut dead in its tracks was astounding. I don't envy anyone still battling against spam. - Damian
LIke others here, I don't find SFP useful and more often than not I find it causes people a headake as no one really understands it properly (my self included) and are often very unwilling to even engage to attempt to fix it.
Even tracking down the mail admin for a company can be time consuming to the point of pointlessness.
D
On 2/04/2017 3:28 PM, Martin Kealey wrote:
On 2 Apr. 2017 12:32, "Glen Eustace"
wrote: I am still of the opinion that SPF is broken but seem to be fairly alone holding that opinion.
Well I somewhat share your opinion.
I don't think that SPF *per-se* is broken, but typical implementations definitely *are* broken.
I do think that applying SPF to *inbound* relays is definitely broken. A service provider should allow customers to nominate their own inbound relays, and customer service should not be spouting obvious nonsense such as "the sender should fix their SPF".
-MK
_______________________________________________ NZNOG mailing listNZNOG(a)list.waikato.ac.nzhttps://list.waikato.ac.nz/mailman/listinfo/nznog
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 <03-348%207235> Mobile: + 64 21 114 0699 <021%20114%200699> Ph: +61 3 9111 1821 <+61%203%209111%201821> (Melb)www.thinkdesignprint.co.nz skype: don.gould.nz
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
On 5/04/2017, at 2:21 PM, Damian Kissick
wrote: Personally the only thing I really find of use in my mail stack is grey listing, for stopping spam. I've just about stripped the rest out and just let people deal with the noise as they see fit.
I'm actually surprised you are finding greylisting still useful.
Our experience matches Don’s. We are still finding greylisting the most effective tool in dealing with spam. I agree that it may not continue to be so but I haven’t seen anything yet that we might use instead. Glen
Hi all,
One very effective but rarely implemented trick is to put in a 1 second delay before the SMTP greeting.
Botnets do not wait for 1 second, they post their whole spam in one shot. Then the mail server says its ready and they've already gone. 1 second is not much of a delay, so no real risk of timeouts.
It's a nice alternative to greylisting. It gets rid of the botnets, which is what greylisting is really for. Greylisting is no use if the spam is coming from a real mail server.
We do use greylisting at Manukau Institute of Technology and it's great. No complaints from the users in almost 6 years.
We do it based on /24 ranges which is less of a problem that unique IPs and we have built up a large database.
We don't bounce based on SPF (unless specified in DMARC policy) as so many people have their SPF records set up incorrectly. We just mark as spam for that.
Best Regards,
Stephan Hughson | Technical Architect
Private Bag 94006, Manukau, Auckland 2241
p: 09 968 7611 | m: 027 568 7611 | w: manukau.ac.nz
________________________________
From: nznog-bounces(a)list.waikato.ac.nz [nznog-bounces(a)list.waikato.ac.nz] on behalf of Glen Eustace [geustace(a)godzone.net.nz]
Sent: Wednesday, 5 April 2017 3:08 p.m.
To: Damian Kissick
Cc: nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] Xtra and SPF
On 5/04/2017, at 2:21 PM, Damian Kissick
botnets now talk proper SMTP, so sadly this catches very, very little these days. Steve On 05/04/17 15:21, Stephan Hughson wrote:
Hi all,
One very effective but rarely implemented trick is to put in a 1 second delay before the SMTP greeting. Botnets do not wait for 1 second, they post their whole spam in one shot. Then the mail server says its ready and they've already gone. 1 second is not much of a delay, so no real risk of timeouts.
It's a nice alternative to greylisting. It gets rid of the botnets, which is what greylisting is really for. Greylisting is no use if the spam is coming from a real mail server.
We do use greylisting at Manukau Institute of Technology and it's great. No complaints from the users in almost 6 years. We do it based on /24 ranges which is less of a problem that unique IPs and we have built up a large database.
We don't bounce based on SPF (unless specified in DMARC policy) as so many people have their SPF records set up incorrectly. We just mark as spam for that.
Best Regards,
Stephan Hughson| Technical Architect Private Bag 94006, Manukau, Auckland 2241 p: 09 968 7611 | m: 027 568 7611 | w: manukau.ac.nz
------------------------------------------------------------------------ *From:* nznog-bounces(a)list.waikato.ac.nz [nznog-bounces(a)list.waikato.ac.nz] on behalf of Glen Eustace [geustace(a)godzone.net.nz] *Sent:* Wednesday, 5 April 2017 3:08 p.m. *To:* Damian Kissick *Cc:* nznog(a)list.waikato.ac.nz *Subject:* Re: [nznog] Xtra and SPF
On 5/04/2017, at 2:21 PM, Damian Kissick
mailto:me(a)damo.net.nz> wrote: Personally the only thing I really find of use in my mail stack is grey listing, for stopping spam. I've just about stripped the rest out and just let people deal with the noise as they see fit.
I'm actually surprised you are finding greylisting still useful.
Our experience matches Don’s. We are still finding greylisting the most effective tool in dealing with spam. I agree that it may not continue to be so but I haven’t seen anything yet that we might use instead.
Glen
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
-- Steve Holdoway BSc(Hons) MIITP https://www.greengecko.co.nz/ Linkedin: https://www.linkedin.com/in/steveholdoway Skype: sholdowa
participants (13)
-
Blair Harrison
-
Brian Gibbons
-
Damian Kissick
-
Don Gould
-
Glen Eustace
-
Jeremy Visser
-
Jo - Mesh|net
-
Jodi Thomson
-
Martin Kealey
-
Nathan Ward
-
Peter Lambrechtsen
-
Stephan Hughson
-
steve