Re: Is this a good SMTP transaction?

[David W. McSpadden]

Thank you.
  - Original Message - 
  From: Michael B. Smith 
  To: NT System Admin Issues 
  Sent: Wednesday, September 23, 2009 5:31 PM
  Subject: RE: Is this a good SMTP transaction?


  yes.

--

  From: David W. McSpadden [dav...@imcu.com]
  Sent: Tuesday, September 15, 2009 8:15 AM
  To: NT System Admin Issues
  Subject: Is this a good SMTP transaction?


Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection 
(ICID 215625) from sender IP 10.0.50.4. Reverse DNS host 
03030611n4m055.imcu.local verified 1.  
15 Sep 2009 07:16:52 (GMT -0400)  (ICID 215625) RELAY sender group 
RELAYLIST match 10.0.50.4 SBRS rfc1918  
15 Sep 2009 07:16:52 (GMT -0400)  Start message 212050 on incoming 
connection (ICID 215625).  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 enqueued on incoming 
connection (ICID 215625) from err...@imcu.com.  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 on incoming connection 
(ICID 215625) added recipient (3177141...@txt.att.net).  
15 Sep 2009 07:16:52 (GMT -0400)  SMTP delivery connection (DCID 
157984) opened from IronPort interface 10.0.10.15 to IP address 66.102.165.114 
on port 25.  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 contains message ID 
header '<03030611n4m055iizih1...@03030611n4m055.imcu.local>'.  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 (825 bytes) from 
err...@imcu.com ready.  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 matched per-recipient 
policy DEFAULT for outbound mail policies.  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 scanned by Anti-Virus 
engine Sophos. Interim verdict: CLEAN  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 scanned by Anti-Virus 
engine. Final verdict: Negative  
15 Sep 2009 07:16:52 (GMT -0400)  Message 212050 queued for delivery.  
15 Sep 2009 07:16:53 (GMT -0400)  (DCID 157984) Delivery started for 
message 212050 to 3177141...@txt.att.net.  
15 Sep 2009 07:16:53 (GMT -0400)  (DCID 157984) Delivery details: 
Message 212050 sent to 3177141...@txt.att.net  
15 Sep 2009 07:16:53 (GMT -0400)  Message 212050 to 
3177141...@txt.att.net received remote SMTP response 'Message received: 
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'.  




 



 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Is this a good SMTP transaction?

[Michael B. Smith]

yes.

From: David W. McSpadden [dav...@imcu.com]
Sent: Tuesday, September 15, 2009 8:15 AM
To: NT System Admin Issues
Subject: Is this a good SMTP transaction?

Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection (ICID 
215625) from sender IP 10.0.50.4. Reverse DNS host 03030611n4m055.imcu.local 
verified 1.
15 Sep 2009 07:16:52 (GMT -0400)(ICID 215625) RELAY sender group 
RELAYLIST match 10.0.50.4 SBRS rfc1918
15 Sep 2009 07:16:52 (GMT -0400)Start message 212050 on incoming 
connection (ICID 215625).
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 enqueued on incoming 
connection (ICID 215625) from err...@imcu.com.
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 on incoming connection 
(ICID 215625) added recipient (3177141...@txt.att.net).
15 Sep 2009 07:16:52 (GMT -0400)SMTP delivery connection (DCID 157984) 
opened from IronPort interface 10.0.10.15 to IP address 66.102.165.114 on port 
25.
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 contains message ID 
header '<03030611n4m055iizih1...@03030611n4m055.imcu.local>'.
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 (825 bytes) from 
err...@imcu.com ready.
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 matched per-recipient 
policy DEFAULT for outbound mail policies.
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 scanned by Anti-Virus 
engine Sophos. Interim verdict: CLEAN
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 scanned by Anti-Virus 
engine. Final verdict: Negative
15 Sep 2009 07:16:52 (GMT -0400)Message 212050 queued for delivery.
15 Sep 2009 07:16:53 (GMT -0400)(DCID 157984) Delivery started for 
message 212050 to 3177141...@txt.att.net.
15 Sep 2009 07:16:53 (GMT -0400)(DCID 157984) Delivery details: Message 
212050 sent to 3177141...@txt.att.net
15 Sep 2009 07:16:53 (GMT -0400)Message 212050 to 
3177141...@txt.att.net received remote SMTP response 'Message received: 
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'.





~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[Ben Scott]

On Mon, Sep 21, 2009 at 9:31 AM, David W. McSpadden  wrote:
> How are you checking the DNS??
> DNStools.net??
> iptools.com???

  I don't like to depend on third-party web sites for this sort of
thing; you can never be sure what they're doing.  I prefer to run
programs on my computer, under my control, asking nameservers I'm sure
about.

  I'm using the "dig" utility.  It's part of the BIND distribution
from ISC (Internet Software Consortium).  BIND is the reference
implementation of DNS.  It's available for both *nix and Windows
computers.  dig is better than nslookup in various ways.  The command
syntax is nicer, you have more features and options, the output format
is more flexible and more useful, it gives more accurate diagnostic
messages, etc.

  That said, even the NSLOOKUP.EXE that comes with Microsoft Windows
can be used; it's just not as nice as dig.  For example:

nslookup -type=TXT imcu.com. pdns1.ultradns.net.

  That will ask the nameserver  what text records
are available for the  domain name.  That nameserver is one
of the authoritative nameservers for the domain.  You can see which
nameservers are being delegated to from the parent:

nslookup -type=NS imcu.com. a.gtld-servers.net.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

thanks

- Original Message - 
From: "Ames Matthew B" 

To: "NT System Admin Issues" 
Sent: Monday, September 21, 2009 9:47 AM
Subject: RE: Is this a good SMTP transaction?


Looks like Ben is using dig.

http://en.wikipedia.org/wiki/Domain_Information_Groper


-Original Message-
From: David W. McSpadden [mailto:dav...@imcu.com]
Sent: 21 September 2009 14:31
To: NT System Admin Issues
Subject: Re: Is this a good SMTP transaction?

How are you checking the DNS??
DNStools.net??
iptools.com???

- Original Message -
From: "Ben Scott" 
To: "NT System Admin Issues" 
Sent: Friday, September 18, 2009 5:27 PM
Subject: Re: Is this a good SMTP transaction?


On Fri, Sep 18, 2009 at 1:05 PM, David W. McSpadden 
wrote:

Specifically my operators cellphones. Seems sometime on Saturday they
updated a rule that any smtp traffic sent to txt.att.net and coming

from

206.18.123.221 was to be accepted and then blackholed.


 FYI, you appear to have a typo in your DNS records:

$ dig +short TXT imcu.com @pdns1.ultradns.net.
"v=spf1 ip4:208.18.123.221 include:fusemail.net include:mailanyone.net
~all"
"v=spf1 include:mailanyone.net include:fusemail.net ~all"
$

 Note that the "ip4" directive starts with 208, but I believe your
public IP address actually starts with 206.  :-)

 Also, I get two TXT records back from your nameserver, as shown
above.  I'm not sure if that's allowed or not, nor what the spec says
to do, but I suspect it will probabbly just confuse things.  I'd
suggest getting rid of the duplicate record.

 Regardless of AT&T brain damage, you *really* want your SPF records
to be correct.  Incorrect SPF records are usually worse than none at
all.  The whole point of SPF is to tell other servers what to accept,
and if you get it wrong, you end up telling other servers to reject
your legitimate mail.


 Now my AT&T rep was glad to tell me that they have a service that

will

fix
it for 9.99 a month per phone.


 The proper answer to that is, "How about you give it to me for free,
and I don't terminate all our accounts with AT&T?"

-- 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/>  ~
The information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  The information in this communication may be
confidential and/or legally privileged.  Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal 
Purchase Order.


For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes.  Any response to this email indicates consent
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.

QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, 
Farnborough, Hampshire, GU14 0LX, United Kingdom

http://www.qinetiq.com/home/notices/legal.html

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

RE: Is this a good SMTP transaction?

[Ames Matthew B]

Looks like Ben is using dig.

http://en.wikipedia.org/wiki/Domain_Information_Groper
 

-Original Message-
From: David W. McSpadden [mailto:dav...@imcu.com] 
Sent: 21 September 2009 14:31
To: NT System Admin Issues
Subject: Re: Is this a good SMTP transaction?

How are you checking the DNS??
DNStools.net??
iptools.com???

- Original Message -
From: "Ben Scott" 
To: "NT System Admin Issues" 
Sent: Friday, September 18, 2009 5:27 PM
Subject: Re: Is this a good SMTP transaction?


On Fri, Sep 18, 2009 at 1:05 PM, David W. McSpadden 
wrote:
> Specifically my operators cellphones. Seems sometime on Saturday they
> updated a rule that any smtp traffic sent to txt.att.net and coming
from
> 206.18.123.221 was to be accepted and then blackholed.

  FYI, you appear to have a typo in your DNS records:

$ dig +short TXT imcu.com @pdns1.ultradns.net.
"v=spf1 ip4:208.18.123.221 include:fusemail.net include:mailanyone.net
~all"
"v=spf1 include:mailanyone.net include:fusemail.net ~all"
$

  Note that the "ip4" directive starts with 208, but I believe your
public IP address actually starts with 206.  :-)

  Also, I get two TXT records back from your nameserver, as shown
above.  I'm not sure if that's allowed or not, nor what the spec says
to do, but I suspect it will probabbly just confuse things.  I'd
suggest getting rid of the duplicate record.

  Regardless of AT&T brain damage, you *really* want your SPF records
to be correct.  Incorrect SPF records are usually worse than none at
all.  The whole point of SPF is to tell other servers what to accept,
and if you get it wrong, you end up telling other servers to reject
your legitimate mail.

>  Now my AT&T rep was glad to tell me that they have a service that
will 
> fix
> it for 9.99 a month per phone.

  The proper answer to that is, "How about you give it to me for free,
and I don't terminate all our accounts with AT&T?"

-- 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/>  ~
The information contained in this E-Mail and any subsequent 
correspondence is private and is intended solely for the intended 
recipient(s).  The information in this communication may be 
confidential and/or legally privileged.  Nothing in this e-mail is 
intended to conclude a contract on behalf of QinetiQ or make QinetiQ 
subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase 
Order.

For those other than the recipient any disclosure, copying, 
distribution, or any action taken or omitted to be taken in reliance 
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be 
monitored and recorded for business purposes including security, audit 
and archival purposes.  Any response to this email indicates consent 
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality 
control, security and other business purposes.

QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, 
Hampshire, GU14 0LX, United Kingdom 
http://www.qinetiq.com/home/notices/legal.html

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

How are you checking the DNS??
DNStools.net??
iptools.com???

- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
Sent: Friday, September 18, 2009 5:27 PM
Subject: Re: Is this a good SMTP transaction?


On Fri, Sep 18, 2009 at 1:05 PM, David W. McSpadden  wrote:

Specifically my operators cellphones. Seems sometime on Saturday they
updated a rule that any smtp traffic sent to txt.att.net and coming from
206.18.123.221 was to be accepted and then blackholed.


 FYI, you appear to have a typo in your DNS records:

$ dig +short TXT imcu.com @pdns1.ultradns.net.
"v=spf1 ip4:208.18.123.221 include:fusemail.net include:mailanyone.net ~all"
"v=spf1 include:mailanyone.net include:fusemail.net ~all"
$

 Note that the "ip4" directive starts with 208, but I believe your
public IP address actually starts with 206.  :-)

 Also, I get two TXT records back from your nameserver, as shown
above.  I'm not sure if that's allowed or not, nor what the spec says
to do, but I suspect it will probabbly just confuse things.  I'd
suggest getting rid of the duplicate record.

 Regardless of AT&T brain damage, you *really* want your SPF records
to be correct.  Incorrect SPF records are usually worse than none at
all.  The whole point of SPF is to tell other servers what to accept,
and if you get it wrong, you end up telling other servers to reject
your legitimate mail.

 Now my AT&T rep was glad to tell me that they have a service that will 
fix

it for 9.99 a month per phone.


 The proper answer to that is, "How about you give it to me for free,
and I don't terminate all our accounts with AT&T?"

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

Re: Is this a good SMTP transaction?

[Ben Scott]

On Fri, Sep 18, 2009 at 1:05 PM, David W. McSpadden  wrote:
> Specifically my operators cellphones.  Seems sometime on Saturday they
> updated a rule that any smtp traffic sent to txt.att.net and  coming from
> 206.18.123.221 was to be accepted and then blackholed.

  FYI, you appear to have a typo in your DNS records:

$ dig +short TXT imcu.com @pdns1.ultradns.net.
"v=spf1 ip4:208.18.123.221 include:fusemail.net include:mailanyone.net ~all"
"v=spf1 include:mailanyone.net include:fusemail.net ~all"
$

  Note that the "ip4" directive starts with 208, but I believe your
public IP address actually starts with 206.  :-)

  Also, I get two TXT records back from your nameserver, as shown
above.  I'm not sure if that's allowed or not, nor what the spec says
to do, but I suspect it will probabbly just confuse things.  I'd
suggest getting rid of the duplicate record.

  Regardless of AT&T brain damage, you *really* want your SPF records
to be correct.  Incorrect SPF records are usually worse than none at
all.  The whole point of SPF is to tell other servers what to accept,
and if you get it wrong, you end up telling other servers to reject
your legitimate mail.

>  Now my AT&T rep was glad to tell me that they have a service that will fix
> it for 9.99 a month per phone.

  The proper answer to that is, "How about you give it to me for free,
and I don't terminate all our accounts with AT&T?"

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[Ben Scott]

On Fri, Sep 18, 2009 at 3:33 PM, Robert Cato  wrote:
> My guess is that many/all telecom companies suffer from this same problem.

  I prefer the shorter version: "All telcos suck".

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[Robert Cato]

I have personally had a couple of bad transactions with Verizon over the
years. I have several friends that work for Verizon and they have serious
integration problems with the numerous acquisitions. My guess is that
many/all telecom companies suffer from this same problem.

On Fri, Sep 18, 2009 at 2:44 PM, Maglinger, Paul wrote:

> I am constantly amazed that AT&T remains in business.  Their
> incompetence is almost legendary.
>
> -Original Message-
> From: David W. McSpadden [mailto:dav...@imcu.com]
> Sent: Friday, September 18, 2009 12:06 PM
> To: NT System Admin Issues
> Subject: Re: Is this a good SMTP transaction?
>
> Turns out it is just smtp traffic to AT&T cellphones.
> Specifically my operators cellphones.  Seems sometime on Saturday they
> updated a rule that any smtp traffic sent to txt.att.net and  coming
> from
> 206.18.123.221 was to be accepted and then blackholed.
>
> Now my AT&T rep was glad to tell me that they have a service that will
> fix
> it for 9.99 a month per phone.
> So now I have an additional $60/month expense for 6 operators to send
> smtp
> traffic to page.att.net from 206.18.123.221.
>
> See everybody's happy
>
> Idiots wouldn't even give me a log entry showing they had received and
> killed my messge.  Just said buy this service or fail to get messages.
>
> I feel diry.
> - Original Message -
> From: "Ben Scott" 
> To: "NT System Admin Issues" 
> Sent: Thursday, September 17, 2009 12:00 PM
> Subject: Re: Is this a good SMTP transaction?
>
>
> On Wed, Sep 16, 2009 at 10:48 AM, David W. McSpadden 
> wrote:
> > Current: v=spf1 include:mailanyone.net include:fusemail.net ~all
> >
> > Proposed v=spf1 include:mailanyone.net include:fusemail.net
> > include:imcu.local ~all ???
>
>  The proposed addition won't work for two reasons:
>
> (1)  is not resolvable in the public DNS, so the rest of
> the world won't be able to query for the needed records.
>
> (2) The  directive means "Include SPF records from this
> other domain", and I'm guessing you haven't published an SPF record in
> your  domain.  :-)
>
>  You'll generally want to specify the IP address(es) mail can come
> from.  Suppose your IronPort's apparent public IP address is
> <192.0.2.42>.  If so, you'd want your SPF record to read:
>
> v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.42 ~all
>
>  Alternatively, if you own the 192.0.2.32 - 192.0.2.63 range, and you
> want any host in that netblock to be able to send mail:
>
> v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.32/26
> ~all
>
>  OpenSPF <http://www.openspf.org/> is useful here.  They publish a
> FAQ, "Common mistakes" list, a formal SPF syntax spec, etc.  I went
> there to double-check my memory of the syntax, for example.  They also
> offer a "Setup Wizard" that may be useful to you:
>
> http://old.openspf.org/wizard.html?mydomain=imcu.com
>
>  The SPF records for the two domains you're including may be useful
> for illustration purposes:
>
> BSCOTT>dig +short mailanyone.net TXT
> "v=spf1  ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"
>
> BSCOTT>dig +short fusemail.net TXT
> "v=spf1 ip4:10.0.5.0/24 ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"
>
>  I note that  is saying mail can come from a subnet of
> 10/8, which is one of the RFC-1918 private blocks.  They shouldn't be
> publishing that on the public net.  While it's unlikely be a big
> problem, it's still a nonsense thing to do, and might potentially let
> some spam through.  You may want to contact them and tell them to fix
> it.
>
>  Hope this helps!
>
> -- 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/>  ~
>
> ~ 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/>  ~

RE: Is this a good SMTP transaction?

[Maglinger, Paul]

I am constantly amazed that AT&T remains in business.  Their
incompetence is almost legendary. 

-Original Message-
From: David W. McSpadden [mailto:dav...@imcu.com] 
Sent: Friday, September 18, 2009 12:06 PM
To: NT System Admin Issues
Subject: Re: Is this a good SMTP transaction?

Turns out it is just smtp traffic to AT&T cellphones.
Specifically my operators cellphones.  Seems sometime on Saturday they 
updated a rule that any smtp traffic sent to txt.att.net and  coming
from 
206.18.123.221 was to be accepted and then blackholed.

Now my AT&T rep was glad to tell me that they have a service that will
fix 
it for 9.99 a month per phone.
So now I have an additional $60/month expense for 6 operators to send
smtp 
traffic to page.att.net from 206.18.123.221.

See everybody's happy

Idiots wouldn't even give me a log entry showing they had received and 
killed my messge.  Just said buy this service or fail to get messages.

I feel diry.
- Original Message - 
From: "Ben Scott" 
To: "NT System Admin Issues" 
Sent: Thursday, September 17, 2009 12:00 PM
Subject: Re: Is this a good SMTP transaction?


On Wed, Sep 16, 2009 at 10:48 AM, David W. McSpadden  
wrote:
> Current: v=spf1 include:mailanyone.net include:fusemail.net ~all
>
> Proposed v=spf1 include:mailanyone.net include:fusemail.net
> include:imcu.local ~all ???

  The proposed addition won't work for two reasons:

(1)  is not resolvable in the public DNS, so the rest of
the world won't be able to query for the needed records.

(2) The  directive means "Include SPF records from this
other domain", and I'm guessing you haven't published an SPF record in
your  domain.  :-)

  You'll generally want to specify the IP address(es) mail can come
from.  Suppose your IronPort's apparent public IP address is
<192.0.2.42>.  If so, you'd want your SPF record to read:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.42 ~all

  Alternatively, if you own the 192.0.2.32 - 192.0.2.63 range, and you
want any host in that netblock to be able to send mail:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.32/26
~all

  OpenSPF <http://www.openspf.org/> is useful here.  They publish a
FAQ, "Common mistakes" list, a formal SPF syntax spec, etc.  I went
there to double-check my memory of the syntax, for example.  They also
offer a "Setup Wizard" that may be useful to you:

http://old.openspf.org/wizard.html?mydomain=imcu.com

  The SPF records for the two domains you're including may be useful
for illustration purposes:

BSCOTT>dig +short mailanyone.net TXT
"v=spf1  ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

BSCOTT>dig +short fusemail.net TXT
"v=spf1 ip4:10.0.5.0/24 ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

  I note that  is saying mail can come from a subnet of
10/8, which is one of the RFC-1918 private blocks.  They shouldn't be
publishing that on the public net.  While it's unlikely be a big
problem, it's still a nonsense thing to do, and might potentially let
some spam through.  You may want to contact them and tell them to fix
it.

  Hope this helps!

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

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Is this a good SMTP transaction?

[Jonathan Link]

IANAL
If another operator is available in your area you should be able to
terminate the contract, since they changed the terms of service on you...

On Fri, Sep 18, 2009 at 1:05 PM, David W. McSpadden  wrote:

> Turns out it is just smtp traffic to AT&T cellphones.
> Specifically my operators cellphones.  Seems sometime on Saturday they
> updated a rule that any smtp traffic sent to txt.att.net and  coming from
> 206.18.123.221 was to be accepted and then blackholed.
>
> Now my AT&T rep was glad to tell me that they have a service that will fix
> it for 9.99 a month per phone.
> So now I have an additional $60/month expense for 6 operators to send smtp
> traffic to page.att.net from 206.18.123.221.
>
> See everybody's happy
>
> Idiots wouldn't even give me a log entry showing they had received and
> killed my messge.  Just said buy this service or fail to get messages.
>
> I feel diry.
> - Original Message - From: "Ben Scott" 
> To: "NT System Admin Issues" 
> Sent: Thursday, September 17, 2009 12:00 PM
> Subject: Re: Is this a good SMTP transaction?
>
>
> On Wed, Sep 16, 2009 at 10:48 AM, David W. McSpadden 
> wrote:
>
>> Current: v=spf1 include:mailanyone.net include:fusemail.net ~all
>>
>> Proposed v=spf1 include:mailanyone.net include:fusemail.net
>> include:imcu.local ~all ???
>>
>
>  The proposed addition won't work for two reasons:
>
> (1)  is not resolvable in the public DNS, so the rest of
> the world won't be able to query for the needed records.
>
> (2) The  directive means "Include SPF records from this
> other domain", and I'm guessing you haven't published an SPF record in
> your  domain.  :-)
>
>  You'll generally want to specify the IP address(es) mail can come
> from.  Suppose your IronPort's apparent public IP address is
> <192.0.2.42>.  If so, you'd want your SPF record to read:
>
> v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.42 ~all
>
>  Alternatively, if you own the 192.0.2.32 - 192.0.2.63 range, and you
> want any host in that netblock to be able to send mail:
>
> v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.32/26 ~all
>
>  OpenSPF <http://www.openspf.org/> is useful here.  They publish a
> FAQ, "Common mistakes" list, a formal SPF syntax spec, etc.  I went
> there to double-check my memory of the syntax, for example.  They also
> offer a "Setup Wizard" that may be useful to you:
>
> http://old.openspf.org/wizard.html?mydomain=imcu.com
>
>  The SPF records for the two domains you're including may be useful
> for illustration purposes:
>
> BSCOTT>dig +short mailanyone.net TXT
> "v=spf1  ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"
>
> BSCOTT>dig +short fusemail.net TXT
> "v=spf1 ip4:10.0.5.0/24 ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"
>
>  I note that  is saying mail can come from a subnet of
> 10/8, which is one of the RFC-1918 private blocks.  They shouldn't be
> publishing that on the public net.  While it's unlikely be a big
> problem, it's still a nonsense thing to do, and might potentially let
> some spam through.  You may want to contact them and tell them to fix
> it.
>
>  Hope this helps!
>
>
> -- 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/>  ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

Turns out it is just smtp traffic to AT&T cellphones.
Specifically my operators cellphones.  Seems sometime on Saturday they 
updated a rule that any smtp traffic sent to txt.att.net and  coming from 
206.18.123.221 was to be accepted and then blackholed.


Now my AT&T rep was glad to tell me that they have a service that will fix 
it for 9.99 a month per phone.
So now I have an additional $60/month expense for 6 operators to send smtp 
traffic to page.att.net from 206.18.123.221.


See everybody's happy

Idiots wouldn't even give me a log entry showing they had received and 
killed my messge.  Just said buy this service or fail to get messages.


I feel diry.
- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
Sent: Thursday, September 17, 2009 12:00 PM
Subject: Re: Is this a good SMTP transaction?


On Wed, Sep 16, 2009 at 10:48 AM, David W. McSpadden  
wrote:

Current: v=spf1 include:mailanyone.net include:fusemail.net ~all

Proposed v=spf1 include:mailanyone.net include:fusemail.net
include:imcu.local ~all ???


 The proposed addition won't work for two reasons:

(1)  is not resolvable in the public DNS, so the rest of
the world won't be able to query for the needed records.

(2) The  directive means "Include SPF records from this
other domain", and I'm guessing you haven't published an SPF record in
your  domain.  :-)

 You'll generally want to specify the IP address(es) mail can come
from.  Suppose your IronPort's apparent public IP address is
<192.0.2.42>.  If so, you'd want your SPF record to read:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.42 ~all

 Alternatively, if you own the 192.0.2.32 - 192.0.2.63 range, and you
want any host in that netblock to be able to send mail:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.32/26 ~all

 OpenSPF <http://www.openspf.org/> is useful here.  They publish a
FAQ, "Common mistakes" list, a formal SPF syntax spec, etc.  I went
there to double-check my memory of the syntax, for example.  They also
offer a "Setup Wizard" that may be useful to you:

http://old.openspf.org/wizard.html?mydomain=imcu.com

 The SPF records for the two domains you're including may be useful
for illustration purposes:

BSCOTT>dig +short mailanyone.net TXT
"v=spf1  ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

BSCOTT>dig +short fusemail.net TXT
"v=spf1 ip4:10.0.5.0/24 ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

 I note that  is saying mail can come from a subnet of
10/8, which is one of the RFC-1918 private blocks.  They shouldn't be
publishing that on the public net.  While it's unlikely be a big
problem, it's still a nonsense thing to do, and might potentially let
some spam through.  You may want to contact them and tell them to fix
it.

 Hope this helps!

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

Re: Is this a good SMTP transaction?

[David W. McSpadden]

Thanks.
Actually the address ends up being the egress point of my firewall for all 
smtp traffic.  So Ironport, Exchange, SQLmail, whatever.  If it is using 
port 25 it is coming out that ip on my firewall.
I appreciate the lecture and education.  The lecture wasn't painful and the 
education was priceless.


- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
Sent: Thursday, September 17, 2009 1:27 PM
Subject: Re: Is this a good SMTP transaction?


On Thu, Sep 17, 2009 at 1:15 PM, David W. McSpadden  wrote:

I need the following added then?

...

spf record  v=spf1 ip4:206.18.123.221 include:fusemail.net
include:mailanyone.net ~all


 If mail coming from the systems you operate (IronPort) will always
originate from IP address 206.18.123.221, that would be correct.  If
you have other hosts that might be sending mail directly, add them,
too.  (An Exchange server, for example.  Maybe your IronPort goes
down, so you reconfigure Exchange to send direct.)


A record mail.imcu.com 206.18.123.221

ptr record 221.123.18.206-in-addr-arpa mail.imcu.com


 That looks good.  Now, SPF doesn't look at A and PTR records unless
you tell it to, so they're not directly relevant for the immediate
problem.  However, it's considered a best practice to have A and PTR
records for mail systems, and some spam systems take that into
account, so it's a good idea to have them.

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

Re: Is this a good SMTP transaction?

[Ben Scott]

On Thu, Sep 17, 2009 at 1:15 PM, David W. McSpadden  wrote:
> I need the following added  then?
...
> spf record  v=spf1 ip4:206.18.123.221 include:fusemail.net
> include:mailanyone.net ~all

  If mail coming from the systems you operate (IronPort) will always
originate from IP address 206.18.123.221, that would be correct.  If
you have other hosts that might be sending mail directly, add them,
too.  (An Exchange server, for example.  Maybe your IronPort goes
down, so you reconfigure Exchange to send direct.)

> A record    mail.imcu.com 206.18.123.221
>
> ptr record  221.123.18.206-in-addr-arpa mail.imcu.com

  That looks good.  Now, SPF doesn't look at A and PTR records unless
you tell it to, so they're not directly relevant for the immediate
problem.  However, it's considered a best practice to have A and PTR
records for mail systems, and some spam systems take that into
account, so it's a good idea to have them.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

I need the following added  then?



A recordmail.imcu.com 206.18.123.221

ptr record  221.123.18.206-in-addr-arpa mail.imcu.com

spf record  v=spf1 ip4:206.18.123.221 include:fusemail.net 
include:mailanyone.net ~all


- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
Sent: Thursday, September 17, 2009 12:00 PM
Subject: Re: Is this a good SMTP transaction?


On Wed, Sep 16, 2009 at 10:48 AM, David W. McSpadden  
wrote:

Current: v=spf1 include:mailanyone.net include:fusemail.net ~all

Proposed v=spf1 include:mailanyone.net include:fusemail.net
include:imcu.local ~all ???


 The proposed addition won't work for two reasons:

(1)  is not resolvable in the public DNS, so the rest of
the world won't be able to query for the needed records.

(2) The  directive means "Include SPF records from this
other domain", and I'm guessing you haven't published an SPF record in
your  domain.  :-)

 You'll generally want to specify the IP address(es) mail can come
from.  Suppose your IronPort's apparent public IP address is
<192.0.2.42>.  If so, you'd want your SPF record to read:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.42 ~all

 Alternatively, if you own the 192.0.2.32 - 192.0.2.63 range, and you
want any host in that netblock to be able to send mail:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.32/26 ~all

 OpenSPF <http://www.openspf.org/> is useful here.  They publish a
FAQ, "Common mistakes" list, a formal SPF syntax spec, etc.  I went
there to double-check my memory of the syntax, for example.  They also
offer a "Setup Wizard" that may be useful to you:

http://old.openspf.org/wizard.html?mydomain=imcu.com

 The SPF records for the two domains you're including may be useful
for illustration purposes:

BSCOTT>dig +short mailanyone.net TXT
"v=spf1  ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

BSCOTT>dig +short fusemail.net TXT
"v=spf1 ip4:10.0.5.0/24 ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

 I note that  is saying mail can come from a subnet of
10/8, which is one of the RFC-1918 private blocks.  They shouldn't be
publishing that on the public net.  While it's unlikely be a big
problem, it's still a nonsense thing to do, and might potentially let
some spam through.  You may want to contact them and tell them to fix
it.

 Hope this helps!

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

Re: Is this a good SMTP transaction?

[Ben Scott]

On Wed, Sep 16, 2009 at 10:48 AM, David W. McSpadden  wrote:
> Current:  v=spf1 include:mailanyone.net include:fusemail.net ~all
>
> Proposed v=spf1 include:mailanyone.net include:fusemail.net
> include:imcu.local ~all ???

  The proposed addition won't work for two reasons:

(1)  is not resolvable in the public DNS, so the rest of
the world won't be able to query for the needed records.

(2) The  directive means "Include SPF records from this
other domain", and I'm guessing you haven't published an SPF record in
your  domain.  :-)

  You'll generally want to specify the IP address(es) mail can come
from.  Suppose your IronPort's apparent public IP address is
<192.0.2.42>.  If so, you'd want your SPF record to read:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.42 ~all

  Alternatively, if you own the 192.0.2.32 - 192.0.2.63 range, and you
want any host in that netblock to be able to send mail:

v=spf1 include:mailanyone.net include:fusemail.net ip4:192.0.2.32/26 
~all

  OpenSPF  is useful here.  They publish a
FAQ, "Common mistakes" list, a formal SPF syntax spec, etc.  I went
there to double-check my memory of the syntax, for example.  They also
offer a "Setup Wizard" that may be useful to you:

http://old.openspf.org/wizard.html?mydomain=imcu.com

  The SPF records for the two domains you're including may be useful
for illustration purposes:

BSCOTT>dig +short mailanyone.net TXT
"v=spf1  ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

BSCOTT>dig +short fusemail.net TXT
"v=spf1 ip4:10.0.5.0/24 ip4:208.101.54.178 ip4:208.70.128.0/21 ~all"

  I note that  is saying mail can come from a subnet of
10/8, which is one of the RFC-1918 private blocks.  They shouldn't be
publishing that on the public net.  While it's unlikely be a big
problem, it's still a nonsense thing to do, and might potentially let
some spam through.  You may want to contact them and tell them to fix
it.

  Hope this helps!

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[Ben Scott]

On Tue, Sep 15, 2009 at 1:03 PM, David W. McSpadden  wrote:
> One from Exchange, through the Ironport, to you.
> One from a Webmail, outside the Ironport, to you.

  After examining the headers, the two different messages appear to
take divergent paths.

  According to Google's mail headers, the message with subject "I sent
one from Exchange"  was relayed through a mail server in domain
"mailanyone.net".  The message with subject "From inside the ironport
to you" appears to have come directly from your IronPort appliance.

  Additionally, your domain  has SPF (Sender Policy
Framework) records which state that your IronPort's apparent public IP
address is *not* an authorized originator of mail.

  Almost certainly, AT&T is taking your SPF records at their word, and
thus ruling the mail coming through the IronPort as spam, and
discarding it.

  Add your IronPort's apparent public IP address to the SPF records
and I bet things will start working again.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

I am sending two.
One from Exchange, through the Ironport, to you.
One from a Webmail, outside the Ironport, to you.
- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
Sent: Tuesday, September 15, 2009 12:29 PM
Subject: Re: Is this a good SMTP transaction?


On Tue, Sep 15, 2009 at 11:37 AM, David W. McSpadden  
wrote:
Check the header to this email it is passing through the same Appliance 
to

get out of my network.


 One of the many problems with Lyris (list server software used by
Sunbelt) is that it mangles headers heavily.  If you want, send a
message to my email address directly.

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

Re: Is this a good SMTP transaction?

[Ben Scott]

On Tue, Sep 15, 2009 at 11:37 AM, David W. McSpadden  wrote:
> Check the header to this email it is passing through the same Appliance to
> get out of my network.

  One of the many problems with Lyris (list server software used by
Sunbelt) is that it mangles headers heavily.  If you want, send a
message to my email address directly.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

Check the header to this email it is passing through the same Appliance to 
get out of my network.


- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
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  
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  
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/>  ~

Re: Is this a good SMTP transaction?

[Ben Scott]

On Tue, Sep 15, 2009 at 8:15 AM, David W. McSpadden  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  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! ~
~   ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

0 bounces.
  - Original Message - 
  From: Fergal O'Connell 
  To: NT System Admin Issues 
  Sent: Tuesday, September 15, 2009 8:56 AM
  Subject: RE: Is this a good SMTP transaction?


  You can ftp to the ironport device and check the bounce queue

   

  From: Steven M. Caesare [mailto:scaes...@caesare.com] 
  Sent: 15 September 2009 13:53
  To: NT System Admin Issues
  Subject: RE: Is this a good SMTP transaction?

   

  Not an IronPort guy, but it sure looks like it's being delivered.

   

  err...@imcu.com is an interesting address.

   

  -sc

   

  From: David W. McSpadden [mailto:dav...@imcu.com] 
  Sent: Tuesday, September 15, 2009 8:30 AM
  To: NT System Admin Issues
  Subject: Re: Is this a good SMTP transaction?

   

  You are correct it is from my Ironport.

  I am just not getting any of these messages to my phone.  I can send from 
other phones.  From Exchange/Outlook or Outlook Express.  But anything coming 
from my Ironport is failing and it appears that the Ironport is passing it to 
AT&T???

- Original Message - 

From: Steven M. Caesare 

To: NT System Admin Issues 

Sent: Tuesday, September 15, 2009 8:17 AM

    Subject: RE: Is this a good SMTP transaction?

 

What is this from?

 

This doesn't appear to be an SMTP conversation, but rather the logs from an 
appliance (IronPort?)

 

-sc

 

From: David W. McSpadden [mailto:dav...@imcu.com] 
Sent: Tuesday, September 15, 2009 8:16 AM
To: NT System Admin Issues
Subject: Is this a good SMTP transaction?

 

  Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection 
(ICID 215625) from sender IP 10.0.50.4. Reverse DNS host 
03030611n4m055.imcu.local verified 1. 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 (ICID 215625) RELAY sender group RELAYLIST match 10.0.50.4 SBRS 
rfc1918 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Start message 212050 on incoming connection (ICID 215625). 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 enqueued on incoming connection (ICID 215625) from 
err...@imcu.com. 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 on incoming connection (ICID 215625) added recipient 
(3177141...@txt.att.net). 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 SMTP delivery connection (DCID 157984) opened from IronPort interface 
10.0.10.15 to IP address 66.102.165.114 on port 25. 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 contains message ID header 
'<03030611n4m055iizih1...@03030611n4m055.imcu.local>'. 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 (825 bytes) from err...@imcu.com ready. 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 matched per-recipient policy DEFAULT for outbound mail 
policies. 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 scanned by Anti-Virus engine Sophos. Interim verdict: 
CLEAN 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 scanned by Anti-Virus engine. Final verdict: Negative 
 
  15 Sep 2009 07:16:52 (GMT -0400) 
 Message 212050 queued for delivery. 
 
  15 Sep 2009 07:16:53 (GMT -0400) 
 (DCID 157984) Delivery started for message 212050 to 
3177141...@txt.att.net. 
 
  15 Sep 2009 07:16:53 (GMT -0400) 
 (DCID 157984) Delivery details: Message 212050 sent to 
3177141...@txt.att.net 
 
  15 Sep 2009 07:16:53 (GMT -0400) 
 Message 212050 to 3177141...@txt.att.net received remote SMTP response 
'Message received: 
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'. 
 

 

  

  

  

 
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.



 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Is this a good SMTP transaction?

[Fergal O'Connell]

You can ftp to the ironport device and check the bounce queue

From: Steven M. Caesare [mailto:scaes...@caesare.com]
Sent: 15 September 2009 13:53
To: NT System Admin Issues
Subject: RE: Is this a good SMTP transaction?

Not an IronPort guy, but it sure looks like it's being delivered.

err...@imcu.com<mailto:err...@imcu.com> is an interesting address...

-sc

From: David W. McSpadden [mailto:dav...@imcu.com]
Sent: Tuesday, September 15, 2009 8:30 AM
To: NT System Admin Issues
Subject: Re: Is this a good SMTP transaction?

You are correct it is from my Ironport.
I am just not getting any of these messages to my phone.  I can send from other 
phones.  From Exchange/Outlook or Outlook Express.  But anything coming from my 
Ironport is failing and it appears that the Ironport is passing it to AT&T???
- Original Message -
From: Steven M. Caesare<mailto:scaes...@caesare.com>
To: NT System Admin Issues<mailto:ntsysadmin@lyris.sunbelt-software.com>
Sent: Tuesday, September 15, 2009 8:17 AM
Subject: RE: Is this a good SMTP transaction?

What is this from?

This doesn't appear to be an SMTP conversation, but rather the logs from an 
appliance (IronPort?)

-sc

From: David W. McSpadden [mailto:dav...@imcu.com]
Sent: Tuesday, September 15, 2009 8:16 AM
To: NT System Admin Issues
Subject: Is this a good SMTP transaction?

Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection (ICID 
215625) from sender IP 10.0.50.4. Reverse DNS host 03030611n4m055.imcu.local 
verified 1.

15 Sep 2009 07:16:52 (GMT -0400)

(ICID 215625) RELAY sender group RELAYLIST match 10.0.50.4 SBRS rfc1918

15 Sep 2009 07:16:52 (GMT -0400)

Start message 212050 on incoming connection (ICID 215625).

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 enqueued on incoming connection (ICID 215625) from 
err...@imcu.com.

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 on incoming connection (ICID 215625) added recipient 
(3177141...@txt.att.net).

15 Sep 2009 07:16:52 (GMT -0400)

SMTP delivery connection (DCID 157984) opened from IronPort interface 
10.0.10.15 to IP address 66.102.165.114 on port 25.

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 contains message ID header 
'<03030611n4m055iizih1...@03030611n4m055.imcu.local>'.

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 (825 bytes) from err...@imcu.com ready.

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 matched per-recipient policy DEFAULT for outbound mail policies.

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 scanned by Anti-Virus engine Sophos. Interim verdict: CLEAN

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 scanned by Anti-Virus engine. Final verdict: Negative

15 Sep 2009 07:16:52 (GMT -0400)

Message 212050 queued for delivery.

15 Sep 2009 07:16:53 (GMT -0400)

(DCID 157984) Delivery started for message 212050 to 3177141...@txt.att.net.

15 Sep 2009 07:16:53 (GMT -0400)

(DCID 157984) Delivery details: Message 212050 sent to 3177141...@txt.att.net

15 Sep 2009 07:16:53 (GMT -0400)

Message 212050 to 3177141...@txt.att.net received remote SMTP response 'Message 
received: 
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'.



















The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Is this a good SMTP transaction?

[Steven M. Caesare]

Not an IronPort guy, but it sure looks like it's being delivered.

 

err...@imcu.com is an interesting address...

 

-sc

 

From: David W. McSpadden [mailto:dav...@imcu.com] 
Sent: Tuesday, September 15, 2009 8:30 AM
To: NT System Admin Issues
Subject: Re: Is this a good SMTP transaction?

 

You are correct it is from my Ironport.

I am just not getting any of these messages to my phone.  I can send
from other phones.  From Exchange/Outlook or Outlook Express.  But
anything coming from my Ironport is failing and it appears that the
Ironport is passing it to AT&T???

- Original Message - 

From: Steven M. Caesare <mailto:scaes...@caesare.com>  

To: NT System Admin Issues
<mailto:ntsysadmin@lyris.sunbelt-software.com>  

Sent: Tuesday, September 15, 2009 8:17 AM

    Subject: RE: Is this a good SMTP transaction?

 

What is this from?

 

This doesn't appear to be an SMTP conversation, but rather the
logs from an appliance (IronPort?)

 

-sc

 

From: David W. McSpadden [mailto:dav...@imcu.com] 
Sent: Tuesday, September 15, 2009 8:16 AM
To: NT System Admin Issues
Subject: Is this a good SMTP transaction?

 

Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection
(ICID 215625) from sender IP 10.0.50.4. Reverse DNS host
03030611n4m055.imcu.local verified 1. 

15 Sep 2009 07:16:52 (GMT -0400) 

(ICID 215625) RELAY sender group RELAYLIST match 10.0.50.4 SBRS rfc1918 

15 Sep 2009 07:16:52 (GMT -0400) 

Start message 212050 on incoming connection (ICID 215625). 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 enqueued on incoming connection (ICID 215625) from
err...@imcu.com. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 on incoming connection (ICID 215625) added recipient
(3177141...@txt.att.net). 

15 Sep 2009 07:16:52 (GMT -0400) 

SMTP delivery connection (DCID 157984) opened from IronPort interface
10.0.10.15 to IP address 66.102.165.114 on port 25. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 contains message ID header
'<03030611n4m055iizih1...@03030611n4m055.imcu.local>'. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 (825 bytes) from err...@imcu.com ready. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 matched per-recipient policy DEFAULT for outbound mail
policies. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 scanned by Anti-Virus engine Sophos. Interim verdict:
CLEAN 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 scanned by Anti-Virus engine. Final verdict: Negative 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 queued for delivery. 

15 Sep 2009 07:16:53 (GMT -0400) 

(DCID 157984) Delivery started for message 212050 to
3177141...@txt.att.net. 

15 Sep 2009 07:16:53 (GMT -0400) 

(DCID 157984) Delivery details: Message 212050 sent to
3177141...@txt.att.net 

15 Sep 2009 07:16:53 (GMT -0400) 

Message 212050 to 3177141...@txt.att.net received remote SMTP response
'Message received:
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'. 

 

 

 

 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Is this a good SMTP transaction?

[David W. McSpadden]

You are correct it is from my Ironport.
I am just not getting any of these messages to my phone.  I can send from other 
phones.  From Exchange/Outlook or Outlook Express.  But anything coming from my 
Ironport is failing and it appears that the Ironport is passing it to AT&T???
  - Original Message - 
  From: Steven M. Caesare 
  To: NT System Admin Issues 
  Sent: Tuesday, September 15, 2009 8:17 AM
  Subject: RE: Is this a good SMTP transaction?


  What is this from?

   

  This doesn't appear to be an SMTP conversation, but rather the logs from an 
appliance (IronPort?)

   

  -sc

   

  From: David W. McSpadden [mailto:dav...@imcu.com] 
  Sent: Tuesday, September 15, 2009 8:16 AM
  To: NT System Admin Issues
  Subject: Is this a good SMTP transaction?

   

Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection 
(ICID 215625) from sender IP 10.0.50.4. Reverse DNS host 
03030611n4m055.imcu.local verified 1. 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   (ICID 215625) RELAY sender group RELAYLIST match 10.0.50.4 SBRS rfc1918 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Start message 212050 on incoming connection (ICID 215625). 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 enqueued on incoming connection (ICID 215625) from 
err...@imcu.com. 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 on incoming connection (ICID 215625) added recipient 
(3177141...@txt.att.net). 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   SMTP delivery connection (DCID 157984) opened from IronPort interface 
10.0.10.15 to IP address 66.102.165.114 on port 25. 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 contains message ID header 
'<03030611n4m055iizih1...@03030611n4m055.imcu.local>'. 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 (825 bytes) from err...@imcu.com ready. 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 matched per-recipient policy DEFAULT for outbound mail 
policies. 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 scanned by Anti-Virus engine Sophos. Interim verdict: 
CLEAN 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 scanned by Anti-Virus engine. Final verdict: Negative 
   
15 Sep 2009 07:16:52 (GMT -0400) 
   Message 212050 queued for delivery. 
   
15 Sep 2009 07:16:53 (GMT -0400) 
   (DCID 157984) Delivery started for message 212050 to 
3177141...@txt.att.net. 
   
15 Sep 2009 07:16:53 (GMT -0400) 
   (DCID 157984) Delivery details: Message 212050 sent to 
3177141...@txt.att.net 
   
15 Sep 2009 07:16:53 (GMT -0400) 
   Message 212050 to 3177141...@txt.att.net received remote SMTP response 
'Message received: 
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'. 
   

   

 


 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Is this a good SMTP transaction?

[Steven M. Caesare]

What is this from?

 

This doesn't appear to be an SMTP conversation, but rather the logs from
an appliance (IronPort?)

 

-sc

 

From: David W. McSpadden [mailto:dav...@imcu.com] 
Sent: Tuesday, September 15, 2009 8:16 AM
To: NT System Admin Issues
Subject: Is this a good SMTP transaction?

 

Protocol SMTP interface Data1 (IP 10.0.10.15) on incoming connection
(ICID 215625) from sender IP 10.0.50.4. Reverse DNS host
03030611n4m055.imcu.local verified 1. 

15 Sep 2009 07:16:52 (GMT -0400) 

(ICID 215625) RELAY sender group RELAYLIST match 10.0.50.4 SBRS rfc1918 

15 Sep 2009 07:16:52 (GMT -0400) 

Start message 212050 on incoming connection (ICID 215625). 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 enqueued on incoming connection (ICID 215625) from
err...@imcu.com. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 on incoming connection (ICID 215625) added recipient
(3177141...@txt.att.net). 

15 Sep 2009 07:16:52 (GMT -0400) 

SMTP delivery connection (DCID 157984) opened from IronPort interface
10.0.10.15 to IP address 66.102.165.114 on port 25. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 contains message ID header
'<03030611n4m055iizih1...@03030611n4m055.imcu.local>'. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 (825 bytes) from err...@imcu.com ready. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 matched per-recipient policy DEFAULT for outbound mail
policies. 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 scanned by Anti-Virus engine Sophos. Interim verdict:
CLEAN 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 scanned by Anti-Virus engine. Final verdict: Negative 

15 Sep 2009 07:16:52 (GMT -0400) 

Message 212050 queued for delivery. 

15 Sep 2009 07:16:53 (GMT -0400) 

(DCID 157984) Delivery started for message 212050 to
3177141...@txt.att.net. 

15 Sep 2009 07:16:53 (GMT -0400) 

(DCID 157984) Delivery details: Message 212050 sent to
3177141...@txt.att.net 

15 Sep 2009 07:16:53 (GMT -0400) 

Message 212050 to 3177141...@txt.att.net received remote SMTP response
'Message received:
20090915111653.udfi13119.atledge02.cingularme@ironport.imcu.local'. 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~