Options
Email "delayed", single domain, smtpdiag problems
cnfuzzd
Member Posts: 208
Hi Everyone
Ok. We have a client with problems delivering to one domain (referred to as Problem Domain). The email will sit in the queue forever until a delayed delivery report is generated. This is true for all recipients in that domain. The client's domain is receiving and sending mail from and to all other domains with no known issues. Other domains can send to the problem domain with no issue.
Running SMTPdiag would fail from the client's domain, but succeed from an outside domain. The error message was listed in both smtpdiag and smtp logging:
431+Too+many+recipients+received+this+hour 0 0 42 0 235 SMTP - - - -
Ok, now things get strange. When telneting into the problem domain from the client's domain, you receive this:
220 *********************
At this point you can not enter any smtp commands (ehlo/helo) and you end up disconnecting.
Telneting in from an outside domain gives you the expected 220 <fqdn> response, and you can engage in an smtp session
My thought is that this is a spam filter going rambo on our ip address. Does this sound correct?
Thanks!
John
Ok. We have a client with problems delivering to one domain (referred to as Problem Domain). The email will sit in the queue forever until a delayed delivery report is generated. This is true for all recipients in that domain. The client's domain is receiving and sending mail from and to all other domains with no known issues. Other domains can send to the problem domain with no issue.
Running SMTPdiag would fail from the client's domain, but succeed from an outside domain. The error message was listed in both smtpdiag and smtp logging:
431+Too+many+recipients+received+this+hour 0 0 42 0 235 SMTP - - - -
Ok, now things get strange. When telneting into the problem domain from the client's domain, you receive this:
220 *********************
At this point you can not enter any smtp commands (ehlo/helo) and you end up disconnecting.
Telneting in from an outside domain gives you the expected 220 <fqdn> response, and you can engage in an smtp session
My thought is that this is a spam filter going rambo on our ip address. Does this sound correct?
Thanks!
John
__________________________________________
Work In Progress: BSCI, Sharepoint
Work In Progress: BSCI, Sharepoint
Comments
-
Options
HeroPsycho
Inactive Imported Users Posts: 1,940
cnfuzzd wrote:Ok. We have a client with problems delivering to one domain (referred to as Problem Domain). The email will sit in the queue forever until a delayed delivery report is generated. This is true for all recipients in that domain. The client's domain is receiving and sending mail from and to all other domains with no known issues. Other domains can send to the problem domain with no issue.
Running SMTPdiag would fail from the client's domain, but succeed from an outside domain. The error message was listed in both smtpdiag and smtp logging:
431+Too+many+recipients+received+this+hour 0 0 42 0 235 SMTP - - - -
Most likely reason is the receiving mail system thinks your mail system is a spammer. Check and see if your mail system is on any blacklists. See if the admin of that system can whitelist you. They do this because it delays and clogs your system, so if you were a spammer, it would slow you down.cnfuzzd wrote:When telneting into the problem domain from the client's domain, you receive this:
220 *********************
At this point you can not enter any smtp commands (ehlo/helo) and you end up disconnecting.
Telneting in from an outside domain gives you the expected 220 <fqdn> response, and you can engage in an smtp session
Their system has a PIX with Mailguard enabled. That's par for the course when using telnet.Good luck to all! -
Options
wedge1988
Member Posts: 434 ■■■□□□□□□□
Don't know if this is helpful, but Port 220 is IMAP 3. Hope this is useful.~ wedge1988 ~ IdioT Certified~
MCSE:2003 ~ MCITP:EA ~ CCNP:R&S ~ CCNA:R&S ~ CCNA:Voice ~ Office 2000 MASTER ~ A+ ~ N+ ~ C&G:IT Diploma ~ Ofqual Entry Japanese -
OptionsHeroPsycho
Inactive Imported Users Posts: 1,940
Referred to above is an SMTP response code. IMAP has nothing to do with this.Good luck to all!
-
Options
LOkrasa
Member Posts: 343 ■■■□□□□□□□
This also usually happens with our IP when the other company is using a IronPort appliance. Check your IP on senderbase.org... -
Options
blargoe
Member Posts: 4,174 ■■■■■■■■■□
They're definitely blocking your client for some reason or another. Next step is to contact their IT person.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...