On Tue, 2011-03-22 at 17:10 +0000, W B Hacker wrote:
> Kebba Foon wrote:
> > my MX is mail.qanet.gm or newgainde.qanet.gm
> >
> > Thanks
> > Kebba
>
> Hard to help find a problem on either of those when you tell us they are
> 'mydomain.com'...
>
> With that cleared up, both are responding to telnet ex Hong Kong.
>
> Page Two:
>
> When you say 'state.gov' are unable to deliver, what have you obfuscated
> there?
>
> - organizations within Gambia?
>
> - Agencies in Africa, The Americas, Asia. Europe, Oceania?
>
> - one or two *specific* senders?
Its the US State Department email servers, its whats the guys from the
embassy use to send mails to some of our clients. its all senders from
that domain
>
> You've said your logs do not show attempted connections.
>
> Suggestion: *temporarily* ('coz it generates a lot of log lines) set:
>
> log_selector = +all
>
> If you know the IP from whence the problematic arrivals jump-off, a grep
> for that IP now and then will turn up evidence of it connecting.
I did an mx lookup for their mail servers and get there ip address and
try to grep them from my mail log. all i get is outgoing mails to
nothing from their servers to my server.
>
> There will then be two PID's, listed in square brackets right after the
> date/time. One for the listener daemon, the second for the child process
> assigned to the connection.
>
> Grep on the child-process PID to drop out all extraneous info and track
> the life of that one connection.
>
> If nothing shows at the same TZ-corrected date/time they have on their
> error messages, a firewall or OTHER MX has intercepted their traffic,
> ELSE they are not finding your current IP in whatever DNS they use.
>
> If you have made a recent DNS entry change, it may simply be a
> propagation/update issue.
the strange thing is that my mx records and set primary mail 5 and
secondary 15 but if i check the logs on the mail on the secondary i
still see mails servers sending mails to it which are further forwarded
to my main mail server.
the two reverse names pointing to the same mx has been there since i
taking the task of maintaining the our mails server it has never been an
issue, but right now i have remove the one that those not point to an
A(forward) record, just to exclude any possible dns issue.
>
> HTH,
>
> Bill
>
>
> >
> > On Tue, 2011-03-22 at 16:32 +0000, W B Hacker wrote:
> >> Kebba Foon wrote:
> >>> Hi List,
> >>>
> >>> I have been having issues with state.gov users not been able to send
> >>> mails to my exim mail server. this is the error message they get when
> >>> they try to send to my server and if i check on the logs i see no
> >>> attempted delivery from their servers. this was the error massage one of
> >>> the state.gov users forwarded to my free yahoo account. anyone enconter
> >>> this kind of problem with exim?
> >>
> >> triligon# telnet mx.mydomain.com smtp
> >> Trying 216.34.94.184...
> >>
> >>
> >> ... long wait. No response.
> >>
> >> Looks as if your mx is offline...
> >>
> >> *yawn*....
> >>
> >> Bill
> >>
> >>>
> >>> ----- Transcript of session follows -----
> >>> 451 4.4.1 reply: read error from mail.mydomain.
> >>> 451 4.4.1 reply: read error from newmail.mydomain
> >>> <**@mydomain>... Deferred: Connection reset by
> >>> newgmail.mydomain
> >>> Warning: message still undelivered after 4 hours Will keep
> >>> trying until
> >>> message is 1 day old
> >>>
> >>> --p2LHIwt6029028-p2LHIwt6029028.1300728611/l.mydomain.com.
> >>> 451 4.4.1 reply: read error from newmydomain.com
> >>> <***@mydomain.com>... Deferred:
> >>> Content-Type: message/delivery-status
> >>>
> >>> Reporting-MTA: dns; l.qanet.gm.
> >>> 451 4.4.1 reply: read error from newmydomain.com
> >>> <****@mydomain.com>... Deferred: Connection reset by
> >>> newmydomain.com
> >>> Warning: message still undelivered after 4 hours Will keep
> >>> trying until
> >>> message is 1 day old on/pdf
> >>> Arrival-Date: Mon, 21 Mar 2011 08:07:13 -0400
> >>>
> >>> Final-Recipient: RFC822; ****@mydomain.com
> >>> Action: delayed
> >>> Status: 4.4.2
> >>> Last-Attempt-Date: Mon, 21 Mar 2011 13:30:11 -0400
> >>> Will-Retry-Until: Tue, 22 Mar 2011 08:07:13 -0400
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
