smtp 554 5.7.1 : Relay access denied randomly from outside
hi
we have some problem receiving email from outside.
This is scenario:
- Ms Exchange 2010
- fortimail virtual appliance
- fortigate firewall
we send correctly with SMTP external connector (configured in a right way in SPF record.)
we receive with 3 different mx record, with different priority, based on 3 different internet connection up and running
internal mail is ok
Some external user often receive a :
DELIVERY STATUS NOTIFICATION
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients was aborted after 61 second(s):
* user@mydomain.com
Details:
Diagnostic-Code: smtp; 554 5.7.1 : Relay access denied
This happens:
- from different external sender A,B,C... of different domains
- randomly (if A write two times to user@mydomain.com, one time goes and one time error)
- we rebooted fortimail appliance and internal domain controller for LDAP Auth
- we rebooted ISP connectivity router
Please help, now we don't know how many emails are rejected and this is can be a great problem
Ask me for details, sorry for my english
Really thanks
we have some problem receiving email from outside.
This is scenario:
- Ms Exchange 2010
- fortimail virtual appliance
- fortigate firewall
we send correctly with SMTP external connector (configured in a right way in SPF record.)
we receive with 3 different mx record, with different priority, based on 3 different internet connection up and running
internal mail is ok
Some external user often receive a :
DELIVERY STATUS NOTIFICATION
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients was aborted after 61 second(s):
* user@mydomain.com
Details:
Diagnostic-Code: smtp; 554 5.7.1 : Relay access denied
This happens:
- from different external sender A,B,C... of different domains
- randomly (if A write two times to user@mydomain.com, one time goes and one time error)
- we rebooted fortimail appliance and internal domain controller for LDAP Auth
- we rebooted ISP connectivity router
Please help, now we don't know how many emails are rejected and this is can be a great problem
Ask me for details, sorry for my english
Really thanks
ASKER
Sorry , only to be clear...
we not receive these emails, sent by outside to our domain, so we are the receiving MTA , no?
In attachment status and bodypart, in yellow info i have deleted
Are you talking about these info?
thanks
bodypart.docx
status.docx
we not receive these emails, sent by outside to our domain, so we are the receiving MTA , no?
In attachment status and bodypart, in yellow info i have deleted
Are you talking about these info?
thanks
bodypart.docx
status.docx
My policy is to not open Office documents. There are security issues with macros and other infections.
Could you repost these in Rich Text Format (RTF)?
Could you repost these in Rich Text Format (RTF)?
ASKER
It would appear that there are some fonts on the system that generated this report that are not available on my system. Still, it's early on yet and I'm sure there will be someone on later who can read it.
ASKER
Better to test + know, than guess.
Here's how I'd test this.
1) Stop 2x instances of your MX listeners.
2) Send your mail.
3) If mail send worked as expected, then start another MX + stop current one.
Likely what you'll find is one MX listener is configured slightly different than the others, which is causing the problem.
If you have only one MX running at a time + send all mail to this known MX... likely you can find problem MX listener faster.
Here's how I'd test this.
1) Stop 2x instances of your MX listeners.
2) Send your mail.
3) If mail send worked as expected, then start another MX + stop current one.
Likely what you'll find is one MX listener is configured slightly different than the others, which is causing the problem.
If you have only one MX running at a time + send all mail to this known MX... likely you can find problem MX listener faster.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
which logic use mx assignment?
i have 3 mx
mx1 priority 1
mx2 priority 4
mx3 priority 5
when email is send to mx2? when mx1 in unavailable, busy, timeout....?
now i'll do these test with mx
just changed ldap server for authentication (appliance use two dc. to exclude problem on one dc, we tried using only a dc for 1 hour, thenother dc for other hour. same problem -> 10 mail from outside, 1 not delivered with relay access denied)
i have 3 mx
mx1 priority 1
mx2 priority 4
mx3 priority 5
when email is send to mx2? when mx1 in unavailable, busy, timeout....?
now i'll do these test with mx
just changed ldap server for authentication (appliance use two dc. to exclude problem on one dc, we tried using only a dc for 1 hour, thenother dc for other hour. same problem -> 10 mail from outside, 1 not delivered with relay access denied)
There's also an even easier way to test this.
1) Extract all MX records from DNS.
2) Submit an email to all three MX record using SWAKS at slow submission rate.
3) If single (slow) submissions work, then put the above in a tight loop + see if problem arises under load. Doubtful + might be...
For $MX value, substitute in 3x MX records returned by the first dig.
Oh... One other thing.
Best run dig against all of your NS records to, just to make sure...
1) All NS servers return exactly the same MX record set.
2) All NS server return exactly the same IP when each MX record is resolved.
Start at the absolute beginning. Imagine DNS is wrong/broken + debug every step.
My guess is this is a DNS problem, rather than mail server config problem, so I'd test DNS closely, if you haven't done this yet.
If you require assistance, post your actual domain name + someone can run some of these tests for you.
1) Extract all MX records from DNS.
dig site mx2) Submit an email to all three MX record using SWAKS at slow submission rate.
swaks -tlsc -auth login -s $MX:587 -au $user -ap $pass --from $from -t $to3) If single (slow) submissions work, then put the above in a tight loop + see if problem arises under load. Doubtful + might be...
while : ; do swaks -tlsc -auth login -s $MX:587 -au $user -ap $pass --from $from -t $to ; doneFor $MX value, substitute in 3x MX records returned by the first dig.
Oh... One other thing.
Best run dig against all of your NS records to, just to make sure...
1) All NS servers return exactly the same MX record set.
2) All NS server return exactly the same IP when each MX record is resolved.
Start at the absolute beginning. Imagine DNS is wrong/broken + debug every step.
My guess is this is a DNS problem, rather than mail server config problem, so I'd test DNS closely, if you haven't done this yet.
If you require assistance, post your actual domain name + someone can run some of these tests for you.
ASKER
Problem exist on 2nd and 3rd mx record.
So on 10 email, 9 goes on 1st mx (up and running) and 1 on 2nd or 3rd (down one for a nat problem, one for a device problem)
so telnetting was a rapid solution
So on 10 email, 9 goes on 1st mx (up and running) and 1 on 2nd or 3rd (down one for a nat problem, one for a device problem)
so telnetting was a rapid solution
Deface any usernames, domain names and IP addresses, but leave everything else intact so that we can see where in the delivery process the error is occurring.