Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


SOLVED Mail error after sending message: "Mail from domain '<example.com>' is not allowed from your host"

Support
Log in to reply
  • d19dotca

    Hello,

    I believe this may be an expected error due to some setting somewhere that is likely trying to prevent a loop, but it's not working as expected in my case.

    I can reproduce the issue easily. Here is how:

    1. Setup an icloud.com email account, for example.

    2. Setup new external email account to forward to an email on a domain where the domain email is hosted on the Cloudron server (i.e. test@icloud.com account set to forward incoming mail to dustin@example.com where example.com is hosted on Cloudron server)

    3. Send email from the domain hosted on Cloudron server to external email account

    4. See failure message of "Mail from domain '<example.com>' is not allowed from your host"

    This is unfortunately causing issues, because I have two new clients which are wanting to basically forward all of their emails from previous domain to new domain where only the new domain is hosted and controlled on Cloudron server, and it works for most incoming mail just fine but email sent from colleagues on same domain who send to old domain causes this issue to happen and so messages fail to deliver in that use-case.

    Hopefully the above makes sense. If there's anything I can do to clarify, please let me know. Is this a setting I need to set somewhere, or is this something that should be improved for future versions to be a tad less aggressive in what I assume is set to prevent loops from domain to domain? Any help would be greatly appreciated as this is causing issues. I have not encountered this before in previous mail products to my knowledge, although I can't say I've necessarily had this use-case either.

    0
  • girish
    Staff

    @d19dotca Is this with 4.3? (We added some code in 4.3 to resolve aliases in lists, which I think you reported earlier in a forum post).

    d19dotca 1 Reply 0
  • d19dotca

    @girish This is confirmed in 4.3.2, however I think this was actually reported to me many months ago when I started using Cloudron and I just never got around to validating it or fixing it until it was brought up again recently. So I’m not certain if it has to do with the recent changes made for aliases.

    0
  • girish
    Staff

    @d19dotca Ah, I misread your post. I think what's happening is that iCloud.com does not support SRS. What this means is that when forwarding email (from say A to icloud), it is forwarding email pretending to be the original mail address i.e it declares itself in the MAIL FROM to be A.

    Cloudron sees that it is "spoofing" address A because icloud is not listed in the SPF record of A and it rejects the email. This is a good article about how SPF breaks forwarding in general.

    In your case, iCloud sends an email with the MAIL FROM set to an address which is on Cloudron itself. It sees that as a spam/spoof and rejects it. The behavior is correct but of course it doesn't help you with your problem.

    A fix is to add the icloud servers to the domain A's SPF record. Does icloud list the servers from which it sends mail? Alternately, you can make the current SPF record very permissive. By default, Cloudron will setup the SPF record to only allow the Cloudron server itself.

    d19dotca 1 Reply 0
  • girish
    Staff 

    $ host -t TXT icloud.com
icloud.com descriptive text "google-site-verification=knAEOH4QxR29I4gjRkpkvmUmP2AA7WrDk8Kq0wu9g9o"
icloud.com descriptive text "v=spf1 ip4:17.36.0.0/16 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.110.0.0/15 ip4:17.111.110.0/23 ip4:17.120.0.0/16 ip4:17.133.0.0/16 ip4:17.139.0.0/16 ip4:17.142.0.0/15 ip4:17.151.1.0/24" " ip4:17.158.0.0/15 ip4:17.162.0.0/15 ip4:17.164.0.0/16 ip4:17.171.37.0/24 ip4:17.172.0.0/16 ip4:17.179.168.0/23 ~all"

    Adding the above to example.com's SPF maybe is a start.

    d19dotca 1 Reply 0
  • d19dotca

    @girish Ah okay, I think that makes sense. So ultimately it seems this is due to my SPF records, where I need to just allow a few other domains that my clients use so that it isn’t seen as spoofed when it arrives at my server. That makes sense to me. I’ll try to fix this up later tonight or tomorrow and see if it helps. Will report back. Thanks again for all the help.

    0
  • d19dotca

    @girish Just wanted to say that this resolved the issue. Thank you! 🙂 So to clarify, this was not a Cloudron issue but a simple DNS issue for the SPF records.

    0