Re: [exim] [new to exim] exim server not sending host namea…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] [new to exim] exim server not sending host nameandfailing verification.
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 info@???
> * 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 info@???.
>
> 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