Dominic Benson wrote:
On 28/03/11 17:31, Dave Evans wrote:
On Mon, Mar 28, 2011 at 05:40:49PM +1100, Sam Walters wrote:
Hi Dave
Thanks for the background info on how to post on this email list.
I didn't notice the http://wiki.exim.org/DontObfuscate
Yes you can probably get some info by looking at it directly: eg: exim
-bh 203.132.28.33 *the misconfigured server in question
I've re-read your emails a few times but I'm afraid I'm still unclear
as to
what problem we're trying to resolve here.
Likewise. I'm going to take a bit of a guess at the problem; tell me if
I'm wrong.
I am assuming that;
* You're working on the mail server for aeroclub-beta.com.au.
* You are working on the machine with IP 203.132.28.33
* You want to send e-mail from [email protected]
* Such e-mail is being rejected by some recipient hosts
Is this correct?
It sounds like you're falling foul of sender verification. Basically, if
you don't accept delivery *to* an address, some users won't accept
delivery *from* it.
If that us indeed the correct sending IP, probably not a [ specific ]
sender verification issue, (they are not common) ...but rather just the
basic server 'credentials'
There is no PTR RR showing up for IP 203.132.28.33
$ host 203.132.28.33
Host 33.28.132.203.in-addr.arpa. not found: 3(NXDOMAIN)
Absent a PTR RR, it doesn't necessarily help traffic acceptability to
have an MX RR.
Whenever the connecting IP has no backpointer to the <domain>.<tld> the
MX or A would be published *for*, any server checking rDNS would reject
'incoming' as a probable forgery.
AFAIK rDNS checking is far more common than sender verification.
Per below, an MX RR is a 'Very Good Idea' for any serious MTA as well.
But a PTR RR OTOH, isn't just a good idea - it is pretty much *essential*.
Needless to say, that presumes a fixed-IP, AND NOT one buried in the
midst of an otherwise-dynamic IP block, ELSE rejection can occur even if
a server is not doing rDNS checks, but IS checking dynamic-IP Remote
Black Lists. Or both...
Aeroclub-beta.com.au has only an A record, resolving to 203.132.28.33.
That is an Exim 4.69 server, (so it seems consistent with what you
describe). That host won't accept delivery for [email protected].
If it should, then you need to configure it to. If it shouldn't, you
need an MX record to point to the host that should. (An MX record
wouldn't hurt in any case, A fallback isn't ideal).
If it does, but info@ isn't one of those, then you should do one of:
a) Accept mail to info
b) Send from a different address
c) Use a different address as the return path (the -f option, if you're
calling from the local machine)
d) Accept, but blackhole mail to info@
There are pros and cons to each of the above. Without more information
as to what you're trying to accomplish, I can't say which would be most
appropriate.
I suggest getting both a PTR RR and an MX RR into your connectivity
provider | IP blockholder DNS.
HTH,
Bill
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
