Mail blocked if not HTML
in [Postfix]
|
From: Noel Jones on 1 Jul 2010 18:42 On 7/1/2010 4:55 PM, James R. Marcus wrote: > Sorry I didn't post them before I was just trying to do a > sanity check. Here they are: > > --------------- > Postfix Logs > --------------- > Jun 23 16:48:10 relay0 postfix/smtp[30504]: 5ED4F114BBC: > to=<sales(a)2co.com <mailto:sales(a)2co.com>>, > relay=mail.2co.com[64.128.185.221]:25, delay=0.98, > delays=0.01/0.01/0.33/0.62, dsn=4.4.2, status=deferred (lost > connection with mail.2co.com[64.128.185.221] while sending end > of data -- message may > Jun 23 18:02:08 relay0 postfix/smtp[1638]: 5ED4F114BBC: > enabling PIX <CRLF>.<CRLF> workaround for > mail.2co.com[64.128.185.221]:25 > Jun 23 18:02:18 relay0 postfix/smtp[1638]: 5ED4F114BBC: > to=<sales(a)2co.com <mailto:sales(a)2co.com>>, > relay=mail.2co.com[64.128.185.221]:25, delay=4449, > delays=4438/0.03/0.34/10, dsn=4.4.2, status=deferred (lost > connection with mail.2co.com[64.128.185.221] while sending end > of data -- message may be deferred - message can't be received now, please try later. lost connection - the other end disconnected in the middle of the conversation. Is it just this one host that's deferring your mail? Did the recipient get the mail anyway? Does the mail eventually get delivered? Have you confirmed the user's claim that only plain-text mail is deferred? Have you contacted the postmaster of 64.128.185.221? If you can deliver to other hosts OK, the problem is at 64.128.185.221. > > ---------- > The Bounce > ---------- > Diagnostic information for administrators: > > Generating server: relay0.edhance.com <http://relay0.edhance.com> > > sales(a)2co.com <mailto:sales(a)2co.com> > #< #4.4.2 X-Postfix; lost connection with > mail.2co.com[64.128.185.221] while sending end of data -- > message may be sent more than once> #SMTP# > This isn't a bounce notice; it's a "message delayed" notice. The mail was not rejected; the connection was lost during transmission. Postfix will continue trying to deliver the mail until the queue file expires; typically 5 days. As the notice says, the mail *might* have been delivered to the recipient, but your local sever can't tell because the remote end disconnected while -- Noel Jones
From: "James R. Marcus" on 1 Jul 2010 18:50 Yes. Well actually an ASA 5520 James On Jul 1, 2010, at 6:34 PM, Ralf Hildebrandt wrote: * James R. Marcus <jmarcus(a)edhance.com<mailto:jmarcus(a)edhance.com>>: Sorry I didn't post them before I was just trying to do a sanity check. Here they are: --------------- Postfix Logs --------------- Jun 23 16:48:10 relay0 postfix/smtp[30504]: 5ED4F114BBC: to=<sales(a)2co.com<mailto:sales(a)2co.com>>, relay=mail.2co.com[64.128.185.221]:25, delay=0.98, delays=0.01/0.01/0.33/0.62, dsn=4.4.2, status=deferred (lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may Jun 23 18:02:08 relay0 postfix/smtp[1638]: 5ED4F114BBC: enabling PIX <CRLF>..<CRLF> workaround for mail.2co.com[64.128.185.221]:25 Jun 23 18:02:18 relay0 postfix/smtp[1638]: 5ED4F114BBC: to=<sales(a)2co.com<mailto:sales(a)2co.com>>, relay=mail.2co.com[64.128.185.221]:25, delay=4449, delays=4438/0.03/0.34/10, dsn=4.4.2, status=deferred (lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may be Jun 23 19:25:27 relay0 postfix/smtp[3204]: 5ED4F114BBC: enabling PIX <CRLF>..<CRLF> workaround for mail.2co.com[64.128.185.221]:25 Jun 23 19:25:37 relay0 postfix/smtp[3204]: 5ED4F114BBC: to=<sales(a)2co.com<mailto:sales(a)2co.com>>, relay=mail.2co.com[64.128.185.221]:25, delay=9448, delays=9438/0.02/0.08/10, dsn=4.4.2, status=deferred (lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may be Jun 23 22:12:08 relay0 postfix/smtp[6277]: 5ED4F114BBC: enabling PIX <CRLF>..<CRLF> workaround for mail.2co.com[64.128.185.221]:25 Jun 23 22:12:18 relay0 postfix/smtp[6277]: 5ED4F114BBC: to=<sales(a)2co.com<mailto:sales(a)2co.com>>, relay=mail.2co.com[64.128.185.221]:25, delay=19449, delays=19438/0.09/0.22/10, dsn=4.4.2, status=deferred (lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may b Is the CISCO PIX in your organization? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt(a)charite.de<mailto:ralf.hildebrandt(a)charite.de> | http://www.charite.de :: James R. Marcus | Director, IT Operations :: Edhance | jmarcus(a)edhance.com<x-msg://103/jmarcus(a)edhance.com> :: v: 617-475-5360 | m: 914-772-8533 :: web: www.edhance.com<http://www.edhance.com/>
From: Matt Hayes on 1 Jul 2010 18:50 On 07/01/2010 05:55 PM, James R. Marcus wrote: > Sorry I didn't post them before I was just trying to do a sanity check. > Here they are: > > --------------- > Postfix Logs > --------------- > Jun 23 16:48:10 relay0 postfix/smtp[30504]: 5ED4F114BBC: > to=<sales(a)2co.com <mailto:sales(a)2co.com>>, > relay=mail.2co.com[64.128.185.221]:25, delay=0.98, > delays=0.01/0.01/0.33/0.62, dsn=4.4.2, status=deferred (lost connection > with mail.2co.com[64.128.185.221] while sending end of data -- message may > Jun 23 18:02:08 relay0 postfix/smtp[1638]: 5ED4F114BBC: enabling PIX > <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 > Jun 23 18:02:18 relay0 postfix/smtp[1638]: 5ED4F114BBC: > to=<sales(a)2co.com <mailto:sales(a)2co.com>>, > relay=mail.2co.com[64.128.185.221]:25, delay=4449, > delays=4438/0.03/0.34/10, dsn=4.4.2, status=deferred (lost connection > with mail.2co.com[64.128.185.221] while sending end of data -- message > may be > Jun 23 19:25:27 relay0 postfix/smtp[3204]: 5ED4F114BBC: enabling PIX > <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 > Jun 23 19:25:37 relay0 postfix/smtp[3204]: 5ED4F114BBC: > to=<sales(a)2co.com <mailto:sales(a)2co.com>>, > relay=mail.2co.com[64.128.185.221]:25, delay=9448, > delays=9438/0.02/0.08/10, dsn=4.4.2, status=deferred (lost connection > with mail.2co.com[64.128.185.221] while sending end of data -- message > may be > Jun 23 22:12:08 relay0 postfix/smtp[6277]: 5ED4F114BBC: enabling PIX > <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 > Jun 23 22:12:18 relay0 postfix/smtp[6277]: 5ED4F114BBC: > to=<sales(a)2co.com <mailto:sales(a)2co.com>>, > relay=mail.2co.com[64.128.185.221]:25, delay=19449, > delays=19438/0.09/0.22/10, dsn=4.4.2, status=deferred (lost connection > with mail.2co.com[64.128.185.221] while sending end of data -- message may b > They have a PIX.. tell them to turn off fixup protocol in the PIX and it should be good to go. -Matt
From: Matt Hayes on 1 Jul 2010 18:51 On 07/01/2010 06:50 PM, James R. Marcus wrote: > Yes. Well actually an ASA 5520 > > James > > > On Jul 1, 2010, at 6:34 PM, Ralf Hildebrandt wrote: > >> * James R. Marcus <jmarcus(a)edhance.com <mailto:jmarcus(a)edhance.com>>: >>> Sorry I didn't post them before I was just trying to do a sanity >>> check. Here they are: >>> >>> --------------- >>> Postfix Logs >>> --------------- >>> Jun 23 16:48:10 relay0 postfix/smtp[30504]: 5ED4F114BBC: >>> to=<sales(a)2co.com<mailto:sales(a)2co.com>>, >>> relay=mail.2co.com[64.128.185.221]:25, delay=0.98, >>> delays=0.01/0.01/0.33/0.62, dsn=4.4.2, status=deferred (lost >>> connection with mail.2co.com[64.128.185.221] while sending end of >>> data -- message may >>> Jun 23 18:02:08 relay0 postfix/smtp[1638]: 5ED4F114BBC: enabling PIX >>> <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 >>> Jun 23 18:02:18 relay0 postfix/smtp[1638]: 5ED4F114BBC: >>> to=<sales(a)2co.com<mailto:sales(a)2co.com>>, >>> relay=mail.2co.com[64.128.185.221]:25, delay=4449, >>> delays=4438/0.03/0.34/10, dsn=4.4.2, status=deferred (lost connection >>> with mail.2co.com[64.128.185.221] while sending end of data -- >>> message may be >>> Jun 23 19:25:27 relay0 postfix/smtp[3204]: 5ED4F114BBC: enabling PIX >>> <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 >>> Jun 23 19:25:37 relay0 postfix/smtp[3204]: 5ED4F114BBC: >>> to=<sales(a)2co.com<mailto:sales(a)2co.com>>, >>> relay=mail.2co.com[64.128.185.221]:25, delay=9448, >>> delays=9438/0.02/0.08/10, dsn=4.4.2, status=deferred (lost connection >>> with mail.2co.com[64.128.185.221] while sending end of data -- >>> message may be >>> Jun 23 22:12:08 relay0 postfix/smtp[6277]: 5ED4F114BBC: enabling PIX >>> <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 >>> Jun 23 22:12:18 relay0 postfix/smtp[6277]: 5ED4F114BBC: >>> to=<sales(a)2co.com<mailto:sales(a)2co.com>>, >>> relay=mail.2co.com[64.128.185.221]:25, delay=19449, >>> delays=19438/0.09/0.22/10, dsn=4.4.2, status=deferred (lost >>> connection with mail.2co.com[64.128.185.221] while sending end of >>> data -- message may b >> >> Is the CISCO PIX in your organization? >> >> -- >> Ralf Hildebrandt >> Geschäftsbereich IT | Abteilung Netzwerk >> Charité - Universitätsmedizin Berlin >> Campus Benjamin Franklin >> Hindenburgdamm 30 | D-12203 Berlin >> Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 >> ralf.hildebrandt(a)charite.de <mailto:ralf.hildebrandt(a)charite.de> | >> http://www.charite.de >> > > > > :: James R. Marcus | Director, IT Operations > :: Edhance | jmarcus(a)edhance.com <x-msg://103/jmarcus(a)edhance.com> > :: v: 617-475-5360 | m: 914-772-8533 > :: web: www.edhance.com <http://www.edhance.com/> > ASA: config t no inspect smtp -Matt
From: "James R. Marcus" on 1 Jul 2010 18:54 No it is not just one host it is many. I have tried to confirm the users claim, and although he is a reliable source, I wasn't able to replicate the issue. The recipient did not get the email anyway, as far as I know. There was no response, and in this case it was a customer service request. I have contacted Postmasters about this issue, not many have responded. The most interesting response I got was one asking if we made a connection, did something (which would cause a delay) and then tried to send the email. It seems to me any preprocessing of email is done before the connection is opened. James On Jul 1, 2010, at 6:42 PM, Noel Jones wrote: On 7/1/2010 4:55 PM, James R. Marcus wrote: Sorry I didn't post them before I was just trying to do a sanity check. Here they are: --------------- Postfix Logs --------------- Jun 23 16:48:10 relay0 postfix/smtp[30504]: 5ED4F114BBC: to=<sales(a)2co.com<mailto:sales(a)2co.com> <mailto:sales(a)2co.com>>, relay=mail.2co.com[64.128.185.221]:25, delay=0.98, delays=0.01/0.01/0.33/0.62, dsn=4.4.2, status=deferred (lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may Jun 23 18:02:08 relay0 postfix/smtp[1638]: 5ED4F114BBC: enabling PIX <CRLF>.<CRLF> workaround for mail.2co.com[64.128.185.221]:25 Jun 23 18:02:18 relay0 postfix/smtp[1638]: 5ED4F114BBC: to=<sales(a)2co.com<mailto:sales(a)2co.com> <mailto:sales(a)2co.com>>, relay=mail.2co.com[64.128.185.221]:25, delay=4449, delays=4438/0.03/0.34/10, dsn=4.4.2, status=deferred (lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may be deferred - message can't be received now, please try later. lost connection - the other end disconnected in the middle of the conversation. Is it just this one host that's deferring your mail? Did the recipient get the mail anyway? Does the mail eventually get delivered? Have you confirmed the user's claim that only plain-text mail is deferred? Have you contacted the postmaster of 64.128.185.221? If you can deliver to other hosts OK, the problem is at 64.128.185.221. ---------- The Bounce ---------- Diagnostic information for administrators: Generating server: relay0.edhance.com<http://relay0.edhance.com> <http://relay0.edhance.com> sales(a)2co.com<mailto:sales(a)2co.com> <mailto:sales(a)2co.com> #< #4.4.2 X-Postfix; lost connection with mail.2co.com[64.128.185.221] while sending end of data -- message may be sent more than once> #SMTP# This isn't a bounce notice; it's a "message delayed" notice. The mail was not rejected; the connection was lost during transmission. Postfix will continue trying to deliver the mail until the queue file expires; typically 5 days. As the notice says, the mail *might* have been delivered to the recipient, but your local sever can't tell because the remote end disconnected while -- Noel Jones :: James R. Marcus | Director, IT Operations :: Edhance | jmarcus(a)edhance.com<x-msg://103/jmarcus(a)edhance.com> :: v: 617-475-5360 | m: 914-772-8533 :: web: www.edhance.com<http://www.edhance.com/>
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: header_checks REJECT Next: System Command on Client Restriction Rejection |