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/> ~