451 4.4.1 reply: read error
Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=5543
Printed Date: 28 December 2024 at 3:44am
Topic: 451 4.4.1 reply: read error
Posted By: lyndonje
Subject: 451 4.4.1 reply: read error
Date Posted: 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.
|
Replies:
Posted By: Desperado
Date Posted: 08 March 2006 at 12:20pm
|
Lyndon,
451 4.4.1 reply: read error from mail.incommingserver.net.
<ukorders@domainremoved>... Deferred: Operation timed out with
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
|
Posted By: lyndonje
Date 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.
|
Posted By: christoph
Date 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
from smtp-los04.proxy.aol.com [*IP address removed]
----- The following addresses had permanent fatal errors -----
<*email address removed*>
----- Transcript of session follows -----
451 4.4.1 reply: read error from mail.domain.com.
<*email address*>... Deferred: Connection timed out with mail.domain.com.
Message could not be delivered for 2 hours
Message will be deleted from queue
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. mailto: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.
|
Posted By: lyndonje
Date 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?
|
Posted By: christoph
Date 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-error-319188.html - 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?! :-)
|
Posted By: lyndonje
Date 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.
|
Posted By: Guests
Date 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 -----
<paulosilva@domain.com.br>
(reason: 451 4.4.1 reply: read error from server.domain.com.br.)
Transcript of session follows -----
451 4.4.1 reply: read error from server.domain.com.br.
mailto:danieltavares@domain.com.br - danieltavares@domain.com.br . Deferred: Connection timed out with server.domain.com.br.
Message could not be delivered for 4 hours
Message will be deleted from queue
Best regards,
Patricia.
|
Posted By: Desperado
Date 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
|
Posted By: Guests
Date 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.
|
Posted By: Desperado
Date 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.
-------------
The Desperado
Dan Seligmann.
Work: http://www.mags.net
Personal: http://www.desperado.com
|
Posted By: Guests
Date 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.
|
Posted By: Guests
Date Posted: 14 July 2006 at 9:04am
|
Correcting: "putting the only firewall" = "putting the other firewall (Sonicwall)"
|
Posted By: Desperado
Date 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
|
Posted By: Guests
Date 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.
|
Posted By: Desperado
Date 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
|
|