451 4.4.1 reply: read error |
Post Reply 
|
| Author | |
lyndonje 
Senior Member 
Joined: 31 January 2006 Location: United Kingdom Status: Offline Points: 192 |
 Post Options
 Thanks(0)
 Quote Reply
 Topic: 451 4.4.1 reply: read errorPosted: 08 March 2006 at 5:02am |
|
Hi guys!
A client has contacted my saying one of their clients/suppliers are receiving bounce backs, and has asked me to check out why. I've checked the logs and it doesn't look as though they should/are being blocked, however the emails are failing. The bounce back they receive says: 451 4.4.1 reply: read error from mail.incommingserver.net. <ukorders@domainremoved>... Deferred: Operation timed out with mail.incommingserver.net. In my log I see: 03/01/06 17:28:12:733 -- (2564) Connection from: *ip removed* - Originating country : United States 03/01/06 17:28:13:983 -- (2564) Resolving *ip removed* - *sendinghost.com* 03/01/06 17:28:14:467 -- (2564) - SPF analysis for senderdomain.com done: - none 03/01/06 17:28:14:467 -- (2564) Mail from: usere@senderdomain.com 03/01/06 17:28:21:249 -- (2564) - MAPS search done... 03/01/06 17:28:21:249 -- (2564) RCPT TO: user@receivingdomain.com accepted 03/01/06 17:28:21:249 -- (2564) Disconnect What would cause this? Regards, Lyndon. |
|
 |
|
|
Desperado
Senior Member
Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
Quote Reply
Posted: 08 March 2006 at 12:20pm |
|
Lyndon, 451 4.4.1 reply: read error from mail.incommingserver.net. Looks klike a Sendmail message and is a temp error (400-499) and Sendmail should retry. I would really like to see the message without the modifications so I could actually test the domains. We get these routinely in our systems .... |
|
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
|
|
|
lyndonje
Senior Member
Joined: 31 January 2006 Location: United Kingdom Status: Offline Points: 192 |
Post Options
Thanks(0)
Quote Reply
Posted: 09 March 2006 at 3:28am |
|
Yes, it was a temp error but ultimately the email failed. I've emailed the domains to you.
|
|
|
|
|
christoph
Newbie 
Joined: 19 June 2006 Status: Offline Points: 2 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 June 2006 at 7:40am |
|
Could this be the same? We have a customer who can send emails to a friend (@fsnet.co.uk email address, using AOL as ISP) but the friend's replies keep getting bounced back to her with the following message: The original message was received at Sun, 18 Jun 2006 16:39:25 -0400 Our servers have greylisting installed, so will have asked the AOL proxy to re-send. This has clearly not happened, and it seems as if AOL are refusing to re-send when they face this request for an email address that is not an AOL one (i.e. friend@fsnet.co.uk) Any assistance that anyone might be able to give would be much appreciated so that we can pass this on to the third party. |
|
|
|
|
lyndonje
Senior Member
Joined: 31 January 2006 Location: United Kingdom Status: Offline Points: 192 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 June 2006 at 8:11am |
|
Hi christoph,
If your server is giving a 400 error, which is a temporary error mening the sending server should retry later, and AOL's server's arn't doing this (and you have checked your logs to eliminate an issue with your kit) then AOL arn't re-acting correctly to a 400 error. However, the fact that AOL is waiting for 2 hours before returning the email gives me the impression that they have at least tried to re-send once - I can't see AOL holding NDRs for 2 hours for no reason without retrying. If the recipients email address is fsnet, how does this work? As it must pass through FSNet's servers first before reaching you? In which case how have you implemented the greylisting? I also presume you don't use Spam Filter ISP? |
|
|
|
|
christoph
Newbie
Joined: 19 June 2006 Status: Offline Points: 2 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 June 2006 at 8:26am |
|
Lyndon, Thanks for the response - much appreciated - and sorry if I was not clear. The recipient has an email address on our servers. It is their friend who is using fsnet, and they are nothing to do with us. I think that they are forced to use AOL SMTP for outgoing mail, judging from the error message, and am assuming that the message is therefore not passing through theFSNet's servers? I did see http://forums.devshed.com/mail-server-help-111/451-read-erro r-319188.html which did seem to be very closely aligned to the problem our customer is having, so not sure that the problems are with our logs. We do not use Spam Filter ISP, but I hope that does not mean that you will not be prepared to help?! :-) |
|
|
|
|
lyndonje
Senior Member
Joined: 31 January 2006 Location: United Kingdom Status: Offline Points: 192 |
Post Options
Thanks(0)
Quote Reply
Posted: 19 June 2006 at 9:07am |
|
With you not using Spam Filter ISP, I'm unable to replicate your setup and therefore can only give you limited help.
My first guess is that the 3rd parties server (or Outlook client) is sending the email via port 25, it may be set to deliver direct to recipeints server, or to forward out using FS servers (or another). Regardless of which, AOL are passing all outbound port 25 requests to their SMTP Proxy. And this is the unknown which I think may be causing you problems: 1) Does the AOL SMTP Proxy act as a true proxy - ie does it Proxy your connection to the destination server in real time? Passing back and forth SMTP commands and responses between the sending and receiving servers? or 2) Does the AOL SMTP Proxy act as a middle man, In that the AOL server intercepts the outbound port 25 connection, and accepts the email from the senders sever (issuing them a 2xx code on completion). Then the AOL Proxy tries to connect to your server, which fails and is issued a 4xx error. As the AOL Proxy has limited functionality due to it being a 'proxy' and not a 'full' SMTP server, it may then send the bounce back to sender opposed to retrying. As the senders server is not the one reseiving the 4xx code, it does not know that is must retry the email, and just delivers the bounce back. To fill in a few blanks - does your greylist work on sending IP or senders email? - is the sender sending through their own mail server (Exchange) or mail client (Outlook) If statement 1 above is true, the error is likely to lie with the senders server (assuming the answer to my 2nd 'blank' question above is 'mail server') as it is their server not responding correctly to a 4xx error. Or if it is, and your greylist works based on the same IP re-sending an email, and the external AOL SMTP Proxy IP is different on the second connection then the 1st, then there is your problem. You'll obviously need to check your logs to confirm this. If statement 2 above is true, and AOL are not correctly responding to a 4xx error, then as AOL are unlikely to change anything there is little you can do. Other than blame AOL and suggest the sender uses a more business focused ISP and explain to your customer that AOL do not conform to standards in that it does not retry based on a 4xx error. If however AOL do retry sending the email, but again make the connection from a different external IP (and your greylist works on IP) then its a limitation in your greylist server in that it requires an email to be resent from the same IP, which in this case, and possibly other cases may not be so. In which case I'd see this as a flaw with greylisting unless there is someway to get around this. If this is the case you'll need to seek help from other users of your greylisting software or greylisting groups in general. Regards, Lyndon. |
|
|
|
|
Patricia
Guest Group 
|
Post Options
Thanks(0)
Quote Reply
Posted: 12 July 2006 at 2:14pm |
|
Hi Lyndon, I was reading your post of 08 March 2006, and it seems the same problem i'm having here. Did you find a solution? Here the problem occurs with only one company trying to send emails to us. And it seems the problem happened after we have changed the firewall that was a Sonicwall to a Cisco Pix. They say that they only have problem sending email to us. And we are only having problem receiving emails from them. ----- The following addresses had permanent fatal errors ----- Best regards, Patricia. |
|
|
|
|
Desperado
Senior Member
Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
Quote Reply
Posted: 12 July 2006 at 2:29pm |
|
Patricia, Just for laughs, can you shut off the "Fix-Up" for SMTP on your pix. no fixup protocol smtp 25 And try again? fixup protocol smtp 25 will put it back. |
|
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
|
|
|
Patricia
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 12 July 2006 at 5:11pm |
|
Hi Dan, I looked at the pix configuration and there isn't any "fixup protocol smtp 25", should i still put the "no fixup protocol smtp 25"? I'm not a Pix expert. Another question: my pix is running "PIX Version 7.0(4)" did i still need the configuration? Thanks, Patricia.
|
|
|
|
|
Desperado
Senior Member
Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
Quote Reply
Posted: 13 July 2006 at 8:42am |
|
Patricia, Are you looking at a TFTP'd configuration ... looking at the PDM, or what? Do you see any "Fixup Protocol" statements? You can tell if the fixup is configured by telnetting into the mail server on port 25 from OUTSIDE the Firewall. If you see the server banner, the fixup id off. If you see a bunch od stars instead, it is on. Some mail servers choke on a "fixed up" mail banner ... others do not. Edited by Desperado |
|
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
|
|
|
Patricia
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 14 July 2006 at 9:01am |
|
Hi Dan, It seems like the fix up isn't configured. I did the test with telnet and i saw my server banner. Thank you anyway. It must be another thing, but we tested putting the only firewall and the emails was received correctly. So the problem is really the PIX. But not the fix up configuration. We are still looking for something else. Thanks, Patricia. |
|
|
|
|
Patricia
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 14 July 2006 at 9:04am |
|
Correcting: "putting the only firewall" = "putting the other firewall (Sonicwall)"
|
|
|
|
|
Desperado
Senior Member
Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
Quote Reply
Posted: 14 July 2006 at 11:23am |
|
Patricia, I get tired and type very badly ... as you saw above before I edited the port number. Do you have someone who know the PIX real well? |
|
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
|
|
|
Patricia
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 14 July 2006 at 2:10pm |
|
Dan, No matter... I knew that you typed the wrong port for the SMTP... But i tested the 25 port. We have a company looking at this now... They have Cisco certified people. I think they will try to downgrade the IOS Cisco Version. Thanks any way. Patricia. |
|
|
|
|
Desperado
Senior Member
Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
Quote Reply
Posted: 14 July 2006 at 11:09pm |
|
Patricia, OK ... Good deal. I am also Cisco Certified. That and 2 bucks will get me a Starbucks! Let me know by PM if you still have issues. I have had one or 2 issues with odd smpt handling with PIX but it was usually the way the user set up the translations. |
|
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
|
|
Topic Options|
Post Reply
|
|
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.172 seconds.