Check the header to this email it is passing through the same Appliance to
get out of my network.
----- Original Message -----
From: "Ben Scott" <mailvor...@gmail.com>
To: "NT System Admin Issues" <ntsysadmin@lyris.sunbelt-software.com>
Sent: Tuesday, September 15, 2009 11:25 AM
Subject: Re: Is this a good SMTP transaction?
On Tue, Sep 15, 2009 at 8:15 AM, David W. McSpadden <dav...@imcu.com>
wrote:
Message 212050 to 3177141...@txt.att.net received remote
SMTP response 'Message received:
20090915111653.udfi13119.atledge02.cingularme....@ironport.imcu.local'.
I don't know jack about IronPort, but the above looks like it might
be a log entry from your MTA (the IronPort, I guess), indicating that
it got a message from the other MTA (whoever the IronPort was talking
to), saying the message was received. (That ID fruitcake looks like
an RFC-822 message ID, but it's different than the one reported
earlier. Perhaps IronPort rewrites message IDs for whatever reason.)
All in all, as a guess, I'd say that's good.
To be sure, set-up a packet sniffer between the IronPort and the
outside world, and watch SMTP traffic.
On Tue, Sep 15, 2009 at 8:30 AM, David W. McSpadden <dav...@imcu.com>
wrote:
But anything coming from my Ironport is failing and it appears
that the Ironport is passing it to AT&T???
It might be that AT&T's system is deciding your message is spam
after accepting it, and then discarding it.
Can you post the full RFC-822 headers of a sample message, given as
they were sent from the IronPort? One way to do that might be to send
the same message to your phone and to some other account that works;
copy the headers from there.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
