On 05/12/2021 09:15, Martin Brown wrote:
> On 02/12/2021 23:39, #Paul wrote:
>> John Rumm <see.my.s...@nowhere.null> wrote:
>>> On 01/12/2021 13:23, Martin Brown wrote:
>>>> You may be better off with a non-ISP email service even if it actually
>>>> costs money. One day they will discontinue providing it.
>>> Even if you use your ISPs email service, its always more sensible to
>>> user your own domain to forward messages to it. That way if it is ever
>>> withdrawn, or turns out to not be good enough, or you simply want to
>>> change ISP, you get to keep your address, and can seamlessly transition
>>> to a new provider.
>> Except, as happened to me and someone else I know, when the
>> forwarding comes in conflict with SPF, and your ISP silently
>> deletes them as "forged". It's quite hard to diagnose why
>> someone isn't getting (e.g.) the password reset emails from
>> amazon when they simply never arrive for no discernable reason,
>> and since you can't log in, you can't change where they get
For some reason Paul's post is not showing up on my server, so I well
Remember that if you own the domain, then you also have control over SPF
and DKIM records. So you should be able to avoid such problems.
You also control the MX records, so don't have to use the domain hosts
email forwarding facilities if you don't want to.
>> I now grab the emails directly from the domain hosting service.
>>  I think the way it "works" - but I am not sure - is that
>> once forwarded, the email can look like it is no longer from
>> the original sender but from the forwarder; thus it looks
>> the forwarder has (might have) forged an email from the original
The forwarder should check the SPF on the incoming mail. If it then
forwards, and chooses to re-write the header, it should make sure it
does so in accordance with its own SPF records.
> SPF is an ill thought out protocol intended to make forgeries more
> difficult but has the unfortunate side effect that poorly configured ISP
> mail servers and accounts belonging to naive not especially tech savvy
> small businesses end up with emails that SPF interprets as forgeries.
In the case of ISPs perhaps. For many small businesses the default SPF
record is usually no SPF record at all - which is far less harmful than
an incorrectly configured one.
The biggest pain IME, is when you have a number of subcontracted
organisations that you want to be able to send mail on your behalf. You
then need a more complicated record that can designate their mail
servers as legitimate senders of mail for your domain. You can soon run
into the maximum length limits of the record itself, or the number of
DNS lookups required to fully resolve it. And that is before you get the
problems of subcontractors changing their email platform hosting
arrangements and not telling you! (or telling you they are changing on a
particular date and then not actually changing them)
> Under some circumstances BT servers can treat emails sent from one sort
> of BT customer to another sort the resulting email fails to pass the
> test. I have seen it and have never been able to pin down why it
> happens. They just vanish into the ether leaving the sender with the
> impression it has gone and the recipient non the wiser.
> It (SPF fails) shows up a lot at this time of year when accountants are
> trying to contact their clients about year end tax and vice versa and
> things sometimes just disappear. If it is time critical it is as well to
> ring and check that it arrived safely since if a server drops it on the
> floor you will not get any kind of warning :(
> Confused the hell out of my accountant last year when something like
> half their clients claimed never to have been reminded. Looking at their
> email headers I could understand why but it took some explaining and I
> told them to just forward my email to their ISP for them to sort it out.
> I'm hoping that this year they won't run into the same brick wall.
> SPF is an unholy bodge.