I have received the following guidance from a service provider. Can anyone indicate how this can be safely implemented in hmailserver?

I have tried IPRanges/Incoming Relays/Routes. All without success. I always find the providers server gets a 530 SMTP auth... required


When you send emails via K******, it impersonates you by using your email address as the sender address. This can sometimes cause problems if your domain name is set up with something called SPF.

SPF (Sender Framework Policy) is used to list servers that are allowed to send emails on your behalf. If our servers aren't listed and your SPF records explicitly say noone besides the approved list can send emails from you then emails sent via KashFlow could be regarded as junk.

To get around this, you need to add our servers to the list of servers that are allowed to send emails on your behalf.

The addresses for our mail server is xxx.com (nnn.nnn.nnn.nnn).

Quickbooks Web has the same issue & offered the exact same "advice". The correct fix is for them to send the emails from their domain. The SMTP from does not need to match the From header (and often does not). Or alternatively they should provide a way for you to send the invoices/emails yourself or thru your mail server. The hackish way of doing it is to request that you add their IP(s)/host(s) to your SPF and that's the route they've chosen.

Btw for their 'fix' you don't need to change anything in hmail.. It's done in your SPF string in your TXT record in DNS which is outside of hmail.
Bill

I thought their approach was poor.

Would you share the ipf record?

It is a lame fix for what they are trying to do. I gave a few better options but doubt they'll listen any more than Intuit did on quickbooks.

There is nothing to share about SPF.. It is a public DNS record. You control your domain & the DNS for that domain you just edit your own SPF record then the world knows which servers are 'authorized' senders for your domain.

If you are not familiar with SPF there is a ton online such as:
http://www.openspf.org/
Bill

Just as a transient test I set up an SPF record as:

@ TXT v=spf1 +all

I still got the same 530 result

Grr!

Not all mail servers will honor +all as a matter of fact some will reject all mail from domain with that set.
Bill

The SPF record I have set up is ok...but the issue remains

I wrote a simple diagnostic script and I can see the following behaviour:

1] OnClientConnect
I detect the ip address I'm interested in

Thats it...no more callbacks

But I see the 503 in the log

then
2] OnClientConnect
I detect the ip address I'm interested in

OnAccept etal from the same ip sending me an email detailing the failure in 1]


So my question is: what is going on after the exit of the first OnClientConnect and before the start of the second OCC?
What can I do to configure/manage this behaviour so that I do not send a 503?

Not sure what you're trying to solve.. The original post talks about changing your SPF so that they can send on your behalf which I answered for you. Maybe you need to post a log snippet of an example email to better explain the issue. The SPF change has to do with OTHER PEOPLE accepting email 'from' your domain that is sent by the accounting people on your behalf. It has nothing to do with email coming into your server.. If the issue is the accounting people are cc'ing you for the emails sent to the clients then you'll have issues no matter what SPF is sent to because your server will reject it as a spoofed email. To get around that you need to add 1 or more IP ranges & not require authentication for them. Your logs would show they were being rejeted due to that.
Bill