Solaris 8 - Configuring sendmail relay (NoAuth inbound -> SSL outbound)

Dave.Anderson-NOSPAM

unread,

May 14, 2008, 12:20:38 PM5/14/08

to

NOTE: This post is condensed from a thread elsewhere where I was
getting help with som of the basic issues, but we seem to have hit a
wall with SMTP/SSL -- that individual had some good info for me, on
basic sendmail setup so I'm grateful for having made as much progress
as I have.. Hopefully someone here knows how to get me the rest of the
way over the hump.

Also I should mention that I have a bit more than a decade of UNIX
experience, but sendmail is one pice that I don't understand very
well.

I have been happily chugging away for the past 5 years with my Solaris
8 server on my home network, using sendmail 8.11.7+Sun for a variety
of purposes: scraping financial websites and emailing mashups to
myself & friends, developing/testing cgi scripts for websites that
need to email form data, etc.

Recently my ISP decided that I must use SSL/Auth to send mail through
their SMTP server(smtp.att.yahoo.com). In addition to breaking my
sendmail implementation, it has broken a number of important Wintel
utilities, notably my APC Powerchute Business Edition email
notifications, my 3ware RAID controller email notifications, and
others. I have contacted tech support for each of the products that
I'm having this problem with as well as my ISP and the collective
response is a shrug of the shoulders.

What this boils down to is, I have two problems I need to solve:

1) I need to get sendmail working again for non-interactive sessions
as shown in the perl code snippet attached to this post.
2) Contingent on (1), I would like to be able to use the Solaris box
to relay notification emails from the Wintel box. I do not need to
have the Solaris box handle all of my outbound mail(e.g. Thunderbird),
just the outbound email from applications that do not support SSL/
Auth.

Regarding (1), it seems that the obvious starting point would be to
yank the Sun sendmail out by the roots and set up sendmail 8.14.3, but
from my reading on the subject it seems that I will need to install
OpenSSL and possibly BerkelyDB to meet the prerequisites for compiling
sendmail with SSL support. Links to details on this would be much
appreciated, especially any info pertaining to steps I need to take to
pave the way to solving problem (2) above. (UPDATE: *Done*)

Regarding (2), all of the info I've been able to dig up on SMTP/SSL
relay configuration assumes that the user wants the client to make an
SSL connection to the relay. That's not what I want. What I need is to
have my client applications send their mail to the relay on the
Solaris box with NO authentication(I suppose I need to set up an SMTP
server of some flavor) and have that mail relayed to my ISP's SMTP
server using SSL and user/pass authentication (again, this needs to be
non-interactive).

Note that security is not the highest priority here; these machines
all sit behind a router with built-in firewall/NAT and are essentially
invisible to the internet at large(as far as I can tell with grc.com
ShieldsUP). So long as it's reasonably secure, that's fine; I don't
have to worry about port scans, spammers, etc.
1: #!/usr/bin/perl -T
2: .
3: .
4: .
5: open MAIL, "| /usr/lib/sendmail -t -F'$from_name' -
f'$from_email'"
6: or die "Could not open sendmail: $!";
7: print MAIL <<END_OF_HEADER;
8: To: $email
9: Reply-to: $from_email
10: Subject: $sub
11: $type_string
12: END_OF_HEADER
13: open(FILE, "< ./reports/$rpt_file.$type")
14: or die "Couldn't open $rpt_file.$type for reading:
$!\n";
15: while (<FILE>) {
16: chomp($_);
17: print MAIL "$_\n";
18: }
19: close(FILE);
20: if($type_string) {
21: print MAIL end_html();
22: }
23: close MAIL or die "Error closing sendmail: $!";
24: print "<li>Sent $sub.</li><br>\n";
25: }

========================================================================

To reiterate:

1) My clients need to be able to talk to an SMTP server on my local
Solaris box, without authentication/SSL.
2) My Solaris box then needs to be able to forward that mail to my
ISP's SMTP server using SSL, port 465, with user/pass auth. I have no
control over this whatsoever, and it is a hard requirement.

Also, I do not need to control access to sendmail. My firewall is
secure enough that plain old SMTP/Port 25 will not present a security
risk, and this machine will never live in the DMZ. If the machine ever
does get compromised, I can just restore from one of my periodic
backups that I make to a spare drive using dd. It is a development
machine after all, so I tend to be prepared for the worst. :)

===============================================================================
Well, things went pretty smoothly for a while, up until I actually
started trying to compile sendmail. To be more precise, I was fine up
until the "sh ./Build" mentioned in step 3 of the INSTALL file. I am
working with 8.14.2 as you recommended.

First off, when I copy and pasted your site.config.m4 contents into a
terminal window, it replaced some of the quote characters with ^Y and
removed others. I carefully replaced them, always using ` on the left
side of a quoted string and ' on the right side of a quoted string. I
corrected the path to BerkelyDB and the path to openssl. The ssl lines
in this file are seemingly being ignored(see Build output below
site.m4.config below.

I tried modifying sendmail.h line 125 from openssl/ssl.h to /usr/local/
ssl/include/openssl/ssl.h and Build returned page upon page of errors
for my efforts, so I changed it back. Any thoughts as to why my second
confINCDIRS directive is being ignored? I have a hunch that is the
root of the problem.

I have to run off to work soon, at minimum I will back up site config
file, delete everything and untar the source again. I may have run
build from the top level directory before setting up site config and
maybe there is something screwy that Build can't overwrite.
1: APPENDDEF(`confLIBDIRS', `-L/usr/local/BerkeleyDB.4.2/lib')
2: APPENDDEF(`confINCDIRS', `-I/usr/local/BerkeleyDB.4.2/include')
3: APPENDDEF(`confENVDEF', `-DNEWDB')
4: define(`confSTDIO_TYPE', `portable')
5: APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -DHASURANDOMDEV')
6: APPENDDEF(`confLIBDIRS', `-L/usr/local/ssl/lib')
7: APPENDDEF(`confINCDIRS'; `-I/usr/local/ssl/include')
8: APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
9: APPENDDEF(`conf_sendmail_ENVDEF',`-DMILTER')
10: APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_MILTER_ROOT_UNSAFE')
11: Result -- ssl include path seems to be ignored:
12: # time sh ./Build
13: Configuration: pfx=, os=SunOS, rel=5.8, rbase=5, rroot=5.8,
arch=sun4, sfx=, variant=optimized
14: Making in /export/home/swinst/sendmail.Mar.08/install/
sendmail-8.14.2/obj.SunOS.5.8.sun4/sendmail
15: gcc -O -I. -I../../include -I/usr/local/BerkeleyDB.4.2/include -
DNEWDB -DNDBM -DNIS -DNISPLUS -DMAP
16: _REGEX -DSOLARIS=20800 -DNETINET6 -DNEWDB -DSTARTTLS -
DHASURANDOMDEV -DMILTER -c -o main.o main.
17: c
18: In file included from main.c:15:
19: ./sendmail.h:125:27: openssl/ssl.h: No such file or directory
20: In file included from main.c:15:
21: ./sendmail.h:694: error: syntax error before "SSL"
22: ./sendmail.h:694: warning: no semicolon at end of struct or union
23: ./sendmail.h:697: error: syntax error before '}' token
24: ./sendmail.h:1451: error: field `sv_mci' has incomplete type
25: ./sendmail.h:1876: error: syntax error before '*' token
26: ./sendmail.h:1880: error: syntax error before '*' token
27: ./sendmail.h:1881: error: syntax error before '*' token
28: ./sendmail.h:2614: error: syntax error before '*' token
29: make: *** [main.o] Error 1
30: real 0m3.24s
31: user 0m2.79s
32: sys 0m0.27s
33: #

============================================================================
OK, made some progress. Untarred the release to start from scratch,
ended up adding the following two lines to Makefile to get it to build
without errors:

INCDIRS= -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/include
LIBDIRS= -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/ssl/lib

However, I get the following in my Apache error_log when I try to run
a script that uses sendmail as shownin my script example above:

ld.so.1: sendmail: fatal: libssl.so.0.9.8: open failed: No such file
or directory

This is odd, since libssl.so.0.9.8 exists in the lib path mentioned
above, and I did not see any errors about it during the build.
========================================================================
I've also expanded LD_LIBRARY_PATH in /etc/skel with the following:

export LD_LIBRARY_PATH=/usr/lib:/usr/local/ssl/lib

I put the same in S90apachectl at the top of the file.

After trying to restart apache, then rebooting, still no joy.

=====================================================================
1: May 10 08:10:20 ultra sendmail[639]: [ID 801593 mail.info]
m4AFAKOr000639: Authentication-Warning: ultra.myfake.net: nobody set
sender to feed...@lavaggioprima.com using -f
2: May 10 08:10:20 ultra sendmail[639]: [ID 801593 mail.info]
m4AFAKOr000639: from=feed...@lavaggioprima.com, size=80, class=0,
nrcpts=1, msgid=<200805101510....@ultra.myfake.net>,
relay=nobody@localhost
3: May 10 08:10:21 ultra sendmail[640]: [ID 801593 mail.info]
m4AFAKGA000640: from=<feed...@lavaggioprima.com>, size=453, class=0,
nrcpts=1, msgid=<200805101510....@ultra.myfake.net>,
proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
4: May 10 08:10:21 ultra sendmail[639]: [ID 801593 mail.info]
m4AFAKOr000639: to=sa...@lavaggioprima.com,
ctladdr=feed...@lavaggioprima.com (60001/60001), delay=00:00:01,
xdelay=00:00:01, mailer=relay, pri=30080, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (m4AFAKGA000640 Message accepted for
delivery)
5: May 10 08:10:21 ultra sendmail[642]: [ID 801593 mail.info]
m4AFAKGA000640: to=<sa...@lavaggioprima.com>, delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=120453, relay=smtp.att.yahoo.com
[69.147.64.31], dsn=5.0.0, stat=Service unavailable
6: May 10 08:10:21 ultra sendmail[642]: [ID 801593 mail.info]
m4AFAKGA000640: m4AFALGA000642: DSN: Service unavailable
7: May 10 08:10:21 ultra sendmail[642]: [ID 801593 mail.info]
m4AFALGA000642: to=<feed...@lavaggioprima.com>, delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=31678, relay=smtp.att.yahoo.com,
dsn=4.0.0, stat=Deferred: Connection reset by smtp.att.yahoo.com
8: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.info]
m4AFALGA000642: to=<feed...@lavaggioprima.com>, delay=00:00:04,
xdelay=00:00:00, mailer=relay, pri=121678, relay=smtp.att.yahoo.com
[69.147.64.31], dsn=5.0.0, stat=Service unavailable
9: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.crit]
m4AFALGA000642: SYSERR(root): hash map "Alias0": missing map file /etc/
mail/aliases.db: No such file or directory
10: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.info]
m4AFALGA000642: m4AFAPGB000643: return to sender: hash map "Alias0":
missing map file /etc/mail/aliases.db: No such file or directory
11: May 10 08:10:25 ultra sendmail[644]: [ID 801593 mail.info]
m4AFAPGB000643: Warning: program /usr/lib/mail.local unsafe: No such
file or directory
12: May 10 08:10:25 ultra sendmail[644]: [ID 801593 mail.crit]
m4AFAPGB000643: SYSERR(root): Cannot exec /usr/lib/mail.local: No such
file or directory
13: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.error]
m4AFAPGB000643: smtpquit: mailer local exited with exit value 71
14: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.info]
m4AFAPGB000643: to=root, delay=00:00:00, xdelay=00:00:00,
mailer=local, pri=33558, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local
15: May 10 08:10:25 ultra sendmail[645]: [ID 801593 mail.info]
m4AEbNB6000389: Warning: program /usr/lib/mail.local unsafe: No such
file or directory
16: May 10 08:10:25 ultra sendmail[645]: [ID 801593 mail.crit]
m4AEbNB6000389: SYSERR(root): Cannot exec /usr/lib/mail.local: No such
file or directory
17: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.error]
m4AEbNB6000389: smtpquit: mailer local exited with exit value 71
18: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.info]
m4AEbNB6000389: to=root, delay=00:33:01, xdelay=00:00:00,
mailer=local, pri=3003558, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local
19: May 10 08:10:25 ultra sendmail[646]: [ID 801593 mail.info]
m4AEZdE5000367: Warning: program /usr/lib/mail.local unsafe: No such
file or directory
20: May 10 08:10:25 ultra sendmail[646]: [ID 801593 mail.crit]
m4AEZdE5000367: SYSERR(root): Cannot exec /usr/lib/mail.local: No such
file or directory
21: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.error]
m4AEZdE5000367: smtpquit: mailer local exited with exit value 71
22: May 10 08:10:25 ultra sendmail[643]: [ID 801593 mail.info]
m4AEZdE5000367: to=root, delay=00:34:45, xdelay=00:00:00,
mailer=local, pri=3183555, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local

==============================================================================

I have recompiled sendmail with SASL support per the instructions
here:

http://www.brandonhutchinson.com/Installing_Cyrus_SASL_with_sendmail_on_Solaris.html

I have added further entries to sendmail.mc:

divert(0)dnl
VERSIONID(`$Id: sendmail.mc,v 8.13 2008/05/29 11:46:30 Dave Exp $')
OSTYPE(solaris8)dnl
DOMAIN(generic)dnl
define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl
FEATURE(`access_db')dnl
MAILER(local)dnl
MAILER(smtp)dnl
define(`SMART_HOST', `smtp.att.yahoo.com')dnl
define(`confPRIVACY_FLAGS', `authwarnings,goaway')dnl
define(`STATUS_FILE', `/etc/mail/statistics')dnl
define(`confHOST_STATUS_DIRECTORY', `/etc/mail/host_status')dnl

I have added the following line to /etc/mail/access, and ran "makemap
hash /etc/mail/access.db < /etc/mail/access"

ro...@ultra.myfake.net RELAY

I have populated /etc/mail/auhinfo as follows:

# cat authinfo
AuthInfo:smtp.att.yahoo.com "U:<user...@pacbell.net>"
"P:<MyPassword>" "M:DIGEST-MD5"
#

Here is some verbose output from sendmail:

# /usr/lib/sendmail -v root <local-host-names
root... Connecting to [127.0.0.1] via relay...
220 ultra.myfake.net ESMTP Sendmail 8.14.2/8.14.2; Wed, 14 May 2008
07:09:16 -0700 (PDT)
>>> EHLO ultra.myfake.net
250-ultra.myfake.net Hello localhost [127.0.0.1], pleased to meet you
250 ENHANCEDSTATUSCODES
>>> MAIL From:<ro...@ultra.myfake.net>
550 5.7.1 Access denied
root... Using cached ESMTP connection to [127.0.0.1] via relay...
>>> RSET
250 2.0.0 Reset state
>>> MAIL From:<>
550 5.7.1 Access denied
postmaster... Using cached ESMTP connection to [127.0.0.1] via
relay...
>>> RSET
250 2.0.0 Reset state
>>> MAIL From:<>
550 5.7.1 Access denied
May 14 07:09:16 ultra sendmail[5209]: [ID 801593 mail.alert]
m4EE9GmE005209: Losing ./qfm4EE9GmE005209: savemail panic
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 ultra.myfake.net closing connection

I seem to be able to connect to the sendmail/SMTP daemon OK, which is
promising:

220 ultra.myfake.net ESMTP Sendmail 8.14.2/8.14.2; Wed, 14 May 2008
09:12:34 -0700 (PDT)
helo ultra
250 ultra.myfake.net Hello Flash [192.168.69.68], pleased to meet you
quit
221 2.0.0 ultra.myfake.net closing connection

So, I'm learning, bit by bit -- it seems that the local mail problem
needs to be solved first, since local delivery seems to be the first
step in relaying the outbound mail.

Note that I changed LOCAL_MAILER_PATH after following up on the
mail.local messages above and finding that there are a whole list of
caveats if I want to use mail.local -- the README stated that I would
have to perform a whole slew of additional steps to get that to work,
so I'm trying to stick with the existing /etc/mail.

********************************************************

So, apologies if the above seems disjointed. I tried to just pull the
most relevant info from the earlier thread. I will be happy to post
any additional info or run other experiments to aid the process of
troubleshooting this. I can't be the only one that suddenly needs to
relay to an SMTP server that requires SSL.

TIA,

Dave A.

Rob MacGregor

unread,

May 14, 2008, 3:52:03 PM5/14/08

to

Dave.Anderson-NOSPAM unleashed the infinite monkeys on 14/05/2008 17:20
producing:
<---SNIP--->

>
> Recently my ISP decided that I must use SSL/Auth to send mail through
> their SMTP server(smtp.att.yahoo.com). In addition to breaking my
> sendmail implementation, it has broken a number of important Wintel
> utilities, notably my APC Powerchute Business Edition email
> notifications, my 3ware RAID controller email notifications, and
> others. I have contacted tech support for each of the products that
> I'm having this problem with as well as my ISP and the collective
> response is a shrug of the shoulders.
>
> What this boils down to is, I have two problems I need to solve:
>
> 1) I need to get sendmail working again for non-interactive sessions
> as shown in the perl code snippet attached to this post.
> 2) Contingent on (1), I would like to be able to use the Solaris box
> to relay notification emails from the Wintel box. I do not need to
> have the Solaris box handle all of my outbound mail(e.g. Thunderbird),
> just the outbound email from applications that do not support SSL/
> Auth.

<---SNIP--->

I read your posting at speed, so I may have missed something, however...

You may find that the remote mail server is expecting either PLAIN or
LOGIN, rather than DIGEST-MD5. ISTR that LOGIN isn't configured by
default with Cyrus SASL and you have to enable it explicitly at
configure time.

I don't see anything showing your attempts to connect to the ISP after
you included SASL though. I don't think it would have worked anyway as
you haven't included the authinfo feature from what I could see:

http://www.sendmail.org/~ca/email/auth.html

Finally, I'm pretty sure the MAILER lines should be the last lines in
the .mc file.

--
Rob MacGregor (BOFH)

Rule 37: "There is no 'overkill'. There is only 'open fire'
and 'I need to reload.'"

Per Hedeland

unread,

May 14, 2008, 4:55:36 PM5/14/08

to

In article
<f1ab3acd-06b8-43aa...@q27g2000prf.googlegroups.com>

"Dave.Anderson-NOSPAM" <dave.and...@gmail.com> writes:
>
>2) My Solaris box then needs to be able to forward that mail to my
>ISP's SMTP server using SSL, port 465, with user/pass auth. I have no
>control over this whatsoever, and it is a hard requirement.

Are you *sure* that that is the *only* form of SSL access they support?
SMTP "wrapped in" SSL a.k.a. SMTPS on port 465 is non-standard and
generally frowned upon. The standard way to use SSL with SMTP is via
STARTTLS on the normal port 25. This is the most important question for
you, since sendmail has no client-side support for SMTPS (server-side it
supports both STARTTLS and SMTPS, the latter for the benefit of stupid
MUAs that can't do STARTTLS) - no amount of upgrading and rebuilding it
will get it to appear. There is a solution to this, but you don't want
to go there if you don't have to.

--Per Hedeland
p...@hedeland.org

Dave.Anderson-NOSPAM

unread,

May 16, 2008, 11:05:16 AM5/16/08

to

On May 14, 1:55 pm, p...@hedeland.org (Per Hedeland) wrote:
> In article
> <f1ab3acd-06b8-43aa-9ab6-c0fd7d483...@q27g2000prf.googlegroups.com>

>
> "Dave.Anderson-NOSPAM" <dave.anderson...@gmail.com> writes:
>
> >2) My Solaris box then needs to be able to forward that mail to my

> >ISP'sSMTPserver usingSSL, port 465, with user/pass auth. I have no

> >control over this whatsoever, and it is a hard requirement.
>

> Are you *sure* that that is the *only* form ofSSLaccess they support?SMTP"wrapped in"SSLa.k.a. SMTPS on port 465 is non-standard and
> generally frowned upon. The standard way to useSSLwithSMTPis via

> STARTTLS on the normal port 25. This is the most important question for
> you, since sendmail has no client-side support for SMTPS (server-side it
> supports both STARTTLS and SMTPS, the latter for the benefit of stupid
> MUAs that can't do STARTTLS) - no amount of upgrading and rebuilding it
> will get it to appear. There is a solution to this, but you don't want
> to go there if you don't have to.
>
> --Per Hedeland
> p...@hedeland.org

Maybe I am misinterpreting what is laid out here:
http://helpme.att.net/article.php?item=10918

SSL is a requirement. The specific auth mechanism I am unsure of, but
if I don't have my username/password correctly entered, mail doesn't
get sent. I can find some time to look into this over the weekend,
perhaps a Wireshark capture would clarify matters -- I'm not sure what
to look for in the capture, but will see if anything jumps out at me
and post what seems relevant.

Per Hedeland

unread,

May 16, 2008, 3:45:11 PM5/16/08

to

In article
<778a7697-e80a-4dfc...@k10g2000prm.googlegroups.com>

"Dave.Anderson-NOSPAM" <dave.and...@gmail.com> writes:
>On May 14, 1:55 pm, p...@hedeland.org (Per Hedeland) wrote:
>>
>> Are you *sure* that that is the *only* form ofSSLaccess they
>support?SMTP"wrapped in"SSLa.k.a. SMTPS on port 465 is non-standard and
>> generally frowned upon. The standard way to useSSLwithSMTPis via
>> STARTTLS on the normal port 25. This is the most important question for
>> you, since sendmail has no client-side support for SMTPS (server-side it
>> supports both STARTTLS and SMTPS, the latter for the benefit of stupid
>> MUAs that can't do STARTTLS) - no amount of upgrading and rebuilding it
>> will get it to appear. There is a solution to this, but you don't want
>> to go there if you don't have to.

How "interesting" to have two different threads about the same subject
going in parallell, one with a person that digs up everything I asked
for and way more and tries out and reports all kinds of things, another
with a person that just throws up his arms and doesn't even read what I
wrote...

>Maybe I am misinterpreting what is laid out here:
>http://helpme.att.net/article.php?item=10918

That page asks me to log in with my AT&T email username, of which I have
none, and otherwise provides zero information.

>SSL is a requirement.

Yes, but as I wrote above it can be achieved in two different ways, one
non-standard that isn't supported by sendmail, one standard that is.
Your first mission is to find out whether your ISP supports the latter.
There are a couple of ways to go about it (none of them foolproof):

1) Ask your ISP.
2) Read carefully through the information provided by the ISP.
3) telnet to port 25 on your SMTP server, enter EHLO, and look for
STARTTLS in the response.
4) Same as 3) but using port 587.

>The specific auth mechanism I am unsure of, but
>if I don't have my username/password correctly entered, mail doesn't
>get sent.

Although it's possible to use SSL/TLS for authentication, I'd say it's
unheard of in the area of end-user SMTP connections to ISP servers. If
SSL/TLS is required, you need to get that going before you even attempt
authentication.

--Per Hedeland
p...@hedeland.org

rea...@newsguy.com

unread,

May 16, 2008, 6:57:04 PM5/16/08

to

"Dave.Anderson-NOSPAM" <dave.and...@gmail.com> writes:

> SSL is a requirement. The specific auth mechanism I am unsure of, but
> if I don't have my username/password correctly entered, mail doesn't
> get sent. I can find some time to look into this over the weekend,

Per has already mentioned telnetting to port 25 and port 587. What did
you get there? If it showed STARTTLS you may be in good shape.

You may like a little tool I just learned about called swaks
(swiss army knife smtp)

I just used gentoo linux portage setup to install it but on solaris
you may need to google up a suitable package or build from source.

Telnet should tell the story but if you want a nifty little tool that
will give a bit more info try swaks.

Be sure to aim telnet or swaks at port 587 on the server. I just
found out with Per H's prompting that on a cable (comcast) ISP that
the normal sendmail with compiled in ssl STARTTLS support works when I
was thinking I needed to do exactly what you are thinking about;
cobbling up some kind of stunnel or other ssl wrapper to talk to part
465 that will be no fun to maintain.

All it really took was a line Per posted in:
Message-ID: <g0kmsb$2ddp$1...@hedeland.org>
that makes sendmail contact the smarthost on port 587.

My isp had been ok with plain authentication until just a couple weeks
ago and guess who my isp was just before I switched to comcast
... ATT. Up until about 2 mnths ago and again plain password auth was
ok with them then.

So I'm thinking some of the big players in the ISP field may be doing
the same kind of things on there mail servers... If your problems
arose quite recently ... that seems even more likely.

Dave.Anderson-NOSPAM

unread,

May 16, 2008, 8:25:13 PM5/16/08

to

On May 14, 12:52 pm, Rob MacGregor <m...@privacy.net> wrote:
> Dave.Anderson-NOSPAM unleashed the infinite monkeys on 14/05/2008 17:20
> producing:
> <---SNIP--->
>
>
>
> > Recently my ISP decided that I must useSSL/Auth to send mail through

> > theirSMTPserver(smtp.att.yahoo.com). In addition to breaking my

Thanks Rob, this is info that I had not run across in my earlier
efforts. If, in the context of other information that is coming to
light in this thread, it makes sense to try these things I will do so
soonest.

Dave.Anderson-NOSPAM

unread,

May 16, 2008, 8:27:18 PM5/16/08

to

Well, I do appreciate your help, and I don't mean to come across as
"throwing up my hands". If anything, I meant to come across as:

-Someone who is NOT in any way an expert with sendmail/SMTP/etc
-Someone who is fiddling with this in what tiny amount of free time he
has.
-Someone who can't get a straight answer out of AT&T about anything,
all they do is refer me to that link and tell me those are the only
supported clients.
-Someone who was trying to tell you where he got the idea that he
needded SSL to send mail, though he really needed to get out the door
to work and did not have time to try ANYTHING at that moment.
-Someone who just has a minute to post now, then has a PILE if honey-
dos to attend to before digging more deeply into this -- at that, my
brother who is visiting the area from out-of-town may come in the door
at any minute and soak up any time I might spend solving this problem.
-Someone who also can't get a straight answer out of AT&T as to what
news server they provide, so instead of setting up a proper newsreader
is using Google groups(BTW this means I have no idea how, in this UI,
I would find the message that you appear to be giving me a pointer
to).

Look, I work in software QA(NOT on SMTP) and I know full well that
more needs to be done to characterize the problem. I laid out what had
been done before and I am willing to try anything to move this
forward, but please be patient with the fact that I have many higher
priorities on my plate. I will do any tests/experiments that
kowledgeable experts might suggest,

Your first and only question was, "Are you *sure* that that is the
*only* form of SSL access they support?" and I answered with a link
that contains all I know about what they do or do not allow. You did
not *ask* me anything else whatsoever, so I don't understand your
implication that I did not read what you wrote.

Now, regarding the portion of your post that contained useful
troubleshooting experiments, here are the results --

1) As mentioned above, the ISP only points me to that link, and tells
me that the only supported methods of sending mail through them are
the clients mentioned at that link, and pages lnked there. OK, I wnent
and looked at that link with IE instead of my usual browser, and I see
why you said "zero information". I have pasted in the content of the
page I was referring to at the bottom of this post, since I realize
now that you can't see it. You will note that even if you had been
able to see the page, it essentiall offers no useful information.

2) The info provided by the ISP is sparse and useless IMHO.

3/4) Looking for STARTTLS from server:

$ telnet smtp.att.yahoo.com 25
Trying 69.147.64.31...
Connected to smtp.sbc.mail.yahoo4.akadns.net.
Escape character is '^]'.
220 smtp120.sbc.mail.sp1.yahoo.com ESMTP
EHLO
250-smtp120.sbc.mail.sp1.yahoo.com
250-AUTH LOGIN PLAIN XYMCOOKIE
250-PIPELINING
250 8BITMIME

$ telnet smtp.att.yahoo.com 587
Trying 69.147.64.31...
Connected to smtp.sbc.mail.yahoo4.akadns.net.
Escape character is '^]'.
220 smtp118.sbc.mail.sp1.yahoo.com ESMTP
EHLO
250-smtp118.sbc.mail.sp1.yahoo.com
250-AUTH LOGIN PLAIN XYMCOOKIE
250-PIPELINING
250 8BITMIME

And, just for grins:

$ telnet smtp.att.yahoo.com 465
Trying 69.147.64.31...
Connected to smtp.sbc.mail.yahoo4.akadns.net.
Escape character is '^]'.
EHLO
Connection closed by foreign host.
$

I will work on this at the best pace I am able, given my priorities/
obligations elsewhere. Thank you for your help.

Regards,

Dave A.

On May 16, 12:45 pm, p...@hedeland.org (Per Hedeland) wrote:
> In article
> <778a7697-e80a-4dfc-8f60-415377ded...@k10g2000prm.googlegroups.com>

>
> "Dave.Anderson-NOSPAM" <dave.anderson...@gmail.com> writes:
> >On May 14, 1:55 pm, p...@hedeland.org (Per Hedeland) wrote:
>
> >> Are you *sure* that that is the *only* form ofSSLaccess they
> >support?SMTP"wrapped in"SSLa.k.a. SMTPS on port 465 is non-standard and
> >> generally frowned upon. The standard way to useSSLwithSMTPis via
> >> STARTTLS on the normal port 25. This is the most important question for
> >> you, since sendmail has no client-side support for SMTPS (server-side it
> >> supports both STARTTLS and SMTPS, the latter for the benefit of stupid
> >> MUAs that can't do STARTTLS) - no amount of upgrading and rebuilding it
> >> will get it to appear. There is a solution to this, but you don't want
> >> to go there if you don't have to.
>
> How "interesting" to have two different threads about the same subject
> going in parallell, one with a person that digs up everything I asked
> for and way more and tries out and reports all kinds of things, another
> with a person that just throws up his arms and doesn't even read what I
> wrote...
>
> >Maybe I am misinterpreting what is laid out here:
> >http://helpme.att.net/article.php?item=10918
>
> That page asks me to log in with my AT&T email username, of which I have
> none, and otherwise provides zero information.
>

> >SSLis a requirement.

>
> Yes, but as I wrote above it can be achieved in two different ways, one
> non-standard that isn't supported by sendmail, one standard that is.
> Your first mission is to find out whether your ISP supports the latter.
> There are a couple of ways to go about it (none of them foolproof):
>
> 1) Ask your ISP.
> 2) Read carefully through the information provided by the ISP.

> 3) telnet to port 25 on yourSMTPserver, enter EHLO, and look for

> STARTTLS in the response.
> 4) Same as 3) but using port 587.
>
> >The specific auth mechanism I am unsure of, but
> >if I don't have my username/password correctly entered, mail doesn't
> >get sent.
>

> Although it's possible to useSSL/TLS for authentication, I'd say it's
> unheard of in the area of end-userSMTPconnections to ISP servers. IfSSL/TLS is required, you need to get that going before you even attempt
> authentication.
>
> --Per Hedeland
> p...@hedeland.org

Dave.Anderson-NOSPAM

unread,

May 16, 2008, 8:33:56 PM5/16/08

to

On May 16, 3:57 pm, rea...@newsguy.com wrote:
> "Dave.Anderson-NOSPAM" <dave.anderson...@gmail.com> writes:
> >SSLis a requirement. The specific auth mechanism I am unsure of, but

> > if I don't have my username/password correctly entered, mail doesn't
> > get sent. I can find some time to look into this over the weekend,
>
> Per has already mentioned telnetting to port 25 and port 587. What did
> you get there? If it showed STARTTLS you may be in good shape.

Results in a previous message.

>
> You may like a little tool I just learned about called swaks
> (swiss army knifesmtp)

I will look for this when I have time, possibly tomorrow evening.
Thank you for the suggestion.

>
> I just used gentoo linux portage setup to install it but on solaris
> you may need to google up a suitable package or build from source.
>
> Telnet should tell the story but if you want a nifty little tool that
> will give a bit more info try swaks.
>
> Be sure to aim telnet or swaks at port 587 on the server. I just
> found out with Per H's prompting that on a cable (comcast) ISP that

> the normal sendmail with compiled insslSTARTTLS support works when I

> was thinking I needed to do exactly what you are thinking about;

> cobbling up some kind of stunnel or othersslwrapper to talk to part

> 465 that will be no fun to maintain.
>
> All it really took was a line Per posted in:

> Message-ID: <g0kmsb$2dd...@hedeland.org>

> that makes sendmail contact the smarthost on port 587.

Since I can't see a way to follow that link, would you mind posting it
here?(I've got to get a newsreader set up...) I'm guessing it might be
one of:

DSsmtp.att.yahoo.com:587
DSsmtp.att.yahoo.com 587

>
> My isp had been ok with plain authentication until just a couple weeks
> ago and guess who my isp was just before I switched to comcast
> ... ATT. Up until about 2 mnths ago and again plain password auth was
> ok with them then.

AT&T just started this nonsense in the last 2-3 weeks. Thunderbird was
using "Use secure connection=no" till then. Sendmail was happy. I was
happy. :/

>
> So I'm thinking some of the big players in the ISP field may be doing
> the same kind of things on there mail servers... If your problems
> arose quite recently ... that seems even more likely.

Thank You for your help.

Regards,

Dave A.

Dave.Anderson-NOSPAM

unread,

May 16, 2008, 8:35:57 PM5/16/08

to

Here is the useless info from that page you couldn't reach without a
sign-in:

Time is running out - update your email settings to help us serve you
better!

To help us ensure the security of your email, you will need to change
the settings on your desktop or mobile email client program. These
changes will affect members who send or receive email from a desktop
or mobile client program, such as Microsoft Outlook, Microsoft Outlook
Express, Eudora, Apple Mail, or Thunderbird.

Important Notice: Once these security enhancement are fully
implemented only SSL compatible email clients will be able to access
client email (POP/SMTP). Some older email client versions may not
support SSL. Please go to the AT&T Yahoo! Help site to determine if
your email client supports SSL and to see if updates or patches are
available to support SSL.

If your email client does not support SSL it will be necessary for you
to upgrade your email client in order to use client email. As always,
all customers are welcome to utilize the web-based version of AT&T
Yahoo! Mail available at http://mail.yahoo.com.

Make the Changes Automatically: To automatically make the required
changes to Outlook Express only, use the AT&T Email Auto-Configuration
Tool or the AT&T Self Support Tool.

The AT&T Email Auto-Configuration Tool will automatically change your
Outlook Express email settings. The tool can be downloaded from AT&T
Help site and follow the installation instructions.

* If you already have the AT&T Self Support Tool installed on your
computer, simply select Cannot send/receive email from the Self
Support Tool Main Interface to run an email settings check. When
prompted to change your email settings, select Yes.

Note: This will only provide changes to Outlook Express.
* If you do not have the AT&T Self Support Tool installed,
download it and then follow the instructions above.

Make the Changes Manually: To manually make the required setting
changes in Outlook, Outlook Express and other email applications,
please follow these detailed instructions.

Alternatively, you may take the following steps to change the settings
on your desktop or mobile email client program:

1. Open your email client program.
2. Locate the email account settings for your particular client.
3. Change the POP server to pop.att.yahoo.com.
4. Change the SMTP server to smtp.att.yahoo.com.
5. Check the option labeled Use an encrypted connection (SSL).
* Change the SMTP port to 465.
6. Check the option labeled Use an encrypted connection (SSL).
* Change the POP3 port to 995.
7. Confirm the above settings before clicking OK.

The web-based version of AT&T Yahoo! Mail is not affected by these
changes and will continue to be available at http://mail.yahoo.com.

On May 16, 12:45 pm, p...@hedeland.org (Per Hedeland) wrote:
> In article
> <778a7697-e80a-4dfc-8f60-415377ded...@k10g2000prm.googlegroups.com>
>

> "Dave.Anderson-NOSPAM" <dave.anderson...@gmail.com> writes:
> >On May 14, 1:55 pm, p...@hedeland.org (Per Hedeland) wrote:
>
> >> Are you *sure* that that is the *only* form ofSSLaccess they
> >support?SMTP"wrapped in"SSLa.k.a. SMTPS on port 465 is non-standard and
> >> generally frowned upon. The standard way to useSSLwithSMTPis via
> >> STARTTLS on the normal port 25. This is the most important question for
> >> you, since sendmail has no client-side support for SMTPS (server-side it
> >> supports both STARTTLS and SMTPS, the latter for the benefit of stupid
> >> MUAs that can't do STARTTLS) - no amount of upgrading and rebuilding it
> >> will get it to appear. There is a solution to this, but you don't want
> >> to go there if you don't have to.
>
> How "interesting" to have two different threads about the same subject
> going in parallell, one with a person that digs up everything I asked
> for and way more and tries out and reports all kinds of things, another
> with a person that just throws up his arms and doesn't even read what I
> wrote...
>
> >Maybe I am misinterpreting what is laid out here:
> >http://helpme.att.net/article.php?item=10918
>
> That page asks me to log in with my AT&T email username, of which I have
> none, and otherwise provides zero information.
>

> >SSLis a requirement.

>
> Yes, but as I wrote above it can be achieved in two different ways, one
> non-standard that isn't supported by sendmail, one standard that is.
> Your first mission is to find out whether your ISP supports the latter.
> There are a couple of ways to go about it (none of them foolproof):
>
> 1) Ask your ISP.
> 2) Read carefully through the information provided by the ISP.

> 3) telnet to port 25 on yourSMTPserver, enter EHLO, and look for

> STARTTLS in the response.
> 4) Same as 3) but using port 587.
>
> >The specific auth mechanism I am unsure of, but
> >if I don't have my username/password correctly entered, mail doesn't
> >get sent.
>

> Although it's possible to useSSL/TLS for authentication, I'd say it's

> unheard of in the area of end-userSMTPconnections to ISP servers. IfSSL/TLS is required, you need to get that going before you even attempt
> authentication.
>
> --Per Hedeland
> p...@hedeland.org

Dave Anderson

unread,

May 16, 2008, 9:35:46 PM5/16/08

to

OK, I'm the OP, and I dug up AT&T's news server settings.... I'll be
posting mostly from this acct. I have to move on to other things, but at
least I have decent newsreader set up and will get to browsing other
related threads when I have time.

Thanks again all, for the help so far.

D

Dave Anderson

unread,

May 17, 2008, 1:00:34 AM5/17/08

to

While I am not yet *sure* that what I described is the *only* form of
SSL access supported, I have established that, at least with Thunderbird
using the recommended configuration, port 25 is never used. Remote port
465 is *always* used, for every inbound/outbound packet.

Below is a trace from sending a test message with Thunderbird, backing
the above assertion and hopefully shedding some light on what's really
going on. The trace has been sanitized somewhat, though user/pass were
obviously encrypted. Any address where the last octet or byte is "ME" is
the machine running Thunderbird. Any address where the last octet or
byte is "RT" is my router/firewall.

I could also run snoop against a sendmail session but I'm not sure that
would be worth doing -- might be easier to post various config file
details(if I've missed any).

I'll continue to pick at this as I find time here and there. This
computer is a fresh setup, so I don't yet have all my software setup,
but I'll do my best to follow any diagnostic steps tha might help.

Thx,

Dave A.

---[snip]---

No. Time Source Destination Protocol
Info
4 2.905072 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [SYN] Seq=0
Win=32768 Len=0 MSS=1460

Frame 4 (62 bytes on wire, 62 bytes captured)
Arrival Time: May 16, 2008 21:19:16.507982000
[Time delta from previous captured frame: 0.001122000 seconds]
[Time delta from previous displayed frame: 2.905072000 seconds]
[Time since reference or first frame: 2.905072000 seconds]
Frame Number: 4
Frame Length: 62 bytes
Capture Length: 62 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP SYN/FIN]
[Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 48
Identification: 0x522f (21039)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1cfa [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 0, Len: 0
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 32768
Checksum: 0xa857 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (8 bytes)
Maximum segment size: 1460 bytes
NOP
NOP
SACK permitted

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 30 52 2f 40 00 80 06 1c fa c0 a8 45 44 45 93 .0R/@.......EDE.
0020 40 1f 0c 68 01 d1 86 81 3a 6e 00 00 00 00 70 02 @..h....:n....p.
0030 80 00 a8 57 00 00 02 04 05 b4 01 01 04 02 ...W..........

No. Time Source Destination Protocol
Info
5 2.919649 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0
MSS=1460

Frame 5 (60 bytes on wire, 60 bytes captured)
Arrival Time: May 16, 2008 21:19:16.522559000
[Time delta from previous captured frame: 0.014577000 seconds]
[Time delta from previous displayed frame: 0.014577000 seconds]
[Time since reference or first frame: 2.919649000 seconds]
Frame Number: 5
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP SYN/FIN]
[Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 0000
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 44
Identification: 0xd37f (54143)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe3ad [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 0, Ack: 1, Len: 0
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 24 bytes
Flags: 0x12 (SYN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x01cf [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (4 bytes)
Maximum segment size: 1460 bytes
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 4]
[The RTT to ACK the segment was: 0.014577000 seconds]

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 2c d3 7f 40 00 38 06 e3 ad 45 93 40 1f c0 a8 .,..@.8...E.@...
0020 45 44 01 d1 0c 68 6b 82 cf fc 86 81 3a 6f 60 12 ED...hk.....:o`.
0030 ff ff 01 cf 00 00 02 04 05 b4 00 00 ............

No. Time Source Destination Protocol
Info
6 2.919669 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [ACK] Seq=1
Ack=1 Win=33580 [TCP CHECKSUM INCORRECT] Len=0

Frame 6 (54 bytes on wire, 54 bytes captured)
Arrival Time: May 16, 2008 21:19:16.522579000
[Time delta from previous captured frame: 0.000020000 seconds]
[Time delta from previous displayed frame: 0.000020000 seconds]
[Time since reference or first frame: 2.919669000 seconds]
Frame Number: 6
Frame Length: 54 bytes
Capture Length: 54 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x5230 (21040)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1d01 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 1, Ack: 1, Len: 0
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 33580
Checksum: 0x8bb9 [incorrect, should be 0x965f (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 5]
[The RTT to ACK the segment was: 0.000020000 seconds]

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 28 52 30 40 00 80 06 1d 01 c0 a8 45 44 45 93 .(R0@.......EDE.
0020 40 1f 0c 68 01 d1 86 81 3a 6f 6b 82 cf fd 50 10 @..h....:ok...P.
0030 83 2c 8b b9 00 00 .,....

No. Time Source Destination Protocol
Info
7 2.920601 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=1 Ack=1 Win=33580 [TCP CHECKSUM INCORRECT] Len=151

Frame 7 (205 bytes on wire, 205 bytes captured)
Arrival Time: May 16, 2008 21:19:16.523511000
[Time delta from previous captured frame: 0.000932000 seconds]
[Time delta from previous displayed frame: 0.000932000 seconds]
[Time since reference or first frame: 2.920601000 seconds]
Frame Number: 7
Frame Length: 205 bytes
Capture Length: 205 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 191
Identification: 0x5233 (21043)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c67 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 1, Ack: 1, Len: 151
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 1 (relative sequence number)
[Next sequence number: 152 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 33580
Checksum: 0x8c50 [incorrect, should be 0x7614 (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Data (151 bytes)
Data: 16030100920100008E030100011C7750A3A9AF3A90AE5B40...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 bf 52 33 40 00 80 06 1c 67 c0 a8 45 44 45 93 ..R3@....g..EDE.
0020 40 1f 0c 68 01 d1 86 81 3a 6f 6b 82 cf fd 50 18 @..h....:ok...P.
0030 83 2c 8c 50 00 00 16 03 01 00 92 01 00 00 8e 03 .,.P............
0040 01 00 01 1c 77 50 a3 a9 af 3a 90 ae 5b 40 bc 3a ....wP...:..[@.:
0050 91 f8 2b a6 21 c2 49 3d db 62 47 f0 b8 4d b6 fd ..+.!.I=.bG..M..
0060 62 00 00 38 c0 0a c0 14 00 39 00 38 c0 0f c0 05 b..8.....9.8....
0070 00 35 c0 07 c0 09 c0 11 c0 13 00 33 00 32 c0 0c .5.........3.2..
0080 c0 0e c0 02 c0 04 00 04 00 05 00 2f c0 08 c0 12 .........../....
0090 00 16 00 13 c0 0d c0 03 fe ff 00 0a 01 00 00 2d ...............-
00a0 00 00 00 17 00 15 00 00 12 73 6d 74 70 2e 61 74 .........smtp.at
00b0 74 2e 79 61 68 6f 6f 2e 63 6f 6d 00 0a 00 08 00 t.yahoo.com.....
00c0 06 00 17 00 18 00 19 00 0b 00 02 01 00 .............

No. Time Source Destination Protocol
Info
8 2.943447 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1 Ack=152 Win=65535 Len=827

Frame 8 (881 bytes on wire, 881 bytes captured)
Arrival Time: May 16, 2008 21:19:16.546357000
[Time delta from previous captured frame: 0.022846000 seconds]
[Time delta from previous displayed frame: 0.022846000 seconds]
[Time since reference or first frame: 2.943447000 seconds]
Frame Number: 8
Frame Length: 881 bytes
Capture Length: 881 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 867
Identification: 0xd39b (54171)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe05a [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1, Ack: 152, Len: 827
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1 (relative sequence number)
[Next sequence number: 828 (relative sequence number)]
Acknowledgement number: 152 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xbc04 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 7]
[The RTT to ACK the segment was: 0.022846000 seconds]
Data (827 bytes)
Data: 160301002A020000260301482E5CCAC4CBC1AD32B6FD72B6...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 03 63 d3 9b 40 00 38 06 e0 5a 45 93 40 1f c0 a8 .c..@.8..ZE.@...
0020 45 44 01 d1 0c 68 6b 82 cf fd 86 81 3b 06 50 18 ED...hk.....;.P.
0030 ff ff bc 04 00 00 16 03 01 00 2a 02 00 00 26 03 ..........*...&.
0040 01 48 2e 5c ca c4 cb c1 ad 32 b6 fd 72 b6 4a 58 .H.\.....2..r.JX
0050 2b be d4 53 db 63 5b a4 de eb b5 ae 15 02 64 9a +..S.c[.......d.
0060 c9 00 00 35 00 16 03 01 02 fe 0b 00 02 fa 00 02 ...5............
0070 f7 00 02 f4 30 82 02 f0 30 82 02 59 a0 03 02 01 ....0...0..Y....
0080 02 02 03 06 cc 0b 30 0d 06 09 2a 86 48 86 f7 0d ......0...*.H...
0090 01 01 05 05 00 30 4e 31 0b 30 09 06 03 55 04 06 .....0N1.0...U..
00a0 13 02 55 53 31 10 30 0e 06 03 55 04 0a 13 07 45 ..US1.0...U....E
00b0 71 75 69 66 61 78 31 2d 30 2b 06 03 55 04 0b 13 quifax1-0+..U...
00c0 24 45 71 75 69 66 61 78 20 53 65 63 75 72 65 20 $Equifax Secure
00d0 43 65 72 74 69 66 69 63 61 74 65 20 41 75 74 68 Certificate Auth
--snip --
0340 29 7f 96 aa 97 f1 0d bc df 5d cf 1a c0 8b 8d 18 )........]......
0350 99 89 53 24 54 4e 8f 1e 30 e8 ee 77 45 91 c7 5e ..S$TN..0..wE..^
0360 d0 a3 21 87 35 8e 37 27 16 03 01 00 04 0e 00 00 ..!.5.7'........
0370 00 .

No. Time Source Destination Protocol
Info
9 2.945037 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=152 Ack=828 Win=32753 [TCP CHECKSUM INCORRECT] Len=198

Frame 9 (252 bytes on wire, 252 bytes captured)
Arrival Time: May 16, 2008 21:19:16.547947000
[Time delta from previous captured frame: 0.001590000 seconds]
[Time delta from previous displayed frame: 0.001590000 seconds]
[Time since reference or first frame: 2.945037000 seconds]
Frame Number: 9
Frame Length: 252 bytes
Capture Length: 252 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 238
Identification: 0x523a (21050)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c31 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 152, Ack: 828, Len: 198
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 152 (relative sequence number)
[Next sequence number: 350 (relative sequence number)]
Acknowledgement number: 828 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32753
Checksum: 0x8c7f [incorrect, should be 0x66ef (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 8]
[The RTT to ACK the segment was: 0.001590000 seconds]
Data (198 bytes)
Data: 1603010086100000820080518406B2A592CD1D20D26E56AA...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
--snip--
00f0 d8 39 af f3 65 c6 dd dc 2e 2a 64 7d .9..e....*d}

No. Time Source Destination Protocol
Info
10 2.970933 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=828 Ack=350 Win=65535 Len=59

Frame 10 (113 bytes on wire, 113 bytes captured)
Arrival Time: May 16, 2008 21:19:16.573843000
[Time delta from previous captured frame: 0.025896000 seconds]
[Time delta from previous displayed frame: 0.025896000 seconds]
[Time since reference or first frame: 2.970933000 seconds]
Frame Number: 10
Frame Length: 113 bytes
Capture Length: 113 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 99
Identification: 0xd3d2 (54226)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe323 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 828, Ack: 350, Len: 59
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 828 (relative sequence number)
[Next sequence number: 887 (relative sequence number)]
Acknowledgement number: 350 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x8b5f [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 9]
[The RTT to ACK the segment was: 0.025896000 seconds]
Data (59 bytes)
Data: 140301000101160301003094CABF0800B24CE16337D0C82F...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0060 b2 d9 b5 f1 71 d4 ac 9e 3f 76 0f e9 c8 5b a6 2d ....q...?v...[.-
0070 9d .

No. Time Source Destination Protocol
Info
11 3.116739 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=887 Ack=350 Win=65535 Len=69

Frame 11 (123 bytes on wire, 123 bytes captured)
Arrival Time: May 16, 2008 21:19:16.719649000
[Time delta from previous captured frame: 0.145806000 seconds]
[Time delta from previous displayed frame: 0.145806000 seconds]
[Time since reference or first frame: 3.116739000 seconds]
Frame Number: 11
Frame Length: 123 bytes
Capture Length: 123 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 109
Identification: 0xd42d (54317)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe2be [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 887, Ack: 350, Len: 69
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 887 (relative sequence number)
[Next sequence number: 956 (relative sequence number)]
Acknowledgement number: 350 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xece4 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (69 bytes)
Data: 17030100401F4B2D6264B3016A9058BE1ED4E35921A285EF...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 6d d4 2d 40 00 38 06 e2 be 45 93 40 1f c0 a8 .m.-@.8...E.@...
0020 45 44 01 d1 0c 68 6b 82 d3 73 86 81 3b cc 50 18 ED...hk..s..;.P.
0030 ff ff ec e4 00 00 17 03 01 00 40 1f 4b 2d 62 64 ..........@.K-bd
0040 b3 01 6a 90 58 be 1e d4 e3 59 21 a2 85 ef 32 75 ..j.X....Y!...2u
0050 d8 4f 00 02 0b 36 15 b4 86 76 50 04 1f 55 bd d7 .O...6...vP..U..
0060 3d a9 5a 82 a5 e9 59 d1 0d 01 5b 63 87 40 d9 46 =.Z...Y...[c.@.F
0070 a2 e0 45 9b 2c 63 a1 a5 bf 12 4c ..E.,c....L

No. Time Source Destination Protocol
Info
12 3.116765 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [ACK] Seq=350
Ack=956 Win=32625 [TCP CHECKSUM INCORRECT] Len=0

Frame 12 (54 bytes on wire, 54 bytes captured)
Arrival Time: May 16, 2008 21:19:16.719675000
[Time delta from previous captured frame: 0.000026000 seconds]
[Time delta from previous displayed frame: 0.000026000 seconds]
[Time since reference or first frame: 3.116765000 seconds]
Frame Number: 12
Frame Length: 54 bytes
Capture Length: 54 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x5245 (21061)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1cec [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 350, Ack: 956, Len: 0
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 350 (relative sequence number)
Acknowledgement number: 956 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32625
Checksum: 0x8bb9 [incorrect, should be 0x9502 (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 11]
[The RTT to ACK the segment was: 0.000026000 seconds]

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 28 52 45 40 00 80 06 1c ec c0 a8 45 44 45 93 .(RE@.......EDE.
0020 40 1f 0c 68 01 d1 86 81 3b cc 6b 82 d3 b8 50 10 @..h....;.k...P.
0030 7f 71 8b b9 00 00 .q....

No. Time Source Destination Protocol
Info
13 3.117487 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=350 Ack=956 Win=32625 [TCP CHECKSUM INCORRECT] Len=53

Frame 13 (107 bytes on wire, 107 bytes captured)
Arrival Time: May 16, 2008 21:19:16.720397000
[Time delta from previous captured frame: 0.000722000 seconds]
[Time delta from previous displayed frame: 0.000722000 seconds]
[Time since reference or first frame: 3.117487000 seconds]
Frame Number: 13
Frame Length: 107 bytes
Capture Length: 107 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 93
Identification: 0x5254 (21076)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1ca8 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 350, Ack: 956, Len: 53
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 350 (relative sequence number)
[Next sequence number: 403 (relative sequence number)]
Acknowledgement number: 956 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32625
Checksum: 0x8bee [incorrect, should be 0x34ef (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Data (53 bytes)
Data: 1703010030C150CF9F1988163F0DB68D8238FA46ED77108F...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 5d 52 54 40 00 80 06 1c a8 c0 a8 45 44 45 93 .]RT@.......EDE.
--snip--
0060 32 61 15 41 35 18 ed cf c2 02 cb 2a.A5......

No. Time Source Destination Protocol
Info
14 3.134447 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=956 Ack=403 Win=65535 Len=133

Frame 14 (187 bytes on wire, 187 bytes captured)
Arrival Time: May 16, 2008 21:19:16.737357000
[Time delta from previous captured frame: 0.016960000 seconds]
[Time delta from previous displayed frame: 0.016960000 seconds]
[Time since reference or first frame: 3.134447000 seconds]
Frame Number: 14
Frame Length: 187 bytes
Capture Length: 187 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 173
Identification: 0xd444 (54340)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe267 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 956, Ack: 403, Len: 133
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 956 (relative sequence number)
[Next sequence number: 1089 (relative sequence number)]
Acknowledgement number: 403 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x2c7f [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 13]
[The RTT to ACK the segment was: 0.016960000 seconds]
Data (133 bytes)
Data: 17030100803D59BD0009187BB67A9D923AAD12E315D073D5...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 ad d4 44 40 00 38 06 e2 67 45 93 40 1f c0 a8 ...D@.8..gE.@...
--snip--
00a0 49 72 51 54 df 5e b5 55 42 f8 39 fd 0a 82 3d 69 IrQT.^.UB.9...=i
00b0 31 7f b7 a2 3d 74 ff 1c 7a 14 6b 1...=t..z.k

No. Time Source Destination Protocol
Info
15 3.134819 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=403 Ack=1089 Win=32492 [TCP CHECKSUM INCORRECT] Len=85

Frame 15 (139 bytes on wire, 139 bytes captured)
Arrival Time: May 16, 2008 21:19:16.737729000
[Time delta from previous captured frame: 0.000372000 seconds]
[Time delta from previous displayed frame: 0.000372000 seconds]
[Time since reference or first frame: 3.134819000 seconds]
Frame Number: 15
Frame Length: 139 bytes
Capture Length: 139 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 125
Identification: 0x526b (21099)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c71 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 403, Ack: 1089, Len: 85
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 403 (relative sequence number)
[Next sequence number: 488 (relative sequence number)]
Acknowledgement number: 1089 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32492
Checksum: 0x8c0e [incorrect, should be 0xf6ed (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 14]
[The RTT to ACK the segment was: 0.000372000 seconds]
Data (85 bytes)
Data: 1703010050868A9A3CAB675610D990C21E17BEB8F897A54D...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 7d 52 6b 40 00 80 06 1c 71 c0 a8 45 44 45 93 .}Rk@....q..EDE.
--snip--
0080 91 f7 fa da b7 96 e4 8c c4 a2 83 ...........

No. Time Source Destination Protocol
Info
16 3.245017 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [ACK] Seq=1089 Ack=488 Win=65535 Len=0

Frame 16 (60 bytes on wire, 60 bytes captured)
Arrival Time: May 16, 2008 21:19:16.847927000
[Time delta from previous captured frame: 0.110198000 seconds]
[Time delta from previous displayed frame: 0.110198000 seconds]
[Time since reference or first frame: 3.245017000 seconds]
Frame Number: 16
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0xd4a0 (54432)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe290 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1089, Ack: 488, Len: 0
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1089 (relative sequence number)
Acknowledgement number: 488 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x1365 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 15]
[The RTT to ACK the segment was: 0.110198000 seconds]

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 28 d4 a0 40 00 38 06 e2 90 45 93 40 1f c0 a8 .(..@.8...E.@...
0020 45 44 01 d1 0c 68 6b 82 d4 3d 86 81 3c 56 50 10 ED...hk..=..<VP.
0030 ff ff 13 65 00 00 00 00 00 00 00 00 ...e........

No. Time Source Destination Protocol
Info
17 3.595680 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1089 Ack=488 Win=65535 Len=53

Frame 17 (107 bytes on wire, 107 bytes captured)
Arrival Time: May 16, 2008 21:19:17.198590000
[Time delta from previous captured frame: 0.350663000 seconds]
[Time delta from previous displayed frame: 0.350663000 seconds]
[Time since reference or first frame: 3.595680000 seconds]
Frame Number: 17
Frame Length: 107 bytes
Capture Length: 107 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 93
Identification: 0xd5d9 (54745)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe122 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1089, Ack: 488, Len: 53
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1089 (relative sequence number)
[Next sequence number: 1142 (relative sequence number)]
Acknowledgement number: 488 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x65dc [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (53 bytes)
Data: 1703010030F2C499F7AFA6254F85A4F77EC6D7F1FDEB664B...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 5d d5 d9 40 00 38 06 e1 22 45 93 40 1f c0 a8 .]..@.8.."E.@...
--snip--
0060 95 38 8e 78 48 17 8b 2b b9 cf 31 .8.xH..+..1

No. Time Source Destination Protocol
Info
18 3.596025 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=488 Ack=1142 Win=32439 [TCP CHECKSUM INCORRECT] Len=69

Frame 18 (123 bytes on wire, 123 bytes captured)
Arrival Time: May 16, 2008 21:19:17.198935000
[Time delta from previous captured frame: 0.000345000 seconds]
[Time delta from previous displayed frame: 0.000345000 seconds]
[Time since reference or first frame: 3.596025000 seconds]
Frame Number: 18
Frame Length: 123 bytes
Capture Length: 123 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 109
Identification: 0x5282 (21122)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c6a [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 488, Ack: 1142, Len: 69
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 488 (relative sequence number)
[Next sequence number: 557 (relative sequence number)]
Acknowledgement number: 1142 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32439
Checksum: 0x8bfe [incorrect, should be 0x54f2 (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 17]
[The RTT to ACK the segment was: 0.000345000 seconds]
Data (69 bytes)
Data: 1703010040F1934A2A0D5310B49C3A4AC454F803D99F1BB3...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
--snip--
0070 10 19 6e 78 0f 86 0e b6 7f d3 2a ..nx......*

No. Time Source Destination Protocol
Info
19 3.611407 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1142 Ack=557 Win=65535 Len=37

Frame 19 (91 bytes on wire, 91 bytes captured)
Arrival Time: May 16, 2008 21:19:17.214317000
[Time delta from previous captured frame: 0.015382000 seconds]
[Time delta from previous displayed frame: 0.015382000 seconds]
[Time since reference or first frame: 3.611407000 seconds]
Frame Number: 19
Frame Length: 91 bytes
Capture Length: 91 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 77
Identification: 0xd5e6 (54758)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe125 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1142, Ack: 557, Len: 37
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1142 (relative sequence number)
[Next sequence number: 1179 (relative sequence number)]
Acknowledgement number: 557 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xf215 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 18]
[The RTT to ACK the segment was: 0.015382000 seconds]
Data (37 bytes)
Data: 1703010020CC1AAA4376A92A71EB0254CAB84DE1CEC096B3...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0050 b4 40 bf 35 a3 d8 a6 40 83 49 49 .@.5...@.II

No. Time Source Destination Protocol
Info
20 3.611744 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=557 Ack=1179 Win=32402 [TCP CHECKSUM INCORRECT] Len=69

Frame 20 (123 bytes on wire, 123 bytes captured)
Arrival Time: May 16, 2008 21:19:17.214654000
[Time delta from previous captured frame: 0.000337000 seconds]
[Time delta from previous displayed frame: 0.000337000 seconds]
[Time since reference or first frame: 3.611744000 seconds]
Frame Number: 20
Frame Length: 123 bytes
Capture Length: 123 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 109
Identification: 0x529b (21147)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c51 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 557, Ack: 1179, Len: 69
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 557 (relative sequence number)
[Next sequence number: 626 (relative sequence number)]
Acknowledgement number: 1179 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32402
Checksum: 0x8bfe [incorrect, should be 0x34fe (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 19]
[The RTT to ACK the segment was: 0.000337000 seconds]
Data (69 bytes)
Data: 170301004057D1D297774B891434D660A665C1BC78F67528...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 6d 52 9b 40 00 80 06 1c 51 c0 a8 45 44 45 93 .mR.@....Q..EDE.
--snip--
0060 cc de 53 d9 d2 a6 0b c1 2f b1 30 30 73 b1 2b 5b ..S...../.00s.+[
0070 c7 f1 4f 01 be 5d 49 22 b6 ce 5a ..O..]I"..Z

No. Time Source Destination Protocol
Info
21 3.664644 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1179 Ack=626 Win=65535 Len=37

Frame 21 (91 bytes on wire, 91 bytes captured)
Arrival Time: May 16, 2008 21:19:17.267554000
[Time delta from previous captured frame: 0.052900000 seconds]
[Time delta from previous displayed frame: 0.052900000 seconds]
[Time since reference or first frame: 3.664644000 seconds]
Frame Number: 21
Frame Length: 91 bytes
Capture Length: 91 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 77
Identification: 0xd615 (54805)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe0f6 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1179, Ack: 626, Len: 37
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1179 (relative sequence number)
[Next sequence number: 1216 (relative sequence number)]
Acknowledgement number: 626 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x2974 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 20]
[The RTT to ACK the segment was: 0.052900000 seconds]
Data (37 bytes)
Data: 170301002035A7453AF4D4F1DF0867209E102482AAAD3848...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0050 5c 2e d7 4e 1e 91 63 bf 59 da 32 \..N..c.Y.2

No. Time Source Destination Protocol
Info
22 3.664938 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=626 Ack=1216 Win=32365 [TCP CHECKSUM INCORRECT] Len=37

Frame 22 (91 bytes on wire, 91 bytes captured)
Arrival Time: May 16, 2008 21:19:17.267848000
[Time delta from previous captured frame: 0.000294000 seconds]
[Time delta from previous displayed frame: 0.000294000 seconds]
[Time since reference or first frame: 3.664938000 seconds]
Frame Number: 22
Frame Length: 91 bytes
Capture Length: 91 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 77
Identification: 0x52b4 (21172)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c58 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 626, Ack: 1216, Len: 37
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 626 (relative sequence number)
[Next sequence number: 663 (relative sequence number)]
Acknowledgement number: 1216 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32365
Checksum: 0x8bde [incorrect, should be 0x0090 (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 21]
[The RTT to ACK the segment was: 0.000294000 seconds]
Data (37 bytes)
Data: 1703010020F584163CC887844FDD4C7E587865D94DF8B717...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
--snip--
0050 77 bc b9 9e 13 f1 bf 4a 75 aa ca w......Ju..

No. Time Source Destination Protocol
Info
23 3.684364 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1216 Ack=663 Win=65535 Len=53

Frame 23 (107 bytes on wire, 107 bytes captured)
Arrival Time: May 16, 2008 21:19:17.287274000
[Time delta from previous captured frame: 0.019426000 seconds]
[Time delta from previous displayed frame: 0.019426000 seconds]
[Time since reference or first frame: 3.684364000 seconds]
Frame Number: 23
Frame Length: 107 bytes
Capture Length: 107 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 93
Identification: 0xd625 (54821)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe0d6 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1216, Ack: 663, Len: 53
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1216 (relative sequence number)
[Next sequence number: 1269 (relative sequence number)]
Acknowledgement number: 663 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x3eb0 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 22]
[The RTT to ACK the segment was: 0.019426000 seconds]
Data (53 bytes)
Data: 1703010030FB51DF90B309FBEBE2EB1E34C7AAA9BFE01115...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 5d d6 25 40 00 38 06 e0 d6 45 93 40 1f c0 a8 .].%@.8...E.@...
--snip--
0050 5d 79 b4 3a 23 b5 0b 4d bb 04 c3 8b ce 3f 29 de ]y.:#..M.....?).
0060 ae 08 97 ae 82 19 1b 13 b4 96 aa ...........

No. Time Source Destination Protocol
Info
24 3.685499 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=663 Ack=1269 Win=32312 [TCP CHECKSUM INCORRECT] Len=389

Frame 24 (443 bytes on wire, 443 bytes captured)
Arrival Time: May 16, 2008 21:19:17.288409000
[Time delta from previous captured frame: 0.001135000 seconds]
[Time delta from previous displayed frame: 0.001135000 seconds]
[Time since reference or first frame: 3.685499000 seconds]
Frame Number: 24
Frame Length: 443 bytes
Capture Length: 443 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 429
Identification: 0x52cb (21195)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1ae1 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 663, Ack: 1269, Len: 389
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 663 (relative sequence number)
[Next sequence number: 1052 (relative sequence number)]
Acknowledgement number: 1269 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32312
Checksum: 0x8d3e [incorrect, should be 0x6504 (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 23]
[The RTT to ACK the segment was: 0.001135000 seconds]
Data (389 bytes)
Data: 1703010180B84ED6B97AA732DF392D34E430A9D5D3BEE130...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 01 ad 52 cb 40 00 80 06 1a e1 c0 a8 45 44 45 93 ..R.@.......EDE.
--snip--
01b0 93 bf 6e 96 d6 66 3e 78 9e 42 88 ..n..f>x.B.

No. Time Source Destination Protocol
Info
25 3.804636 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [ACK] Seq=1269 Ack=1052 Win=65535 Len=0

Frame 25 (60 bytes on wire, 60 bytes captured)
Arrival Time: May 16, 2008 21:19:17.407546000
[Time delta from previous captured frame: 0.119137000 seconds]
[Time delta from previous displayed frame: 0.119137000 seconds]
[Time since reference or first frame: 3.804636000 seconds]
Frame Number: 25
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0xd681 (54913)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xe0af [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1269, Ack: 1052, Len: 0
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1269 (relative sequence number)
Acknowledgement number: 1052 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x107d [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 24]
[The RTT to ACK the segment was: 0.119137000 seconds]

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0030 ff ff 10 7d 00 00 00 00 00 00 00 00 ...}........

No. Time Source Destination Protocol
Info
26 4.074635 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1269 Ack=1052 Win=65535 Len=69

Frame 26 (123 bytes on wire, 123 bytes captured)
Arrival Time: May 16, 2008 21:19:17.677545000
[Time delta from previous captured frame: 0.269999000 seconds]
[Time delta from previous displayed frame: 0.269999000 seconds]
[Time since reference or first frame: 4.074635000 seconds]
Frame Number: 26
Frame Length: 123 bytes
Capture Length: 123 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 109
Identification: 0xd756 (55126)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xdf95 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1269, Ack: 1052, Len: 69
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1269 (relative sequence number)
[Next sequence number: 1338 (relative sequence number)]
Acknowledgement number: 1052 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x8be7 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (69 bytes)
Data: 17030100406235FFAEC161D94FC512BCCE757F583BC7F4B2...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0070 29 87 da f5 49 5e 4b ba 8c ca 2c )...I^K...,

No. Time Source Destination Protocol
Info
27 4.075369 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [PSH, ACK]
Seq=1052 Ack=1338 Win=32243 [TCP CHECKSUM INCORRECT] Len=37

Frame 27 (91 bytes on wire, 91 bytes captured)
Arrival Time: May 16, 2008 21:19:17.678279000
[Time delta from previous captured frame: 0.000734000 seconds]
[Time delta from previous displayed frame: 0.000734000 seconds]
[Time since reference or first frame: 4.075369000 seconds]
Frame Number: 27
Frame Length: 91 bytes
Capture Length: 91 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 77
Identification: 0x52e1 (21217)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c2b [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 1052, Ack: 1338, Len: 37
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 1052 (relative sequence number)
[Next sequence number: 1089 (relative sequence number)]
Acknowledgement number: 1338 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32243
Checksum: 0x8bde [incorrect, should be 0xea51 (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 26]
[The RTT to ACK the segment was: 0.000734000 seconds]
Data (37 bytes)
Data: 1703010020C1B93106AC66DA7865654ECB8A805AD7BC829F...

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
--snip--
0050 c1 f8 fe ed ba 50 7e 2f f1 98 f9 .....P~/...

No. Time Source Destination Protocol
Info
28 4.094439 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1338 Ack=1089 Win=65535 Len=69

Frame 28 (123 bytes on wire, 123 bytes captured)
Arrival Time: May 16, 2008 21:19:17.697349000
[Time delta from previous captured frame: 0.019070000 seconds]
[Time delta from previous displayed frame: 0.019070000 seconds]
[Time since reference or first frame: 4.094439000 seconds]
Frame Number: 28
Frame Length: 123 bytes
Capture Length: 123 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 109
Identification: 0xd77b (55163)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xdf70 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1338, Ack: 1089, Len: 69
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1338 (relative sequence number)
[Next sequence number: 1407 (relative sequence number)]
Acknowledgement number: 1089 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x9406 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 27]
[The RTT to ACK the segment was: 0.019070000 seconds]
Data (69 bytes)
Data: 17030100404CCF993E6A543DC199F40D14637AC5CF3CB5F8...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0070 8a f2 8a a4 2f c9 c5 42 03 f1 11 ..../..B...

No. Time Source Destination Protocol
Info
29 4.094453 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [PSH, ACK] Seq=1407 Ack=1089 Win=65535 Len=37

Frame 29 (91 bytes on wire, 91 bytes captured)
Arrival Time: May 16, 2008 21:19:17.697363000
[Time delta from previous captured frame: 0.000014000 seconds]
[Time delta from previous displayed frame: 0.000014000 seconds]
[Time since reference or first frame: 4.094453000 seconds]
Frame Number: 29
Frame Length: 91 bytes
Capture Length: 91 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 77
Identification: 0xd77c (55164)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xdf8f [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1407, Ack: 1089, Len: 37
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1407 (relative sequence number)
[Next sequence number: 1444 (relative sequence number)]
Acknowledgement number: 1089 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xda9d [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (37 bytes)
Data: 1503010020F46DEC7D20D5C3D61ABD44D9506FC456D055A6...

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0050 3d b9 7e ed 84 13 47 f6 2f d9 2c =.~...G./.,

No. Time Source Destination Protocol
Info
30 4.094461 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [ACK] Seq=1089
Ack=1444 Win=32137 [TCP CHECKSUM INCORRECT] Len=0

Frame 30 (54 bytes on wire, 54 bytes captured)
Arrival Time: May 16, 2008 21:19:17.697371000
[Time delta from previous captured frame: 0.000008000 seconds]
[Time delta from previous displayed frame: 0.000008000 seconds]
[Time since reference or first frame: 4.094461000 seconds]
Frame Number: 30
Frame Length: 54 bytes
Capture Length: 54 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x52eb (21227)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c46 [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 1089, Ack: 1444, Len: 0
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 1089 (relative sequence number)
Acknowledgement number: 1444 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32137
Checksum: 0x8bb9 [incorrect, should be 0x921f (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 29]
[The RTT to ACK the segment was: 0.000008000 seconds]

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
--snip--
0030 7d 89 8b b9 00 00 }.....

No. Time Source Destination Protocol
Info
31 4.096465 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [FIN, ACK] Seq=1444 Ack=1089 Win=65535 Len=0

Frame 31 (60 bytes on wire, 60 bytes captured)
Arrival Time: May 16, 2008 21:19:17.699375000
[Time delta from previous captured frame: 0.002004000 seconds]
[Time delta from previous displayed frame: 0.002004000 seconds]
[Time since reference or first frame: 4.096465000 seconds]
Frame Number: 31
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP SYN/FIN]
[Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0xd780 (55168)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xdfb0 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1444, Ack: 1089, Len: 0
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1444 (relative sequence number)
Acknowledgement number: 1089 (relative ack number)
Header length: 20 bytes
Flags: 0x11 (FIN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...1 = Fin: Set
Window size: 65535
Checksum: 0x0fa8 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 30]
[The RTT to ACK the segment was: 0.002004000 seconds]

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
--snip--
0030 ff ff 0f a8 00 00 00 00 00 00 00 00 ............

No. Time Source Destination Protocol
Info
32 4.096491 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [ACK] Seq=1089
Ack=1445 Win=32137 [TCP CHECKSUM INCORRECT] Len=0

Frame 32 (54 bytes on wire, 54 bytes captured)
Arrival Time: May 16, 2008 21:19:17.699401000
[Time delta from previous captured frame: 0.000026000 seconds]
[Time delta from previous displayed frame: 0.000026000 seconds]
[Time since reference or first frame: 4.096491000 seconds]
Frame Number: 32
Frame Length: 54 bytes
Capture Length: 54 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x52f6 (21238)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c3b [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 1089, Ack: 1445, Len: 0
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 1089 (relative sequence number)
Acknowledgement number: 1445 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 32137
Checksum: 0x8bb9 [incorrect, should be 0x921e (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 31]
[The RTT to ACK the segment was: 0.000026000 seconds]

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
--snip--
0030 7d 89 8b b9 00 00 }.....

No. Time Source Destination Protocol
Info
33 4.130872 flash
smtp.sbc.mail.yahoo4.akadns.net TCP ars-master > urd [FIN, ACK]
Seq=1089 Ack=1445 Win=32137 [TCP CHECKSUM INCORRECT] Len=0

Frame 33 (54 bytes on wire, 54 bytes captured)
Arrival Time: May 16, 2008 21:19:17.733782000
[Time delta from previous captured frame: 0.034381000 seconds]
[Time delta from previous displayed frame: 0.034381000 seconds]
[Time since reference or first frame: 4.130872000 seconds]
Frame Number: 33
Frame Length: 54 bytes
Capture Length: 54 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
Ethernet II, Src: flash (ff:ff:ff:ff:ff:ME), Dst: router (ff:ff:ff:ff:ff:RT)
Destination: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: flash (192.168.0.ME), Dst:
smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x5305 (21253)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1c2c [correct]
[Good: True]
[Bad : False]
Source: flash (192.168.0.ME)
Destination: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Transmission Control Protocol, Src Port: ars-master (3176), Dst Port:
urd (465), Seq: 1089, Ack: 1445, Len: 0
Source port: ars-master (3176)
Destination port: urd (465)
Sequence number: 1089 (relative sequence number)
Acknowledgement number: 1445 (relative ack number)
Header length: 20 bytes
Flags: 0x11 (FIN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...1 = Fin: Set
Window size: 32137
Checksum: 0x8bb9 [incorrect, should be 0x921d (maybe caused by "TCP
checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]

0000 00 18 3f 04 28 41 00 1d 60 ea 6b c4 08 00 45 00 ..?.(A..`.k...E.
0010 00 28 53 05 40 00 80 06 1c 2c c0 a8 45 44 45 93 .(S.@....,..EDE.
--snip--
0030 7d 89 8b b9 00 00 }.....

No. Time Source Destination Protocol
Info
34 4.145713 smtp.sbc.mail.yahoo4.akadns.net flash
TCP urd > ars-master [ACK] Seq=1445 Ack=1090 Win=65535 Len=0

Frame 34 (60 bytes on wire, 60 bytes captured)
Arrival Time: May 16, 2008 21:19:17.748623000
[Time delta from previous captured frame: 0.014841000 seconds]
[Time delta from previous displayed frame: 0.014841000 seconds]
[Time since reference or first frame: 4.145713000 seconds]
Frame Number: 34
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: router (ff:ff:ff:ff:ff:RT), Dst: flash (ff:ff:ff:ff:ff:ME)
Destination: flash (ff:ff:ff:ff:ff:ME)
Address: flash (ff:ff:ff:ff:ff:ME)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: router (ff:ff:ff:ff:ff:RT)
Address: router (ff:ff:ff:ff:ff:RT)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31),
Dst: flash (192.168.0.ME)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0xd79c (55196)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xdf94 [correct]
[Good: True]
[Bad : False]
Source: smtp.sbc.mail.yahoo4.akadns.net (69.147.64.31)
Destination: flash (192.168.0.ME)
Transmission Control Protocol, Src Port: urd (465), Dst Port: ars-master
(3176), Seq: 1445, Ack: 1090, Len: 0
Source port: urd (465)
Destination port: ars-master (3176)
Sequence number: 1445 (relative sequence number)
Acknowledgement number: 1090 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x0fa7 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 33]
[The RTT to ACK the segment was: 0.014841000 seconds]

0000 00 1d 60 ea 6b c4 00 18 3f 04 28 41 08 00 45 00 ..`.k...?.(A..E.
0010 00 28 d7 9c 40 00 38 06 df 94 45 93 40 1f c0 a8 .(..@.8...E.@...
0020 45 44 01 d1 0c 68 6b 82 d5 a1 86 81 3e b0 50 10 ED...hk.....>.P.
0030 ff ff 0f a7 00 00 00 00 00 00 00 00 ............

Per Hedeland

unread,

May 17, 2008, 6:59:16 AM5/17/08

to

In article
<d6b54e6b-779b-4b58...@d19g2000prm.googlegroups.com>

"Dave.Anderson-NOSPAM" <dave.and...@gmail.com> writes:
>Well, I do appreciate your help, and I don't mean to come across as
>"throwing up my hands". If anything, I meant to come across as:
>

>-Someone [...]

OK, OK, points taken!:-)

>Now, regarding the portion of your post that contained useful
>troubleshooting experiments, here are the results --

[ all of points 1) - 4) ruled out ]

Too bad - and this also means that there is no point for you to try the
RELAY_MAILER_ARGS setting that worked for "reader" - sendmail just
doesn't have the code in it to act as a client using the SMTPS version
of SSL that is required in your case. RELAY_MAILER_ARGS will come in
handy anyway, but there's a bit more to it...

What you need is the "stunnel" program, that can be set up to
effectively "wrap" any TCP connection in SSL. It can do "unwrapping"
too, and this is probably the most common use case, which may make the
available docs a bit confusing - "wrapping" or client-side is much
simpler to set up than "unwrapping" / server-side (e.g. there is no
*requirement* to configure certificates etc). Basically you will have
"stunnel" listening on a fixed port *on your sendmail host*, configured
to "forward" any connections to your ISP SMTP server at port 465 - and
then you need to configure sendmail to connect to that local port
instead of directly to your ISP's server.

I had a discussion about how to do this here quite a while back, in the
thread that "reader" had dug up - try this link:

http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/1b2e9005f31dde5e

Note that there is some trial-and-error going on in there, you can't
just pick the first solution mentioned for every problem.:-)

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 21, 2008, 7:13:58 PM5/21/08

to

I followed the discussion that you linked and tried the "final" settings
for each thing mentioned. I tried to configure for port 25, since the
clients that I am interested in do not have a configurable SMTP port. no
joy, maybe a quick rundown will help point out where I went wrong:

What I've done:

1) Add the following to sendmail.mc:
define(`SMART_HOST',`smarthost-local')dnl
FEATURE(`authinfo',`hash /etc/mail/auth/client-info')
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5
LOGIN PLAIN')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 25')
define(`ESMTP_MAILER_ARGS', `TCP $h 25')
define(`SMART_HOST',`[127.0.0.1]')

2) Downloaded, compiled and installed stunnel using "--with-ssl" switch.

3) edited tools/stunnel.conf wih the following:

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
debug = 7
output = stunnel.log
client = yes

[rev-smtps]
accept = 127.0.0.1:25
connect = smtp.att.yahoo.com:465

4) Added following line in /etc/hosts, below the "localhost" def:
127.0.0.1 smarthost-local

5) stunnel would not run until I ran it with truss, figured out it was
looking for the conf file in /usr/local/etc/stunnel, and moved the conf
file there(was originally in /etc/stunnel).

6) Additionally I had to do a "mkdir -p /usr/local/var/run/stunnel" so
that it could create its pidfile, after which I was able to get it running.

When I telnet to port 25 on this machine, I get:

ehlo myfake.net
250-ultra.myfake.net Hello flash [192.168.0.ME], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN
250-DELIVERBY
250 HELP

I'm still getting the following in syslog, no joy there:

May 21 16:09:01 ultra sendmail[3756]: [ID 801593 mail.info]
m4HNAk9J020280: to=root, delay=3+23:58:15, xdelay=00:00:00,
mailer=local, pri=474968169, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local

Where to next?

Per Hedeland

unread,

May 22, 2008, 7:53:42 PM5/22/08

to

In article <%02Zj.333$N87...@nlpi068.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>I followed the discussion that you linked and tried the "final" settings
>for each thing mentioned. I tried to configure for port 25, since the
>clients that I am interested in do not have a configurable SMTP port.

Don't do that, i.e. put stunnel on port 25 - the port used there is an
internal affair between sendmail and stunnel, it won't be visible to the
clients, and using port 25 will conflict with sendmail's own usage of
that port - it can be made to work under specific circumstances, but is
just a needless hassle.

>1) Add the following to sendmail.mc:
> define(`SMART_HOST',`smarthost-local')dnl
> FEATURE(`authinfo',`hash /etc/mail/auth/client-info')
> define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5
>LOGIN PLAIN')dnl
> define(`RELAY_MAILER_ARGS', `TCP $h 25')
> define(`ESMTP_MAILER_ARGS', `TCP $h 25')

So change those to, say, 2525 as suggested in the earlier thread.

> define(`SMART_HOST',`[127.0.0.1]')

No point having two SMART_HOST define's, the latter will override the
former. And as mentioned in the thread, sendmail "outsmarts" you if you
use anything in class {w}, i.e. the list of "local host names" - and
[127.0.0.1] is among those, you can verify with:

echo '$=w' | sendmail -bt

So, drop that line, and keep the smarthost-local one.

>3) edited tools/stunnel.conf wih the following:
>
> socket = l:TCP_NODELAY=1
> socket = r:TCP_NODELAY=1
> debug = 7
> output = stunnel.log
> client = yes
>
> [rev-smtps]
> accept = 127.0.0.1:25

And change to 2525 here too of course.

> connect = smtp.att.yahoo.com:465

At this point, before actually going on with sendmail, you can test the
stunnel setup with

telnet localhost 2525

This should give you "cleartext connectivity" to smtp.att.yahoo.com,
i.e. you should see the SMTP greeting, be able to type EHLO and get a
response etc. If this doesn't work, you need to debug the stunnel setup,
no point trying to make sendmail do the same exercise and fail too.

>When I telnet to port 25 on this machine, I get:
>
> ehlo myfake.net
> 250-ultra.myfake.net Hello flash [192.168.0.ME], pleased to meet you
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-8BITMIME
> 250-SIZE
> 250-DSN
> 250-ETRN
> 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN
> 250-DELIVERBY
> 250 HELP

So it seems you're just connecting to your local sendmail server here,
which is what should happen - the question then is if stunnel is able to
accept any connections when you've told it to use the same port.

>I'm still getting the following in syslog, no joy there:
>
>May 21 16:09:01 ultra sendmail[3756]: [ID 801593 mail.info]
>m4HNAk9J020280: to=root, delay=3+23:58:15, xdelay=00:00:00,
>mailer=local, pri=474968169, relay=local, dsn=4.4.2, stat=Deferred:
>Connection reset by local

Unclear what is happening here, but you are apparently trying to send
mail to a local user, i.e. "root". And sendmail (presumably the MSP,
i.e. the one running off of submit.cf) tries to connect to a host called
"local" - what is that? Do you have some non-standard stuff in your
submit.mc? The MSP should normally try to connect to [127.0.0.1] based
on the

FEATURE(`msp', `[127.0.0.1]')dnl

line in the standard submit.mc file shipped with sendmail. In any case
the problem may well relate to your having sendmail and stunnel fight
over the same port, so fix that per above first.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 23, 2008, 4:14:17 AM5/23/08

to

OK, thanks for that help -- some good progress to report:

Per Hedeland wrote:
> In article <%02Zj.333$N87...@nlpi068.nbdc.sbc.com> Dave Anderson
> <r-...@pacbell.net> writes:
>> I followed the discussion that you linked and tried the "final" settings
>> for each thing mentioned. I tried to configure for port 25, since the
>> clients that I am interested in do not have a configurable SMTP port.
>
> Don't do that, i.e. put stunnel on port 25 - the port used there is an
> internal affair between sendmail and stunnel, it won't be visible to the
> clients, and using port 25 will conflict with sendmail's own usage of
> that port - it can be made to work under specific circumstances, but is
> just a needless hassle.

That makes sense. I was initially confused about that, but I get it now.

>
>> define(`RELAY_MAILER_ARGS', `TCP $h 25')
>> define(`ESMTP_MAILER_ARGS', `TCP $h 25')
>
> So change those to, say, 2525 as suggested in the earlier thread.

Done.

>
>> define(`SMART_HOST',`[127.0.0.1]')
>
> No point having two SMART_HOST define's, the latter will override the
> former. And as mentioned in the thread, sendmail "outsmarts" you if you
> use anything in class {w}, i.e. the list of "local host names" - and
> [127.0.0.1] is among those, you can verify with:
>
> echo '$=w' | sendmail -bt
>
> So, drop that line, and keep the smarthost-local one.

Done -- I know better, or I should. Careless editing.

>>
>> [rev-smtps]
>> accept = 127.0.0.1:25
>
> And change to 2525 here too of course.

Done. I've added the stunnel startup file to /etc/init.d, and the
appropriate S* and K* links to /etc/rc[1,2].d. stunnel starts before
sendmail and is killed after sendmail(not sure the order matters, but
that's the way I set it up anyway). stunnel is now listening on 2525:

# netstat -a | grep 2525
localhost.2525 *.* 0 0 24576 0 LISTEN
#

>
>> connect = smtp.att.yahoo.com:465
>
> At this point, before actually going on with sendmail, you can test the
> stunnel setup with
>
> telnet localhost 2525
>
> This should give you "cleartext connectivity" to smtp.att.yahoo.com,
> i.e. you should see the SMTP greeting, be able to type EHLO and get a
> response etc. If this doesn't work, you need to debug the stunnel setup,
> no point trying to make sendmail do the same exercise and fail too.

Looks like this worked as expected:

# telnet localhost 2525
Trying 127.0.0.1...
Connected to localhost.

Escape character is '^]'.

220 smtp119.sbc.mail.sp1.yahoo.com ESMTP
ehlo
250-smtp119.sbc.mail.sp1.yahoo.com

250-AUTH LOGIN PLAIN XYMCOOKIE
250-PIPELINING
250 8BITMIME

>>

>> May 21 16:09:01 ultra sendmail[3756]: [ID 801593 mail.info]
>> m4HNAk9J020280: to=root, delay=3+23:58:15, xdelay=00:00:00,
>> mailer=local, pri=474968169, relay=local, dsn=4.4.2, stat=Deferred:
>> Connection reset by local
>
> Unclear what is happening here, but you are apparently trying to send
> mail to a local user, i.e. "root". And sendmail (presumably the MSP,
> i.e. the one running off of submit.cf) tries to connect to a host called
> "local" - what is that? Do you have some non-standard stuff in your
> submit.mc? The MSP should normally try to connect to [127.0.0.1] based
> on the
>
> FEATURE(`msp', `[127.0.0.1]')dnl
>
> line in the standard submit.mc file shipped with sendmail. In any case
> the problem may well relate to your having sendmail and stunnel fight
> over the same port, so fix that per above first.
>

I think these messages are just "undeliverable mail" messages that are
sitting in /var/spool/mqueue(the files contain undelivered mail, here is
the latest from attempting to send mail after getting stunnel
working(note, aliases.db exists, readable by all):

# cat qfm4N6xCWa004080
V8
T1211525952
K1211530216
N72
P6429663
I0/1/135470
Mhash map "Alias0": missing map file /etc/mail/aliases.db: No such file
or directory
Frs
$_localhost
$r
$slocalhost
${daemon_flags}
${if_addr}127.0.0.1
SMAILER-DAEMON
MDeferred: Connection reset by local
C:postmaster
rRFC822; postm...@ultra.myfake.net
RPFA:root
H?P?Return-Path: <g>
H??Received: from localhost (localhost)
by ultra.myfake.net (8.14.2/8.14.2) id m4N6xCWa004080;
Thu, 22 May 2008 23:59:12 -0700 (PDT)
H?D?Date: Thu, 22 May 2008 23:59:12 -0700 (PDT)
H?F?From: Mail Delivery Subsystem <MAILER-DAEMON>
H?x?Full-Name: Mail Delivery Subsystem
H?M?Message-Id: <200805230659....@ultra.myfake.net>
H??To: postmaster
H??MIME-Version: 1.0
H??Content-Type: multipart/report; report-type=delivery-status;
boundary="m4N6xCWa004080.1211525952/ultra.myfake.net"
H??Subject: Postmaster notify: see transcript for details
H??Auto-Submitted: auto-generated (postmaster-notification)
.
#

submit.mc/cf are out-of-the-box. Below are my submit.mc and updated
sendmail.mc. I am no longer getting the same log message, only:

May 23 00:04:13 ultra sendmail[4115]: [ID 801593 mail.crit]
m4N6xCWa004080: SYSERR(root): hash map "Alias0": missing map file

/etc/mail/aliases.db: No such file or directory

I am not yet able to send mail.

Thanks so much for your help so far. I have a feeling we're close. I
tried to diff the sendmail.cf that was working before(Solaris
distributed sendmail) and the current version, but they were too
different for that to be of any use. I'm going to spend some time later
and compare them side-by-side. Any changes I had made would have been
before the "Message Precedences" section so should be easy enough to
pick out.

Thanks and Regards,

Dave A.

==========================================
# cat submit.mc
divert(-1)
.
.
.
divert(0)dnl
VERSIONID(`$Id: submit.mc,v 8.14 2006/04/05 05:54:41 ca Exp $')
define(`confCF_VERSION', `Submit')dnl
define(`__OSTYPE__',`')dnl dirty hack to keep proto.m4 from complaining
define(`_USE_DECNET_SYNTAX_', `1')dnl support DECnet
define(`confTIME_ZONE', `USE_TZ')dnl
define(`confDONT_INIT_GROUPS', `True')dnl
dnl
dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1]

FEATURE(`msp', `[127.0.0.1]')dnl

==========================================
# cat sendmail.mc
divert(-1)
.
.
.

divert(0)dnl
VERSIONID(`$Id: sendmail.mc,v 8.13 2008/05/29 11:46:30 Dave Exp $')
OSTYPE(solaris8)dnl
DOMAIN(generic)dnl
define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl
FEATURE(`access_db')dnl

define(`SMART_HOST', `smarthost-local')dnl

# this means that ppl can't use the smtp VRFY or EXPN commands
# to look up users email addys on your system :)

define(`confPRIVACY_FLAGS', `authwarnings,goaway')dnl

define(`STATUS_FILE', `/etc/mail/statistics')dnl
define(`confHOST_STATUS_DIRECTORY', `/etc/mail/host_status')dnl

define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN
PLAIN')dnl

FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')

MAILER(local)dnl
MAILER(smtp)dnl
#

Dave Anderson

unread,

May 23, 2008, 1:26:22 PM5/23/08

to

Manual examination of old sendmail.cf vs new sendmail.cf:

Original file has:

Fw-o /etc/mail/sendmail.cw

I see in <src>/cf/README that this has been superseded by:

Fw/etc/mail/local-host-names

local-host-names contains my phony FQDN, ultra.myfake.net

--
Considering adding the following to sendmail.mc(not sure what this is
about, but since I do not have DNS set up on my private network and
ATT/Yahoo does not recognize my hostnames, this seems reasonable:

FEATURE(`accept_unqualified_senders')

--
The following used to be OK -- Maybe I should change this to
smtp.att.yahoo.com?

# cat relay-domains
mail.pacbell.net
#

--
client-info file -- <uname> and <passwd> as entered in T-bird creds field.

# cat client-info
AuthInfo:smtp.att.yahoo.com "U:root" "l:<uname>" "P:<passwd>"
#

--
The following are not in my old sendmail.cf, /etc/mail/check-mail does
not exist and the TLS entry seems to be a reasonable addition:

# access_db acceptance class
C{Accept}OK RELAY

# Resolve map (to check if a host exists in check_mail)
Kresolve host -a<OKR> -T<TEMP>
C{ResOk}OKR

# arithmetic map
Karith arith
# macro storage map
Kmacro macro
# possible values for TLS_connection in access map
C{Tls}VERIFY ENCR

Per Hedeland

unread,

May 23, 2008, 5:21:55 PM5/23/08

to

In article <y1vZj.87$uE5...@flpi144.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>Done. I've added the stunnel startup file to /etc/init.d, and the
>appropriate S* and K* links to /etc/rc[1,2].d. stunnel starts before
>sendmail and is killed after sendmail(not sure the order matters, but
>that's the way I set it up anyway).

It shouldn't matter much, but that's the best order.

>Looks like this worked as expected:
>
># telnet localhost 2525
>Trying 127.0.0.1...
>Connected to localhost.
>Escape character is '^]'.
>220 smtp119.sbc.mail.sp1.yahoo.com ESMTP
>ehlo
>250-smtp119.sbc.mail.sp1.yahoo.com
>250-AUTH LOGIN PLAIN XYMCOOKIE
>250-PIPELINING
>250 8BITMIME

Good!

>I think these messages are just "undeliverable mail" messages that are
>sitting in /var/spool/mqueue

Nevertheless the "relay=local" from your log and the "Deferred:
Connection reset by local" from your queue file below is very strange -
it implies that sendmail is trying to connect to a host called "local"
(and succeeding, but then getting disconnected) to send the message - it
shouldn't do that even if it's just a bounce (which it is). Actually it
seems to be the PostmasterCopy of a bounce, directed at
postm...@ultra.myfake.net - but since you have ultra.myfake.net in
/etc/mail/local-host-names per your other post, that should just work
out to local delivery. And it sort of did per your log, with
mailer=local - but relay=local in combination with that doesn't make
sense... Please try:

sendmail -bv postm...@ultra.myfake.net

> (note, aliases.db exists, readable by all):

>Mhash map "Alias0": missing map file /etc/mail/aliases.db: No such file
>or directory

Hm, there's definitely something wrong there - in some cases non-obvious
permission issues may make sendmail refuse to read the file, but it
won't say "No such file or directory" in those cases. Are you *sure*
that you have aliases.db and not actually aliases.pag + aliases.dir
(i.e. NDBM files), seeing as that's what Solaris used to use. And that
it is in /etc/mail. And that it was generated from the cleartext file by
the version of sendmail you're currently running. Do a 'sendmail -bi'
just to rule out those possible problem causes.

But in any case these issues seem to have nothing to do with your
SSL/stunnel setup, that hasn't even come into play yet...

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 24, 2008, 2:29:46 AM5/24/08

to

More good progress, leading to the next set of issues...

>> I think these messages are just "undeliverable mail" messages that are
>> sitting in /var/spool/mqueue
>
> Nevertheless the "relay=local" from your log and the "Deferred:
> Connection reset by local" from your queue file below is very strange -
> it implies that sendmail is trying to connect to a host called "local"
> (and succeeding, but then getting disconnected) to send the message - it
> shouldn't do that even if it's just a bounce (which it is). Actually it
> seems to be the PostmasterCopy of a bounce, directed at
> postm...@ultra.myfake.net - but since you have ultra.myfake.net in
> /etc/mail/local-host-names per your other post, that should just work
> out to local delivery. And it sort of did per your log, with
> mailer=local - but relay=local in combination with that doesn't make
> sense... Please try:
>
> sendmail -bv postm...@ultra.myfake.net

That gives me:

# /usr/lib/sendmail -bv postm...@ultra.myfake.net

hash map "Alias0": missing map file /etc/mail/aliases.db: No such file
or directory

root... deliverable: mailer local, user root
#

>
>> (note, aliases.db exists, readable by all):
>
>> Mhash map "Alias0": missing map file /etc/mail/aliases.db: No such file
>> or directory
>
> Hm, there's definitely something wrong there - in some cases non-obvious
> permission issues may make sendmail refuse to read the file, but it
> won't say "No such file or directory" in those cases. Are you *sure*
> that you have aliases.db and not actually aliases.pag + aliases.dir
> (i.e. NDBM files), seeing as that's what Solaris used to use. And that
> it is in /etc/mail. And that it was generated from the cleartext file by
> the version of sendmail you're currently running. Do a 'sendmail -bi'
> just to rule out those possible problem causes.

sendmail -bi returned the following:

# /usr/lib/sendmail -bi
newaliases: cannot open /etc/mail/aliases: No such file or directory
#

Turns out I had made one of those in-a-hurry typos, it was named
alaises. Ugh. Sorry about the wild goose chase.

# makemap hash /etc/mail/aliases.db < /etc/mail/aliases
# /usr/lib/sendmail -bi
/etc/mail/aliases: 25 aliases, longest 10 bytes, 279 bytes total
# file aliases*
aliases: English text
aliases.db: data
aliases.dir: empty file
aliases.pag: text
# /usr/lib/sendmail -bv postm...@ultra.myfake.net
root... deliverable: mailer local, user root
# mail
No mail.

I left the older files in case they may be of use reconstructing what
"worked" before. For example, I find it curious that aliases.pag
contained, after some gibberish, the string
/dev/nullnobodypostmastermailer-daemonrootpostmaster yet there is no
reference to /dev/null in my current aliases file(default contents).

I ran a couple of CGI scripts after this to see if they could send mail,
no message was received at the destination address OR locally(no bounce
message). I ran "truss mail" and from the output below I can see that
it's looking in what seem to be the right places for mail; the mail is
just not getting to the mailbox(Assuming my current config is not
disallowing bounced messages somehow).

stat("/var/mail/:saved/root", 0xFFBEF230) Err#2 ENOENT
ioctl(1, TCGETA, 0xFFBEED1C) = 0
access("/var/mail/root", 0) Err#2 ENOENT
getgid() = 1 [6]
getgid() = 1 [6]
setegid(1) = 0
open("/var/mail/root", O_RDONLY) Err#2 ENOENT
setegid(6) = 0
ioctl(1, TCGETA, 0xFFBEDF9C) = 0
No mail.
write(1, " N o m a i l .\n", 9) = 9
lstat64("", 0xFFBEF960) Err#2 ENOENT
llseek(0, 0, SEEK_CUR) = 365897
_exit(1)
#

>
> But in any case these issues seem to have nothing to do with your
> SSL/stunnel setup, that hasn't even come into play yet...
>

Yes, while having the local mailer & mail program work will provide
useful info when messages bounce, I haven't lost sight of the goal. :)

I was thinking of starting a new thread for the local mailer issue and
keeping this one focused on the relay issue, but since all of this
discussion is related to problems encountered on the path of ditching
the Sun sendmail, compiling an updated version and putting it back in
shape, I guess it's all on-topic. :D

BTW, I really appreciate you sticking with this problem. The further I
dig in it seems that sendmail is not so much ridiculously complicated as
it is ridiculously obfuscated. :) I still have not found a comprehensive
list of what .mc entries will impact particular .cf entries, but I'm
figuring out the important ones a bit at a time.

Dave Anderson

unread,

May 24, 2008, 10:41:36 AM5/24/08

to

Another interesting datapoint:

# mail root
test
.
ld.so.1: sendmail: fatal: libsasl2.so.2: open failed: No such file or
directory
mail: ERROR signal 13
#

Yet, that sasl lib may be found in the libpath that is in effect when
sendmail is started, in /usr/local/lib. Curious.

lrwxrwxrwx 1 root other 18 May 13 21:48 libsasl2.so.2 ->
libsasl2.so.2.0.22
-rwxr-xr-x 1 root other 168192 May 13 21:48 libsasl2.so.2.0.22

Per Hedeland

unread,

May 24, 2008, 2:54:29 PM5/24/08

to

In article <2BOZj.373$Ri....@flpi146.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>>
>> sendmail -bv postm...@ultra.myfake.net
>
>That gives me:
>
># /usr/lib/sendmail -bv postm...@ultra.myfake.net
>hash map "Alias0": missing map file /etc/mail/aliases.db: No such file
>or directory
>root... deliverable: mailer local, user root
>#

Well, at least the final result looks fine.

>Turns out I had made one of those in-a-hurry typos, it was named
>alaises. Ugh. Sorry about the wild goose chase.

OK.

># makemap hash /etc/mail/aliases.db < /etc/mail/aliases

Do *not* do that - the aliases map must be rebuilt with newaliases
a.k.a. sendmail -bi, not makemap. I suggested sendmail -bi since if you
are messing about with multiple sendmail versions, there's some risk
that newaliases is linked to the wrong one - I believe Solaris puts it
in /usr/sbin while the standard sendmail install puts it in /usr/bin).

># /usr/lib/sendmail -bi
>/etc/mail/aliases: 25 aliases, longest 10 bytes, 279 bytes total

So that repaired the damage done above...

>I ran a couple of CGI scripts after this to see if they could send mail,

Uh, the "big bang" testing philosophy...:-) - doesn't hurt to try, but
in this case I think you'd better get the basics working first.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 24, 2008, 3:02:22 PM5/24/08

to

In article <HOVZj.1755$jI5....@flpi148.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
># mail root
>test
>.
>ld.so.1: sendmail: fatal: libsasl2.so.2: open failed: No such file or
>directory

That certainly explains some of your failures...

>Yet, that sasl lib may be found in the libpath that is in effect when
>sendmail is started, in /usr/local/lib. Curious.

What do you mean by "the libpath that is in effect"? Are you setting
environment LD_LIBRARY_PATH to make sendmail find the library? That's a
hack at best, and doesn't work at all in this case since 'mail' and
other "simplistic" MUAs invoke sendmail directly (the MSP
functionality), and as sendmail is set-gid, no LD_ environment variables
are honoured, for obvious security reasons.

You need to specify any non-standard directories with the -R option when
you build sendmail on Solaris - or you can fix it after the fact with
crle(1), but it'll come back and bite you when you rebuild.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 24, 2008, 8:24:19 PM5/24/08

to

> You need to specify any non-standard directories with the -R option when
> you build sendmail on Solaris - or you can fix it after the fact with
> crle(1), but it'll come back and bite you when you rebuild.
>

Not sure what you mean by the "-R option" -- I can't find a usage
example anywhre for that, and experimenting with it didn't get me very
far...

# sh ./Build -R /usr/local/lib

Configuration: pfx=, os=SunOS, rel=5.8, rbase=5, rroot=5.8, arch=sun4,
sfx=, variant=optimized

Making in
/export/home/swinst/sendmail.Mar.08/install/sendmail-8.14.2/obj.SunOS.5.8.sun4/sendmail
make: Nothing to be done for `/usr/local/lib'.
# sh ./Build -R/usr/local/lib

Configuration: pfx=, os=SunOS, rel=5.8, rbase=5, rroot=5.8, arch=sun4,
sfx=, variant=optimized

Making in
/export/home/swinst/sendmail.Mar.08/install/sendmail-8.14.2/obj.SunOS.5.8.sun4/sendmail
make: invalid option -- /
make: invalid option -- u
make: invalid option -- /
Usage: make [options] [target] ...
Options:
-b, -m Ignored for compatibility.
-B, --always-make Unconditionally make all targets.
-C DIRECTORY, --directory=DIRECTORY
Change to DIRECTORY before doing anything.
-d Print lots of debugging information.
--debug[=FLAGS] Print various types of debugging information.
-e, --environment-overrides
Environment variables override makefiles.
-f FILE, --file=FILE, --makefile=FILE
Read FILE as a makefile.
-h, --help Print this message and exit.
-i, --ignore-errors Ignore errors from commands.
-I DIRECTORY, --include-dir=DIRECTORY
Search DIRECTORY for included makefiles.
-j [N], --jobs[=N] Allow N jobs at once; infinite jobs with
no arg.
-k, --keep-going Keep going when some targets can't be made.
-l [N], --load-average[=N], --max-load[=N]
Don't start multiple jobs unless load is
below N.
-L, --check-symlink-times Use the latest mtime between symlinks and
target.
-n, --just-print, --dry-run, --recon
Don't actually run any commands; just
print them.
-o FILE, --old-file=FILE, --assume-old=FILE
Consider FILE to be very old and don't
remake it.
-p, --print-data-base Print make's internal database.
-q, --question Run no commands; exit status says if up
to date.
-r, --no-builtin-rules Disable the built-in implicit rules.
-R, --no-builtin-variables Disable the built-in variable settings.
-s, --silent, --quiet Don't echo commands.
-S, --no-keep-going, --stop
Turns off -k.
-t, --touch Touch targets instead of remaking them.
-v, --version Print the version number of make and exit.
-w, --print-directory Print the current directory.
--no-print-directory Turn off -w, even if it was turned on
implicitly.
-W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
Consider FILE to be infinitely new.
--warn-undefined-variables Warn when an undefined variable is
referenced.

This program built for sparc-sun-solaris2.8
Report bugs to <bug-...@gnu.org>

Dave Anderson

unread,

May 24, 2008, 8:26:33 PM5/24/08

to

>
>> # makemap hash /etc/mail/aliases.db < /etc/mail/aliases
>
> Do *not* do that - the aliases map must be rebuilt with newaliases
> a.k.a. sendmail -bi, not makemap. I suggested sendmail -bi since if you
> are messing about with multiple sendmail versions, there's some risk
> that newaliases is linked to the wrong one - I believe Solaris puts it
> in /usr/sbin while the standard sendmail install puts it in /usr/bin).
>
>> # /usr/lib/sendmail -bi
>> /etc/mail/aliases: 25 aliases, longest 10 bytes, 279 bytes total
>
> So that repaired the damage done above...

Thanks for the tips. All of the documentation says use makemap, I
appreciate the safer alternative.

>
>> I ran a couple of CGI scripts after this to see if they could send mail,
>
> Uh, the "big bang" testing philosophy...:-) - doesn't hurt to try, but
> in this case I think you'd better get the basics working first.

Exactly -- doesn't hurt, and sometimes useful error messages come up
when trying different things -- like finding that /usr/local/lib isn't
being searched.

Clemens Zauner

unread,

May 25, 2008, 8:24:26 AM5/25/08

to

Dave Anderson <r-...@pacbell.net> wrote:
> Not sure what you mean by the "-R option" -- I can't find a usage
> example anywhre for that, and experimenting with it didn't get me very
> far...
>
> # sh ./Build -R /usr/local/lib

No. goes to site-comfig.m4. Example:

APPENDDEF(`confLIBDIRS', `-L/usr/local/lib -R/usr/local/lib')

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Dave Anderson

unread,

May 25, 2008, 11:39:53 AM5/25/08

to

Clemens Zauner wrote:
> Dave Anderson <r-...@pacbell.net> wrote:
>> Not sure what you mean by the "-R option" -- I can't find a usage
>> example anywhre for that, and experimenting with it didn't get me very
>> far...
>>
>> # sh ./Build -R /usr/local/lib
>
> No. goes to site-comfig.m4. Example:
>
> APPENDDEF(`confLIBDIRS', `-L/usr/local/lib -R/usr/local/lib')
>
> cu
> Clemens.

Thanks for that -- after a "Build -c", "Build install", and sendmail
stop/start the lib message has been resolved, to be replaced with:

# mail root
ugh
.
May 25 08:16:41 ultra sendmail[14825]: [ID 801593 mail.alert]
m4PFGfsY014825: Losing ./qfm4PFGfsY014825: savemail panic
# mailq -qL
/var/spool/mqueue is empty
Total requests: 0
#

syslog has a bit more information:

May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.alert]
m4PFSjoR014847: Losing ./qfm4PFSjoR014847: savemail panic
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
m4PFSjoQ014847: from=root, size=103, class=0, nrcpts=1,
msgid=<200805251528....@ultra.myfake.net>, relay=root@localhost
May 25 08:28:45 ultra sendmail[14848]: [ID 702911 mail.notice]
ruleset=check_relay, arg1=localhost, arg2=127.0.0.1, relay=localhost
[127.0.0.1], reject=550 5.7.1 Access denied
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
m4PFSjoQ014847: to=root, ctladdr=root (0/1), delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=30103, relay=[127.0.0.1] [127.0.0.1],
dsn=5.0.0, stat=Service unavailable
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
m4PFSjoQ014847: m4PFSjoR014847: DSN: Service unavailable
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
m4PFSjoR014847: to=root, delay=00:00:00, xdelay=00:00:00, mailer=relay,
pri=31127, relay=[127.0.0.1], dsn=5.0.0, stat=Service unavailable
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
m4PFSjoR014847: m4PFSjoS014847: return to sender: Service unavailable
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
m4PFSjoS014847: to=postmaster, delay=00:00:00, xdelay=00:00:00,
mailer=relay, pri=32151, relay=[127.0.0.1], dsn=5.0.0, stat=Service
unavailable
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.alert]
m4PFSjoR014847: Losing ./qfm4PFSjoR014847: savemail panic
May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.crit]
m4PFSjoR014847: SYSERR(root): savemail: cannot save rejected email anywhere

my aliases file is out-of-the-box; unmodified:

#
# $Id: aliases,v 8.5 2002/06/05 22:54:26 gshapiro Exp $
# @(#)aliases 8.2 (Berkeley) 3/5/94
#
# Aliases in this file will NOT be expanded in the header from
# Mail, but WILL be visible over networks.
#
# >>>>>>>>>> The program "newaliases" must be run after
# >> NOTE >> this file is updated for any changes to
# >>>>>>>>>> show through to sendmail.
#
#
# See also RFC 2142, `MAILBOX NAMES FOR COMMON SERVICES, ROLES
# AND FUNCTIONS', May 1997

# Pretty much everything else in this file points to "root", so
# you should forward root's email to the system administrator.
# Delivering mail to root's mailbox or reading mail as root is
# inadvisable.

# Uncomment and *CHANGE* this!
# root: insert-human-being-here

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root

# General redirections for pseudo accounts
bin: root
daemon: root
games: root
mailnull: postmaster
smmsp: postmaster
ingres: root
nobody: root
system: root
toor: root

# Well-known aliases
manager: root
dumper: root
operator: root

# RFC 2142: BUSINESS-RELATED MAILBOX NAMES
# info: root
# marketing: root
# sales: root
# support: root

# RFC 2142: NETWORK OPERATIONS MAILBOX NAMES
abuse: root
noc: root
security: root

# RFC 2142: SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
hostmaster: root
usenet: root
news: usenet
webmaster: root
www: webmaster
uucp: root
ftp: root

# Trap decode to catch security attacks
decode: root

I really appreciate the help of experts on this. Just when you think you
have a good handle on Solaris, having compiled/installed a bunch of
different stuff including KDE, apache, and lots of GNU utilities,
something like this comes along -- it's very humbling. :/

Regards,

Dave A.

Per Hedeland

unread,

May 25, 2008, 11:41:35 AM5/25/08

to

In article <4n2_j.334$89....@nlpi069.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>>
>>> # makemap hash /etc/mail/aliases.db < /etc/mail/aliases
>>
>> Do *not* do that - the aliases map must be rebuilt with newaliases
>> a.k.a. sendmail -bi, not makemap. I suggested sendmail -bi since if you
>> are messing about with multiple sendmail versions, there's some risk
>> that newaliases is linked to the wrong one - I believe Solaris puts it
>> in /usr/sbin while the standard sendmail install puts it in /usr/bin).
>>
>>> # /usr/lib/sendmail -bi
>>> /etc/mail/aliases: 25 aliases, longest 10 bytes, 279 bytes total
>>
>> So that repaired the damage done above...
>
>Thanks for the tips. All of the documentation says use makemap, I
>appreciate the safer alternative.

Hm, hopefully *no* documentation says to use makemap to rebuild the
aliases map. E.g. to quote the makemap(8) man page:

Notice: do *not* use _makemap_ to create the aliases data base, but
_newaliases_ which puts a special token into the data base that is
required by sendmail.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 25, 2008, 11:58:27 AM5/25/08

to

>
> Hm, hopefully *no* documentation says to use makemap to rebuild the
> aliases map. E.g. to quote the makemap(8) man page:
>
> Notice: do *not* use _makemap_ to create the aliases data base, but
> _newaliases_ which puts a special token into the data base that is
> required by sendmail.
>
> --Per Hedeland
> p...@hedeland.org

Not sure exactly where I got that -- I think it was here:
http://www.faqs.org/docs/securing/chap22sec179.html Also, there are many
other web pages that suggest that.

In a perfect world, I would find the time to thoroughly read and absorb
all relevant documentation, but I have not been able to find the time to
do so. When I try, for example going through cf/README, it seems that I
end up digging through page after page of stuff that is not relevant,
get frustrated, and fall back to Google.

I am tracking my progress though, and once all is sorted out I intend to
post a synopsis as a direct reply to the top of the thread in hopes that
I may ease the pain of the next amateur that has to go through this. :)

Per Hedeland

unread,

May 25, 2008, 7:14:01 PM5/25/08

to

In article <lLf_j.2377$xZ....@nlpi070.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>syslog has a bit more information:
>
>May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.alert]
>m4PFSjoR014847: Losing ./qfm4PFSjoR014847: savemail panic
>May 25 08:28:45 ultra sendmail[14847]: [ID 801593 mail.info]
>m4PFSjoQ014847: from=root, size=103, class=0, nrcpts=1,
>msgid=<200805251528....@ultra.myfake.net>, relay=root@localhost
>May 25 08:28:45 ultra sendmail[14848]: [ID 702911 mail.notice]
>ruleset=check_relay, arg1=localhost, arg2=127.0.0.1, relay=localhost
>[127.0.0.1], reject=550 5.7.1 Access denied

Your MTA is rejecting messages from your MSP, not a good idea...
What's in your access db?

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 25, 2008, 7:17:46 PM5/25/08

to

In article <K0g_j.2379$xZ....@nlpi070.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>>
>> Hm, hopefully *no* documentation says to use makemap to rebuild the
>> aliases map. E.g. to quote the makemap(8) man page:
>>
>> Notice: do *not* use _makemap_ to create the aliases data base, but
>> _newaliases_ which puts a special token into the data base that is
>> required by sendmail.
>>
>

>Not sure exactly where I got that -- I think it was here:
>http://www.faqs.org/docs/securing/chap22sec179.html Also, there are many
>other web pages that suggest that.
>
>In a perfect world, I would find the time to thoroughly read and absorb
>all relevant documentation, but I have not been able to find the time to
>do so. When I try, for example going through cf/README, it seems that I
>end up digging through page after page of stuff that is not relevant,
>get frustrated, and fall back to Google.

OK, but please don't refer to the ramblings of some ignorant 3rd party
as "the documentation".

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 25, 2008, 10:03:54 PM5/25/08

to

>
> OK, but please don't refer to the ramblings of some ignorant 3rd party
> as "the documentation".
>

Fair enough.

Dave Anderson

unread,

May 25, 2008, 10:24:53 PM5/25/08

to

As follows... I don't think I was able to find what I was looking for by
searching for "access" in the official PDF doc or sendmail.org's "tips"
page so I dredged this up from the internet.

# cat access
# Default is to reject. 'user@' is actually user@*
# Likewise, 192.168 is actualy 192.168.*.*
#
# WHAT ACTION
#
# When actually sending from localhost it uses the IP. Spammers will
# take advantage of 'localhost' though
localhost REJECT
127.0.0.1 RELAY

* RELAY

# We also are going by IP Addresses
192.168.69.* RELAY

#

Per Hedeland

unread,

May 26, 2008, 2:09:45 AM5/26/08

to

In article <0cp_j.2025$jI5....@flpi148.ffdc.sbc.com> Dave Anderson
<r-...@pacbell.net> writes:

>Per Hedeland wrote:
>>
>> Your MTA is rejecting messages from your MSP, not a good idea...
>> What's in your access db?
>>
>
>As follows... I don't think I was able to find what I was looking for by
>searching for "access" in the official PDF doc or sendmail.org's "tips"
>page so I dredged this up from the internet.

># When actually sending from localhost it uses the IP. Spammers will

># take advantage of 'localhost' though
>localhost REJECT

So this line is the problem. I'm not sure what you're trying to achieve
here (maybe you aren't either) - it doesn't matter what the client
"uses" to make the connection, in fact a server can't possibly know
that, and sendmail will look for matching entries both for the IP
address (which it always knows) and for the result of reverse-lookup
(PTR) of that IP address - but the latter is only done if also the
forward-lookup (A/AAAA) of the PTR result is successful *and* includes
the original IP address in *its* result.

So, as far as connect-time checking of the client host (i.e. entries
that would be best tagged with "Connect:") is concerned, a 'localhost'
entry will only match for clients that have an IP address included in
the result of a lookup of 'localhost' on your host - hopefully the only
address returned by that is 127.0.0.1 (possibly the IPv6 ::1 equivalent
too), otherwise you need to fix *that*. And all this entry does is then
to block connections from the local host, just as if you had a REJECT
entry for 127.0.0.1.

Take it out.

>127.0.0.1 RELAY

You can take that one out to, since anything in class $={w} (which
includes both 127.0.0.1 and the name it reverse-resolves to) is allowed
to relay by default.

>* RELAY

Thankfully asterisks don't match anything at all in access db, otherwise
this line might get you in big trouble. Take it out.

># We also are going by IP Addresses
>192.168.69.* RELAY

You want

Connect:192.168.69 RELAY

for this. Assuming that you're actually using 192.168.69.xx addresses on
your local network, that is.

A general comment: The default sendmail setup is quite secure - it
doesn't really make sense to put *anything* in access db until you have
basic mail functionality working. Once you have that, you generally need
to loosen things up a bit (like in the last entry above) to get
everything you need working. *Then* you can perhaps start putting in
restrictions to deal with spam, carefully checking what you break at
each point.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 26, 2008, 4:24:41 AM5/26/08

to

>
>> # When actually sending from localhost it uses the IP. Spammers will
>> # take advantage of 'localhost' though
>> localhost REJECT
>
> So this line is the problem.

I had tried setting this to "RELAY" after posting -- obviously more to
the story though.

> I'm not sure what you're trying to achieve
> here (maybe you aren't either)

Actually, I'm not. I saw a number of examples with that and it wasn't
until earlier this evening that I began to really dig into the docs a
bit on this.

- it doesn't matter what the client
> "uses" to make the connection, in fact a server can't possibly know
> that, and sendmail will look for matching entries both for the IP
> address (which it always knows) and for the result of reverse-lookup
> (PTR) of that IP address - but the latter is only done if also the
> forward-lookup (A/AAAA) of the PTR result is successful *and* includes
> the original IP address in *its* result.
>
> So, as far as connect-time checking of the client host (i.e. entries
> that would be best tagged with "Connect:") is concerned, a 'localhost'
> entry will only match for clients that have an IP address included in
> the result of a lookup of 'localhost' on your host - hopefully the only
> address returned by that is 127.0.0.1 (possibly the IPv6 ::1 equivalent
> too), otherwise you need to fix *that*.

That's good, below are the /etc/hosts entries that pertain to this machine:

127.0.0.1 localhost
127.0.0.1 smarthost-local
192.168.69.x ultra ultra.myfake.net loghost

> And all this entry does is then
> to block connections from the local host, just as if you had a REJECT
> entry for 127.0.0.1.
>
> Take it out.
>

.
.
.

RELAY
>
> You want
>
> Connect:192.168.69 RELAY
>
> for this. Assuming that you're actually using 192.168.69.xx addresses on
> your local network, that is.

Yes I am. So it seems that's the only line that I really need(if any)...
interesting. I believe I had put the lone asterisk in while testing.

>
> A general comment: The default sendmail setup is quite secure - it
> doesn't really make sense to put *anything* in access db until you have
> basic mail functionality working. Once you have that, you generally need
> to loosen things up a bit (like in the last entry above) to get
> everything you need working. *Then* you can perhaps start putting in
> restrictions to deal with spam, carefully checking what you break at
> each point.
>
> --Per Hedeland
> p...@hedeland.org

So, with access cleared out(everything commented) and having run makemap
against it(I have compiled and installed the makemap that came with this
sendmail source, and verified that is the version I am using) I am still
getting mail errors. I get the following in syslog upon starting
sendmail then running "mail root<cr>Another Test<cr>.<cr>"

May 26 01:00:55 ultra sendmail[17608]: [ID 702911 mail.info] starting
daemon (8.14.2): SMTP+queueing@00:01:00
May 26 01:01:27 ultra sendmail[17611]: [ID 801593 mail.info]
m4Q81RUu017611: from=root, size=113, class=0, nrcpts=1,
msgid=<200805260801....@ultra.myfake.net>, relay=root@localhost
May 26 01:01:28 ultra sendmail[17612]: [ID 801593 mail.info]
m4Q81Roi017612: from=<ro...@ultra.myfake.net>, size=345, class=0,
nrcpts=1, msgid=<200805260801....@ultra.myfake.net>,
proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
May 26 01:01:28 ultra sendmail[17611]: [ID 801593 mail.info]
m4Q81RUu017611: to=root, ctladdr=root (0/1), delay=00:00:01,
xdelay=00:00:01, mailer=relay, pri=30113, relay=[127.0.0.1] [127.0.0.1],
dsn=2.0.0, stat=Sent (m4Q81Roi017612 Message accepted for delivery)
May 26 01:01:28 ultra sendmail[17613]: [ID 801593 mail.error]
m4Q81Roi017612: smtpquit: mailer local exited with exit value 5
May 26 01:01:28 ultra sendmail[17613]: [ID 801593 mail.info]
m4Q81Roi017612: to=<ro...@ultra.myfake.net>,
ctladdr=<ro...@ultra.myfake.net> (0/1), delay=00:00:01, xdelay=00:00:00,
mailer=local, pri=30567, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local

Then the following when the queue is processed.

May 26 01:01:55 ultra sendmail[17615]: [ID 801593 mail.error]
m4Q81Roi017612: smtpquit: mailer local exited with exit value 5
May 26 01:01:55 ultra sendmail[17615]: [ID 801593 mail.info]
m4Q81Roi017612: to=<ro...@ultra.myfake.net>,
ctladdr=<ro...@ultra.myfake.net> (0/1), delay=00:00:28, xdelay=00:00:00,
mailer=local, pri=120567, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local

I'm wondering if the "myfake.net" is necessary. As I recall, it was
needed with the Sun sendmail because it somehow needed more than a bare
hostname. I have no such domain set up. Am I shooting myself in the foot
with this? I tried adding the bare hostname to local-host-names, with
the same result.

Dave Anderson

unread,

May 26, 2008, 4:34:18 AM5/26/08

to

Another data point:

# date | /usr/lib/sendmail -v nob...@another.domain
nob...@another.domain... Connecting to [127.0.0.1] via relay...
220 ultra.myfake.net ESMTP Sendmail 8.14.2/8.14.2; Mon, 26 May 2008
01:28:43 -0700 (PDT)
>>> EHLO ultra.myfake.net
250-ultra.myfake.net Hello localhost [127.0.0.1], pleased to meet you

250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN
250-DELIVERBY
250 HELP

>>> MAIL From:<ro...@ultra.myfake.net> SIZE=29 AUTH=ro...@ultra.myfake.net
250 2.1.0 <ro...@ultra.myfake.net>... Sender ok
>>> RCPT To:<nob...@another.domain>
>>> DATA
250 2.1.5 <nob...@another.domain>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 m4Q8Shm8017710 Message accepted for delivery
nob...@another.domain... Sent (m4Q8Shm8017710 Message accepted for delivery)

Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 ultra.myfake.net closing connection

This is what gets written to syslog:

May 26 01:31:59 ultra sendmail[17725]: [ID 801593 mail.info]
m4Q8Vwfk017725: from=root, size=29, class=0, nrcpts=1,
msgid=<200805260831....@ultra.myfake.net>, relay=root@localhost
May 26 01:32:00 ultra sendmail[17726]: [ID 801593 mail.info]
m4Q8VxMA017726: from=<ro...@ultra.myfake.net>, size=334, class=0,
nrcpts=1, msgid=<200805260831....@ultra.myfake.net>,
proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
May 26 01:32:00 ultra sendmail[17725]: [ID 801593 mail.info]
m4Q8Vwfk017725: to=nob...@another.domain, ctladdr=root (0/1),
delay=00:00:02, xdelay=00:00:01, mailer=relay, pri=30029,
relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (m4Q8VxMA017726
Message accepted for delivery)
May 26 01:32:01 ultra sendmail[17728]: [ID 801593 mail.info]
m4Q8VxMA017726: to=<nob...@another.domain>,
ctladdr=<ro...@ultra.myfake.net> (0/1), delay=00:00:01, xdelay=00:00:01,
mailer=relay, pri=120334, relay=smarthost-local.myfake.net., dsn=4.0.0,
stat=Deferred: Connection timed out with smarthost-local.myfake.net.

So it DOES seem to be adding "myfake.net" to smarthost-local -- this
can't be good???

Regards,

Dave A.

Dave Anderson

unread,

May 26, 2008, 12:05:58 PM5/26/08

to

So, I enabled logging like so:

/usr/lib/sendmail -bd -X /var/log/mail.log -oL9 &

I was seeing mail.local complain about an invalid argument:

# cat /var/log/mail.log
19456 === EXEC mail.local -l
19456 <<< mail.local: illegal option -- l
19456 <<< mail.local: Usage: [-ehpPqr] [-f file] [-x debuglevel]
19456 <<< or [-tw] [-m message_type] [-T file] [-x debuglevel] persons
19456 <<< or [-x debuglevel]
19456 <<< [EOF]
19456 === EXEC mail.local -l
19456 <<< mail.local: illegal option -- l
19456 <<< mail.local: Usage: [-ehpPqr] [-f file] [-x debuglevel]
19456 <<< or [-tw] [-m message_type] [-T file] [-x debuglevel] persons
19456 <<< or [-x debuglevel]
19456 <<< [EOF]

This led me to find the -l arg; it was in sendmail.cf:

Mlocal, P=/usr/bin/mail, F=lsDFMAw5:/|@qPSXmnz9,
S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/SMTP,
A=mail.local -l

So I removed the -l, with the following results -- not a fix, but now I
am not getting the error in /var/log/mail.log and the syslog is showing:

smtpquit: mailer local exited with exit value 1

instead of

smtpquit: mailer local exited with exit value 5

==========================================================

# mail root
To: root
From: root

Testing without -l
.
# cat /var/log/mail.log
19514 === EXEC mail.local
19514 <<< No mail.
19514 <<< [EOF]
19514 === EXEC mail.local
19514 <<< No mail.
19514 <<< [EOF]
19514 === EXEC mail.local
19514 <<< No mail.
19514 <<< [EOF]
19514 === EXEC mail.local
19514 <<< No mail.
19514 <<< [EOF]
19531 >>> 220 ultra.myfake.net ESMTP Sendmail 8.14.2/8.14.2; Mon, 26 May
2008 08:25:30 -0700 (PDT)
19531 <<< EHLO ultra.myfake.net
19531 >>> 250-ultra.myfake.net Hello localhost [127.0.0.1], pleased to
meet you
19531 >>> 250-ENHANCEDSTATUSCODES
19531 >>> 250-PIPELINING
19531 >>> 250-8BITMIME
19531 >>> 250-SIZE
19531 >>> 250-DSN
19531 >>> 250-ETRN
19531 >>> 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN
19531 >>> 250-DELIVERBY
19531 >>> 250 HELP
19531 <<< MAIL From:<ro...@ultra.myfake.net> SIZE=139
AUTH=ro...@ultra.myfake.net
19531 >>> 250 2.1.0 <ro...@ultra.myfake.net>... Sender ok
19531 <<< RCPT To:<ro...@ultra.myfake.net>
19531 >>> 250 2.1.5 <ro...@ultra.myfake.net>... Recipient ok
19531 <<< DATA
19531 >>> 354 Enter mail, end with "." on a line by itself
19531 <<< Received: (from root@localhost)
19531 <<< by ultra.myfake.net (8.14.2/8.14.2/Submit) id m4QFPU6h019530
19531 <<< for root; Mon, 26 May 2008 08:25:30 -0700 (PDT)
19531 <<< Date: Mon, 26 May 2008 08:25:30 -0700 (PDT)
19531 <<< Message-Id: <200805261525....@ultra.myfake.net>
19531 <<< To: ro...@ultra.myfake.net
19531 <<< From: ro...@ultra.myfake.net
19531 <<< MIME-Version: 1.0
19531 <<< Content-Type: text/plain
19531 <<<
19531 <<< Testing without -l
19531 <<<
19531 <<< .
19531 >>> 250 2.0.0 m4QFPUt4019531 Message accepted for delivery
19532 === EXEC mail.local
19532 <<< No mail.
19532 <<< [EOF]
19531 <<< QUIT
19531 >>> 221 2.0.0 ultra.myfake.net closing connection

And in syslog:

May 26 08:25:04 ultra sendmail[19527]: [ID 702911 mail.info] starting

daemon (8.14.2): SMTP+queueing@00:01:00

May 26 08:25:30 ultra sendmail[19530]: [ID 801593 mail.info]
m4QFPU6h019530: from=root, size=139, class=0, nrcpts=1,
msgid=<200805261525....@ultra.myfake.net>, relay=root@localhost
May 26 08:25:30 ultra sendmail[19531]: [ID 801593 mail.info]
m4QFPUt4019531: from=<ro...@ultra.myfake.net>, size=364, class=0,
nrcpts=1, msgid=<200805261525....@ultra.myfake.net>,
proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
May 26 08:25:30 ultra sendmail[19530]: [ID 801593 mail.info]
m4QFPU6h019530: to=root, ctladdr=root (0/1), delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=30139, relay=[127.0.0.1] [127.0.0.1],
dsn=2.0.0, stat=Sent (m4QFPUt4019531 Message accepted for delivery)
May 26 08:25:30 ultra sendmail[19532]: [ID 801593 mail.error]
m4QFPUt4019531: smtpquit: mailer local exited with exit value 1
May 26 08:25:30 ultra sendmail[19532]: [ID 801593 mail.info]
m4QFPUt4019531: to=<ro...@ultra.myfake.net>,
ctladdr=<ro...@ultra.myfake.net> (0/1), delay=00:00:00, xdelay=00:00:00,
mailer=local, pri=30585, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local

I went back to having the -l arg in sendmail.cf -- Obviously I should
not be editing that file, and I need help figuring out how to make the
same change via sendmail.mc if it's applicable.

I didn't expect to fix anything with this experiment, and I didn't --
but I've collected a bit more info that may cause a lightbulb to go off
for anyone reading this who knows what they are doing(e.g. anyone but
me). If I get time later today I'll play with the -x option for
mail.local to see if I get any useful info that way.

There have been times through this process that I have thought it would
be better to go back to the Sun sendmail -- it would probably work just
fine with stunnel. But, in for a penny, in for a pound. I am learning a
lot as I go, but I still feel like an idiot when it comes to sendmail.

Thanks for all your help.

Regards,

Dave A.

Per Hedeland

unread,

May 26, 2008, 7:34:13 PM5/26/08

to

In article <HdB_j.2541$co7....@nlpi066.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>Mlocal, P=/usr/bin/mail, F=lsDFMAw5:/|@qPSXmnz9,
>S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL,
> T=DNS/RFC822/SMTP,
> A=mail.local -l

>I went back to having the -l arg in sendmail.cf -- Obviously I should

>not be editing that file, and I need help figuring out how to make the
>same change via sendmail.mc if it's applicable.
>
>I didn't expect to fix anything with this experiment, and I didn't --
>but I've collected a bit more info that may cause a lightbulb to go off
>for anyone reading this who knows what they are doing(e.g. anyone but
>me). If I get time later today I'll play with the -x option for
>mail.local to see if I get any useful info that way.

The problem is that you aren't *running* mail.local, but /usr/bin/mail
(see the P= field), which you for some reason have requested in your
sendmail.mc:

define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl

- more bad info from some google search, perhaps? Take it out.

>There have been times through this process that I have thought it would
>be better to go back to the Sun sendmail -- it would probably work just
>fine with stunnel.

Stunnel doesn't require anything from sendmail, and Sun's sendmail even
has STARTTLS support compiled-in (at least in Solaris 10) - but it
doesn't have AUTH, which I gather that you need.

Your problem is that you've haphazardly thrown in all kinds of random
stuff without even knowing why - I don't think I've seen anyone have
such an assortment of problems getting sendmail up and running (and
given that, I'm afraid that your promised summary of how you overcame
them will not really be useful to anyone else).

A bit late now, but what you *should* have done, once you (correctly, I
believe) figured out that you needed to replace Sun's sendmail, would
have been to setup a bog-standard install of open-source sendmail. No
special compile options for SASL or STARTTLS, nothing more in the .mc
and other config files than what you already had with Sun's version
(probably less than in their .mc). It would have "just worked", and then
you could have incrementally added what you actually needed beyond that,
and immediately seen which changes caused which problems - maybe even
avoided making some of those changes in the first place.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 26, 2008, 8:00:03 PM5/26/08

to

In article <mtu_j.1414$uE5...@flpi144.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>I'm wondering if the "myfake.net" is necessary. As I recall, it was
>needed with the Sun sendmail because it somehow needed more than a bare
>hostname. I have no such domain set up.

"myfake.net" is a valid and existing domain registered to someone in
Germany, so if it isn't yours, you most certainly shouldn't use it.
Sendmail - actually SMTP - in general wants some sort of domain name
qualification, but things should work in your local setup without it,
provided that your name service setup handles it correcty. E.g. you
mustn't have a "search" or "domain" directive in your /etc/resolv.conf
or it will end up being appended to "unqualified" names. The actual name
of your sendmail host (i.e. the output of 'hostname') should also be
unqualified in such a setup.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 26, 2008, 8:54:40 PM5/26/08

to

There is no domain directive in resolv.conf and "hostname" returns the
bare hostname. "myfake.net" was not taken when I set this up, and i will
remove references to it.

Dave Anderson

unread,

May 26, 2008, 9:03:00 PM5/26/08

to

>
> define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl
>
> - more bad info from some google search, perhaps? Take it out.
>

I'll do that.

>> There have been times through this process that I have thought it would
>> be better to go back to the Sun sendmail -- it would probably work just
>> fine with stunnel.
>
> Stunnel doesn't require anything from sendmail, and Sun's sendmail even
> has STARTTLS support compiled-in (at least in Solaris 10) - but it
> doesn't have AUTH, which I gather that you need.
>
> Your problem is that you've haphazardly thrown in all kinds of random
> stuff without even knowing why - I don't think I've seen anyone have
> such an assortment of problems getting sendmail up and running (and
> given that, I'm afraid that your promised summary of how you overcame
> them will not really be useful to anyone else).
>
> A bit late now, but what you *should* have done, once you (correctly, I
> believe) figured out that you needed to replace Sun's sendmail, would
> have been to setup a bog-standard install of open-source sendmail. No
> special compile options for SASL or STARTTLS, nothing more in the .mc
> and other config files than what you already had with Sun's version
> (probably less than in their .mc). It would have "just worked", and then
> you could have incrementally added what you actually needed beyond that,
> and immediately seen which changes caused which problems - maybe even
> avoided making some of those changes in the first place.
>

That's easy enough to do -- When I have some time, I will remove all of
the files installed with sasl, untar a fresh copy of the sendmail distro
and start from there. Note that the Solaris 8 sendmail did not have any
sort of .mc file, at least not in /etc/mail. Part of my problem is that
I took advice from someone who sounded lke they knew what they were
talking about -- when I should have come here in the first place, as you
obviously know sendmail inside out and do know what you're talking about.
Regards,

Dave A.

Per Hedeland

unread,

May 26, 2008, 9:18:29 PM5/26/08

to

In article <MYI_j.5018$Ri....@flpi146.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>Per Hedeland wrote:
>> In article <mtu_j.1414$uE5...@flpi144.ffdc.sbc.com> Dave Anderson
>> <r-...@pacbell.net> writes:
>>> I'm wondering if the "myfake.net" is necessary. As I recall, it was
>>> needed with the Sun sendmail because it somehow needed more than a bare
>>> hostname. I have no such domain set up.
>>
>> "myfake.net" is a valid and existing domain registered to someone in
>> Germany, so if it isn't yours, you most certainly shouldn't use it.
>> Sendmail - actually SMTP - in general wants some sort of domain name
>> qualification, but things should work in your local setup without it,
>> provided that your name service setup handles it correcty. E.g. you
>> mustn't have a "search" or "domain" directive in your /etc/resolv.conf
>> or it will end up being appended to "unqualified" names. The actual name
>> of your sendmail host (i.e. the output of 'hostname') should also be
>> unqualified in such a setup.

>There is no domain directive in resolv.conf and "hostname" returns the

>bare hostname. "myfake.net" was not taken when I set this up, and i will
>remove references to it.

Actually there's one place where not having a FQHN will cause you grief,
and that's sendmail's $j definition, "the canonical name of this host"
(used for HELO, in SMTP greeting etc). Sendmail really, really wants
this to be fully-qualified, and if it isn't, will sit waiting for 60
seconds at startup on the assumption that DNS hasn't started yet.

I haven't used sendmail in a scenario where there isn't a real domain
name to use since forever, but ISTR that people have successfully used
".local" as a "fake" domain. There is an RFC (2606) that describes "best
current practice" for "fake" domains to make sure to avoid conflicts
with real ones, but I don't really think any of those suggestions are
"right" for a "permanent, private" setup.

--Per Hedeland
p...@hedeland.org

Giorgos Keramidas

unread,

May 26, 2008, 10:25:12 PM5/26/08

to

On Mon, 26 May 2008 01:24:41 -0700, Dave Anderson <r-...@pacbell.net> wrote:
>> - it doesn't matter what the client "uses" to make the connection, in
>> fact a server can't possibly know that, and sendmail will look for
>> matching entries both for the IP address (which it always knows) and
>> for the result of reverse-lookup (PTR) of that IP address - but the
>> latter is only done if also the forward-lookup (A/AAAA) of the PTR
>> result is successful *and* includes the original IP address in *its*
>> result.
>>
>> So, as far as connect-time checking of the client host (i.e. entries
>> that would be best tagged with "Connect:") is concerned, a
>> 'localhost' entry will only match for clients that have an IP address
>> included in the result of a lookup of 'localhost' on your host -
>> hopefully the only address returned by that is 127.0.0.1 (possibly
>> the IPv6 ::1 equivalent too), otherwise you need to fix *that*.
>
> That's good, below are the /etc/hosts entries that pertain to this machine:
>
> 127.0.0.1 localhost
> 127.0.0.1 smarthost-local
> 192.168.69.x ultra ultra.myfake.net loghost

For what it's worth, it's not a good idea to use random sub-domains of
"net" as fake network names. In this case, "myfake.net" is an existing
domain, registered by Alfahosting GmbH!

% whois myfake.net
[...]
tech-contact: P-MNB420
tech-organization: Alfahosting GmbH
tech-title: Herr
tech-fname: Moritz
tech-lname: Bartsch
tech-street: AnkerstraΓe 3b
tech-city: Halle
tech-state: Sachsen-Anhalt
tech-zip: 06108
tech-country: DE
tech-phone: +49.3452093290
tech-fax: +49.3456800499
tech-email: hostm...@alfahosting.de
[...]

Putting aside the funny name of "myfake.net", you don't control that
domain, so you should try to avoid using it.

Instead of "myfake.net" you can use "ultra.anderson.priv".

I've seen email bounce to the wrong person because of an 'internal'
domain name that wasn't really internal, but registered by an innocent
third party.

Dave Anderson

unread,

May 26, 2008, 10:53:54 PM5/26/08

to

> Actually there's one place where not having a FQHN will cause you grief,
> and that's sendmail's $j definition, "the canonical name of this host"
> (used for HELO, in SMTP greeting etc). Sendmail really, really wants
> this to be fully-qualified, and if it isn't, will sit waiting for 60
> seconds at startup on the assumption that DNS hasn't started yet.
>
> I haven't used sendmail in a scenario where there isn't a real domain
> name to use since forever, but ISTR that people have successfully used
> ".local" as a "fake" domain. There is an RFC (2606) that describes "best
> current practice" for "fake" domains to make sure to avoid conflicts
> with real ones, but I don't really think any of those suggestions are
> "right" for a "permanent, private" setup.

Thanks for the RFC link. BTW, that was not even published when I set up
sendmail on my SparcStation 2 -- I simply transferred "what worked" to
the Ultra 5 when I set that up ~5 years ago and "it worked" so I kept
plugging. :)

Seems straightforward enough:

The ".localhost" TLD has traditionally been statically defined in host
DNS implementations as having an A record pointing to the loop back IP
address and is reserved for such use. Any other use would conflict with
widely deployed code which assumes this use.

So the following set of /etc/hosts entries would seem, at least, to not
be in conflict with RFC 2606 (and has the benefit that now "ping
ultra.localhost" now works):

127.0.0.1 localhost
127.0.0.1 smarthost-local
127.0.0.1 ultra.localhost
192.168.69.5 ultra loghost

This info may have become lost in that mess of a thread above, but my
primary purposes in having sendmail are as follows:

1) Have the ability to test CGI script that I am developing, which
attempt to send emails in a safe manner.
2) Have the ability to send emails to myself and other interested
parties from utility scripts that I run from cron
3) New requirement: Relay mail from (my)insecure clients to an SMTP
server that requires SSL.

When my requirements were simply (1) and (2), I never cared about what
sendmail did with incoming mail, it never ran as a daemon anyway. Local
mail "just worked" and I never gave it much thought. With requirement
(3) in the mix, I find myself dealing with an aspect of sendmail that I
have never really touched on -- not that I ever did dig very deeply into
understanding sendmail's "send" side.

While I want to stay away from doing things that are "always stupid",
e.g. will break sendmail, I feel like I can compromise somewhat on the
things that would be "stupid if this machine is on the public internet".
This means that:

1) I am not worried about spammers being able to hijack my relay
2) I am not worried about any kind of malware taking advantage of my
less than optimal config.
3) I am not worried about users doing nasty things with sendmail. For
all intents and purposes, I am the only user.

Each time I upgrade/change my router/firewall, I run a cron job/script
combo that greps for any external connections to this machine, usually I
run it for a month but once I forgot about it for 4 months and never
have I seen anything from the internet connect to this machine(or the
SparcStation2), portscan it, etc.

Anyway, I will move forward with a new sendmail build, plain vanilla
except for the stunnel-related additions.

If I post a synopsis, it will be one that starts from this new baseline.
If, as you suggest, it ends up being too convoluted for general use,
I'll skip it.

Dave Anderson

unread,

May 26, 2008, 11:10:30 PM5/26/08

to

Thank you, that has been pointed out to me and addressed. "whois" didn't
know about the domain when it was set up, but then the internet HAS
grown a bit in the last 10+ years. ;)

Per Hedeland pointed me to RFC 2606, which seems to offer a workable
solution, especially since this machine is more a test machine than
anything else. He also cautions that it's probably not a permanent solution.

Dave Anderson

unread,

May 26, 2008, 11:55:57 PM5/26/08

to

>
> Actually there's one place where not having a FQHN will cause you grief,
> and that's sendmail's $j definition, "the canonical name of this host"
> (used for HELO, in SMTP greeting etc). Sendmail really, really wants
> this to be fully-qualified, and if it isn't, will sit waiting for 60
> seconds at startup on the assumption that DNS hasn't started yet.

I assume that's why I'm seeing the following after uninstalling SASL and
recompiling with basically no site config file and a minimal sendmail.mc:

May 26 20:45:51 ultra sendmail[23746]: [ID 702911 mail.alert] unable to
qualify my own domain name (ultra) -- using short name

divert(0)dnl
VERSIONID(`$Id: sendmail.mc,v 8.13 2008/05/29 11:46:30 Dave Exp $')
OSTYPE(solaris8)dnl
DOMAIN(generic)dnl

define(`confDOMAIN_NAME', `$w.localhost')dnl
define(`SMART_HOST', `smarthost-local')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')

FEATURE(`access_db')dnl

MAILER(local)dnl
MAILER(smtp)dnl

Dave Anderson

unread,

May 27, 2008, 12:08:55 AM5/27/08

to

>
> define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl
>
> - more bad info from some google search, perhaps? Take it out.
>

Now I remember why I did that -- without it, on my fresh install, I get
this repeated in my syslog:

May 26 20:53:49 ultra sendmail[23836]: [ID 801593 mail.info]
m4R3pxrF023814: Warning: program /usr/lib/mail.local unsafe: No such
file or directory
May 26 20:53:49 ultra sendmail[23836]: [ID 801593 mail.crit]
m4R3pxrF023814: SYSERR(root): Cannot exec /usr/lib/mail.local: No such
file or directory
May 26 20:53:49 ultra sendmail[23835]: [ID 801593 mail.error]
m4R3pxrF023814: smtpquit: mailer local exited with exit value 71
May 26 20:53:49 ultra sendmail[23835]: [ID 801593 mail.info]
m4R3pxrF023814: to=<root@ultra>, delay=00:01:49, xdelay=00:00:00,
mailer=local, pri=212137, relay=local, dsn=4.4.2, stat=Deferred:
Connection reset by local

I had the impression from the README in <sendmail source>/mail.local
that mail.local was not really intended for a more or less "stock"
Solaris system. Having removed SUNWsndmr and SUNWsndmu, should I
consider the warning to be inapplicable in my case, and go ahead and
install this component?

Something else has changed, now I'm getting the following on every
terminal window -- but that's another matter:

May 26 20:54:46 ultra sendmail[23833]: [ID 702911 mail.alert] unable to

Per Hedeland

unread,

May 27, 2008, 1:58:10 AM5/27/08

to

In article <6YK_j.5240$Ri....@flpi146.ffdc.sbc.com> Dave Anderson
<r-...@pacbell.net> writes:

>Giorgos Keramidas wrote:
>>
>> Instead of "myfake.net" you can use "ultra.anderson.priv".

Is this some kind of standard that I have missed? If so it would seem to
be just the thing for a setup like Dave's. Googling a bit I see a number
of suggestions (at least one as a comment specifically to RFC 2606) that
there is a need for a domain-name equivalent of the private networks
listed in RFC 1918, but I can't see ".priv" actually being reserved for
that purpose anywhere. A lookup for NS records gives NXDOMAIN, but that
doesn't really say anything one way or the other in this case...:-)

>Per Hedeland pointed me to RFC 2606, which seems to offer a workable
>solution, especially since this machine is more a test machine than
>anything else. He also cautions that it's probably not a permanent solution.

Well no, the names given in RFC 2606 will be reserved for their stated
purpose forever, what I meant was just that none of them are "nice" for
permanent, private usage (like .priv would be) - they're all targeted at
testing or examples in documentation and the like. The .localhost that
you chose is perhaps not in that category, but is a bit "weird" to use
as an actual "domain name" with host names below - traditionally it has
just been for the very special domain that consists only of "the local
host", which has the fully qualified name of "localhost". But if you're
happy with it, it should be OK.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 27, 2008, 2:10:52 AM5/27/08

to

In article <TOL_j.5248$Ri....@flpi146.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>>
>> define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl
>>
>> - more bad info from some google search, perhaps? Take it out.
>>
>Now I remember why I did that -- without it, on my fresh install, I get
> this repeated in my syslog:
>
>May 26 20:53:49 ultra sendmail[23836]: [ID 801593 mail.info]
>m4R3pxrF023814: Warning: program /usr/lib/mail.local unsafe: No such
>file or directory

>I had the impression from the README in <sendmail source>/mail.local

>that mail.local was not really intended for a more or less "stock"
>Solaris system. Having removed SUNWsndmr and SUNWsndmu, should I
>consider the warning to be inapplicable in my case, and go ahead and
>install this component?

Aha - yes, personally I would be wary of using the mail.local that comes
with sendmail on Solaris, but Solaris *ships* with a mail.local that
presumably has to be OK to use - but of course it's part of the
SUNWsndmu package... Maybe snarf it from the package and install it "on
its own"?

Otherwise you should be able to use /usr/bin/mail, but then you (at
least) have to get rid of FEATURE(`local_lmtp') that is in
cf/ostype/solaris8.m4 (gets pulled in by OSTYPE(solaris8)) -
/usr/bin/mail can't do LMTP. Maybe you could use OSTYPE(solaris2.pre5).

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 27, 2008, 2:21:34 AM5/27/08

to

In article <ICL_j.5245$Ri....@flpi146.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>>
>> Actually there's one place where not having a FQHN will cause you grief,
>> and that's sendmail's $j definition, "the canonical name of this host"
>> (used for HELO, in SMTP greeting etc). Sendmail really, really wants
>> this to be fully-qualified, and if it isn't, will sit waiting for 60
>> seconds at startup on the assumption that DNS hasn't started yet.
>
>I assume that's why I'm seeing the following after uninstalling SASL and
> recompiling with basically no site config file and a minimal sendmail.mc:

Hm, removing SASL was perhaps a bit overkill at this point, but at least
now you know how to add it back in.:-)

>May 26 20:45:51 ultra sendmail[23746]: [ID 702911 mail.alert] unable to
>qualify my own domain name (ultra) -- using short name

That's what you get if you don't have any domain at all - if you go with
.localhost, you need to rearrange your hosts file a bit so that sendmail
can figure out that the name of your host is ultra.localhost - like so:

127.0.0.1 localhost
127.0.0.1 smarthost-local
192.168.69.5 ultra.localhost ultra loghost

Possibly you may need to put ultra.localhost at the end of the last line
instead of at the beginning to make Solaris happy - the above is the
"standard" way (the "canonical name" comes first, the others are
aliases), but sendmail can deal with either of them.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 28, 2008, 2:04:33 AM5/28/08

to

> Hm, removing SASL was perhaps a bit overkill at this point, but at least
> now you know how to add it back in.:-)

Am I correct in assuming I really don't need it for what I'm trying to
do? I had only installed it on the advice of someone who had apparently
given me much advice that turned out to be not so good... You're right
though, easy enough to put back if needed.

>
>> May 26 20:45:51 ultra sendmail[23746]: [ID 702911 mail.alert] unable to
>> qualify my own domain name (ultra) -- using short name
>
> That's what you get if you don't have any domain at all - if you go with
> .localhost, you need to rearrange your hosts file a bit so that sendmail
> can figure out that the name of your host is ultra.localhost - like so:
>
> 127.0.0.1 localhost
> 127.0.0.1 smarthost-local
> 192.168.69.5 ultra.localhost ultra loghost
>
> Possibly you may need to put ultra.localhost at the end of the last line
> instead of at the beginning to make Solaris happy - the above is the
> "standard" way (the "canonical name" comes first, the others are
> aliases), but sendmail can deal with either of them.

Interesting -- the RFC seemed to indicate that I should be pointing to
the loopback address(127.0.0.1) with this -- Did I misread that, or is
there some strange magic going on where it's just as valid to point it
to the real IP?

I tried ultra.localhost and ended up with the same results, though I
can't say the name lookup is the problem. More details on the branch of
this thread discussing mail.local.

Regards,

Dave A.

Dave Anderson

unread,

May 28, 2008, 2:09:37 AM5/28/08

to

>> Per Hedeland pointed me to RFC 2606, which seems to offer a workable
>> solution, especially since this machine is more a test machine than
>> anything else. He also cautions that it's probably not a permanent solution.
>
> Well no, the names given in RFC 2606 will be reserved for their stated
> purpose forever, what I meant was just that none of them are "nice" for
> permanent, private usage (like .priv would be) - they're all targeted at
> testing or examples in documentation and the like. The .localhost that
> you chose is perhaps not in that category, but is a bit "weird" to use
> as an actual "domain name" with host names below - traditionally it has
> just been for the very special domain that consists only of "the local
> host", which has the fully qualified name of "localhost". But if you're
> happy with it, it should be OK.

I'm OK with whatever works, so long as it doesn't set anything on fire.
:) I have nightmare visions in my head of having to delve into DNS and
BIND, switch to a different type of DSL (currently my modem gets its IP
via DHCP, no domain support), or worse. I'm willing to fudge a little.
Maybe even a lot. ;)

Regards,

Dave A.

Dave Anderson

unread,

May 28, 2008, 3:13:00 AM5/28/08

to

>> I had the impression from the README in <sendmail source>/mail.local
>> that mail.local was not really intended for a more or less "stock"
>> Solaris system. Having removed SUNWsndmr and SUNWsndmu, should I
>> consider the warning to be inapplicable in my case, and go ahead and
>> install this component?
>
> Aha - yes, personally I would be wary of using the mail.local that comes
> with sendmail on Solaris, but Solaris *ships* with a mail.local that
> presumably has to be OK to use - but of course it's part of the
> SUNWsndmu package... Maybe snarf it from the package and install it "on
> its own"?

I'll have to take another look at this if using "mail" turns out to be a
dead end.

>
> Otherwise you should be able to use /usr/bin/mail, but then you (at
> least) have to get rid of FEATURE(`local_lmtp') that is in
> cf/ostype/solaris8.m4 (gets pulled in by OSTYPE(solaris8)) -
> /usr/bin/mail can't do LMTP. Maybe you could use OSTYPE(solaris2.pre5).
>

OK, I've removed that lmtp line and recompiled with Build -c, now when I
try to send a simple
local mail I get a savemail panic:

# mail -x -20 root
To: root
From: root

test
.
# May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.alert]
m4S6LpqX001580: Losing ./qfm4S6LpqX001580: savemail panic

Also in the syslog I see messages about "broken pipe", "unknown mailer
error 5", and "cannot save rejected mail anywhere". I have tried
rearranging the /etc/hosts entries you mentioned elsewhere in this
thread, seems to have no impact on this.

It seems from the mail -x output that mail is handing off to sendmail
just fine, if I'm correct in assuming that no blatantly bad news there
is good news.

What seems pertinent in the mail.log is this:

02054 >>> ----- The following addresses had permanent fatal errors -----
02054 >>> <ro...@ultra.localhost>
02054 >>> (reason: 5)
02054 >>>
02054 >>> ----- Transcript of session follows -----
02054 >>> 451 4.0.0 putbody: write error: Broken pipe
02054 >>> mail: Options MUST PRECEDE persons
02054 >>> 554 5.3.0 unknown mailer error 5

Googling on this turned up the following article, which seems at first
glance to be very dated:
http://www.sunmanagers.org/archives/1995/1587.html The stanford link
from there is dead and unfortunately not even archive.org can dredge it up.

However, looking at the original Sun sendmail.cf vs my latest one it
does seem that the new version has an 'r' option called out:

# grep ^Mlocal sendmail.cf.pre-ssl
Mlocal, P=/usr/lib/mail.local, F=lsDFMAw5:/|@qPSXfmnz9,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
# grep ^Mlocal sendmail.cf
Mlocal, P=/usr/bin/mail, F=lsDFMAw5:/|@qPrmn9,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
#

An examination of the man pages for mail and mail.local indicates that
for the versions I have(had), -r was a valid option for mail.local but
not for mail. Do you think there's anything to this or am I chasing my tail?

BTW, I did another "big bang" test and saw a dialog with
smtp.att.yahoo.com and a failed auth -- so I know that end of things is
closer than I've ever been -- I didn't fiddle with that much though, the
local mailer seems like it needs to be dealt with first.

Below, respectively, are the following from the local mailer test above:

/tmp/MLDBGx.aifd (debug output from mail -x)
site.config.m4
sendmail.mc
syslog
mail.log

==================[/tmp/MLDBGx.aifd]====================
main(): debugging level == 20
main(): trace file ='/tmp/MLDBGx.aifd': kept on success or failure.
main(): thissys = 'ultra', uname = 'ultra'
main(): my_name = 'root'
main(): ismail=1, argc=2
sendmail(): entered
new_reciplist(): entered
add_recip(): 'root' added to recipient list
pushlist(): hdrtype = 8/From , contflg = 0, saved value = 'root Tue May
27 23:21 PDT 2008'
sendmail(): header scan complete, readahead 5 = "test
"
pushlist(): hdrtype = 11/MIME-Version:, contflg = 0, saved value = ''
pushlist(): hdrtype = 4/Content-Type:, contflg = 0, saved value = ''
pushlist(): hdrtype = 3/Content-Length:, contflg = 0, saved value = ''
sendmail(): header out completed
sendmail(): body copy complete, count 5
copylet(): (letnum = 0, type = 2), k = 109
copylet(): loop 1: buf = From root Tue May 27 23:21 PDT 2008
, htype= 0/
copylet(): loop 2: buf = To: root
, htype= 19/To:
copylet(): loop 2: buf = From: root
, htype= 10/From:
copylet(): loop 2: buf = MIME-Version:
, htype= 11/MIME-Version:
dumprcv(): type=2, htype=11/MIME-Version:, *didrcvlines=0, *suppress=0
pckrcvspot(): 'No Received: lines'
dumprcv(): rcvspot==-1
dumpaff(): type=2, htype=11/MIME-Version:, *didafflines=0, *suppress=0
pckaffspot(): 'No Auto-Forward-From lines'
dumpaff(): affspot==-1
copylet(): loop 2: buf = Content-Type:
, htype= 4/Content-Type:
dumprcv(): type=2, htype=4/Content-Type:, *didrcvlines=0, *suppress=0
pckrcvspot(): 'No Received: lines'
dumprcv(): rcvspot==-1
dumpaff(): type=2, htype=4/Content-Type:, *didafflines=0, *suppress=0
pckaffspot(): 'No Auto-Forward-From lines'
dumpaff(): affspot==-1
copylet(): loop 2: buf = Content-Length:
, htype= 3/Content-Length:
dumprcv(): type=2, htype=3/Content-Length:, *didrcvlines=0, *suppress=0
pckrcvspot(): 'No Received: lines'
dumprcv(): rcvspot==-1
dumpaff(): type=2, htype=3/Content-Length:, *didafflines=0, *suppress=0
pckaffspot(): 'No Auto-Forward-From lines'
dumpaff(): affspot==-1
copylet(): loop 2: buf =
, htype= 0/
copylet(): , let[0].text = TRUE
copylet(): header processed, clen/k/n = 5/5/0
copylet(): body processed, k=0
done(): maxerr set to 0
done(): temp file removed

==================[site.config.m4]====================
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib -R/usr/local/lib')
APPENDDEF(`confLIBDIRS', `-L/usr/local/BerkeleyDB.4.2/lib')
APPENDDEF(`confINCDIRS', `-I/usr/local/BerkeleyDB.4.2/include')
APPENDDEF(`confENVDEF', `-DNEWDB')

==================[sendmail.mc]====================

divert(0)dnl
VERSIONID(`$Id: sendmail.mc,v 8.13 2008/05/29 11:46:30 Dave Exp $')
OSTYPE(solaris8)dnl
DOMAIN(generic)dnl

FEATURE(`access_db')dnl
FEATURE(`authinfo')dnl

define(`LOCAL_MAILER_PATH', `/usr/bin/mail')dnl

define(`SMART_HOST', `smarthost-local')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')

MAILER(local)dnl
MAILER(smtp)dnl

==================[syslog]====================
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.alert]
m4S6LpqX001580: Losing ./qfm4S6LpqX001580: savemail panic
May 27 23:21:51 ultra sendmail[1578]: [ID 801593 mail.info]
m4S6LptC001578: from=root, size=124, class=0, nrcpts=1,
msgid=<200805280621....@ultra.localhost>, relay=root@localhost
May 27 23:21:51 ultra sendmail[1579]: [ID 801593 mail.info]
m4S6LpqX001579: from=<ro...@ultra.localhost>, size=346, class=0,
nrcpts=1, msgid=<200805280621....@ultra.localhost>,
proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
May 27 23:21:51 ultra sendmail[1578]: [ID 801593 mail.info]
m4S6LptC001578: to=root, ctladdr=root (0/1), delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=30124, relay=[127.0.0.1] [127.0.0.1],
dsn=2.0.0, stat=Sent (m4S6LpqX001579 Message accepted for delivery)
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.crit]
m4S6LpqX001579: SYSERR(root): putbody: write error: Broken pipe
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 0: fl=0x0, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 1: fl=0x1, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 2: fl=0x1, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 3: fl=0x2000, mode=150444: dev=0/0, ino=29633,
nlink=1, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 4: fl=0x0, mode=20000: CHR: dev=0/0, ino=51974,
nlink=0, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 5: fl=0x9, mode=100644: dev=0/1, ino=146626, nlink=1,
u/gid=0/1, size=325585
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 6: fl=0x1, mode=20000: CHR: dev=0/0, ino=51970,
nlink=0, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 8: fl=0x0, mode=100600: dev=0/1, ino=135242, nlink=1,
u/gid=0/1, size=6
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 9: fl=0x2000, mode=100640: dev=0/0, ino=213, nlink=1,
u/gid=0/1, size=24576
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 10: fl=0x2000, mode=100640: dev=0/0, ino=213, nlink=1,
u/gid=0/1, size=24576
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 11: fl=0x1, mode=100600: dev=0/1, ino=135548, nlink=1,
u/gid=0/1, size=811
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 12: fl=0x2, mode=10000: FIFO: dev=0/0, ino=482,
nlink=0, u/gid=0/1, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: 13: fl=0x2, mode=10000: FIFO: dev=0/0, ino=483,
nlink=0, u/gid=0/1, size=35
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001579: MCI@0x0: NULL
May 27 23:21:51 ultra last message repeated 1 time
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.info]
m4S6LpqX001579: to=<ro...@ultra.localhost>,
ctladdr=<ro...@ultra.localhost> (0/1), delay=00:00:00, xdelay=00:00:00,
mailer=local, pri=30564, dsn=5.3.0, stat=unknown mailer error 5
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.info]
m4S6LpqX001579: m4S6LpqX001580: DSN: unknown mailer error 5
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.crit]
m4S6LpqX001580: SYSERR(root): putbody: write error: Broken pipe
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 0: fl=0x0, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 1: fl=0x1, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 2: fl=0x1, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 3: fl=0x2000, mode=150444: dev=0/0, ino=29633,
nlink=1, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 4: fl=0x0, mode=20000: CHR: dev=0/0, ino=51974,
nlink=0, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 5: fl=0x9, mode=100644: dev=0/1, ino=146626, nlink=1,
u/gid=0/1, size=330424
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 6: fl=0x1, mode=20000: CHR: dev=0/0, ino=51970,
nlink=0, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 7: fl=0x1, mode=100600: dev=0/1, ino=135545, nlink=1,
u/gid=0/1, size=802
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 8: fl=0x0, mode=100600: dev=0/1, ino=135242, nlink=1,
u/gid=0/1, size=6
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 9: fl=0x2000, mode=100640: dev=0/0, ino=213, nlink=1,
u/gid=0/1, size=24576
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 10: fl=0x2000, mode=100640: dev=0/0, ino=213, nlink=1,
u/gid=0/1, size=24576
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 11: fl=0x1, mode=100600: dev=0/1, ino=135548, nlink=1,
u/gid=0/1, size=811
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 12: fl=0x0, mode=100600: dev=0/1, ino=135549, nlink=1,
u/gid=0/1, size=1506
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 13: fl=0x2, mode=10000: FIFO: dev=0/0, ino=484,
nlink=0, u/gid=0/1, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: 14: fl=0x2, mode=10000: FIFO: dev=0/0, ino=485,
nlink=0, u/gid=0/1, size=35
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqX001580: MCI@0x0: NULL
May 27 23:21:51 ultra last message repeated 1 time
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.info]
m4S6LpqX001580: to=<ro...@ultra.localhost>, delay=00:00:00,
xdelay=00:00:00, mailer=local, pri=31588, dsn=5.3.0, stat=unknown mailer
error 5
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.info]
m4S6LpqX001580: m4S6LpqY001580: return to sender: unknown mailer error 5
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.crit]
m4S6LpqY001580: SYSERR(root): putbody: write error: Broken pipe
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 0: fl=0x0, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 1: fl=0x1, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 2: fl=0x1, mode=20666: CHR: dev=0/0, ino=67723,
nlink=1, u/gid=0/3, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 3: fl=0x2000, mode=150444: dev=0/0, ino=29633,
nlink=1, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 4: fl=0x0, mode=20000: CHR: dev=0/0, ino=51974,
nlink=0, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 5: fl=0x9, mode=100644: dev=0/1, ino=146626, nlink=1,
u/gid=0/1, size=339223
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 6: fl=0x1, mode=20000: CHR: dev=0/0, ino=51970,
nlink=0, u/gid=0/0, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 7: fl=0x1, mode=100600: dev=0/1, ino=135545, nlink=1,
u/gid=0/1, size=802
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 8: fl=0x0, mode=100600: dev=0/1, ino=135242, nlink=1,
u/gid=0/1, size=6
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 9: fl=0x2000, mode=100640: dev=0/0, ino=213, nlink=1,
u/gid=0/1, size=24576
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 10: fl=0x2000, mode=100640: dev=0/0, ino=213, nlink=1,
u/gid=0/1, size=24576
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 11: fl=0x1, mode=100600: dev=0/1, ino=135548, nlink=1,
u/gid=0/1, size=811
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 12: fl=0x0, mode=100600: dev=0/1, ino=135549, nlink=1,
u/gid=0/1, size=1506
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 13: fl=0x1, mode=100600: dev=0/1, ino=135550, nlink=1,
u/gid=0/1, size=812
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 14: fl=0x0, mode=100600: dev=0/1, ino=135551, nlink=1,
u/gid=0/1, size=2992
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 15: fl=0x2, mode=10000: FIFO: dev=0/0, ino=486,
nlink=0, u/gid=0/1, size=0
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: 16: fl=0x2, mode=10000: FIFO: dev=0/0, ino=487,
nlink=0, u/gid=0/1, size=35
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.debug]
m4S6LpqY001580: MCI@0x0: NULL
May 27 23:21:51 ultra last message repeated 1 time
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.info]
m4S6LpqY001580: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local,
pri=32612, dsn=5.3.0, stat=unknown mailer error 5
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.alert]
m4S6LpqX001580: Losing ./qfm4S6LpqX001580: savemail panic
May 27 23:21:51 ultra sendmail[1580]: [ID 801593 mail.crit]
m4S6LpqX001580: SYSERR(root): savemail: cannot save rejected email anywhere

==================[mail.log]====================
01579 >>> 220 ultra.localhost ESMTP Sendmail 8.14.2/8.14.2; Tue, 27 May
2008 23:21:51 -0700 (PDT)
01579 <<< EHLO ultra.localhost
01579 >>> 250-ultra.localhost Hello localhost [127.0.0.1], pleased to
meet you
01579 >>> 250-ENHANCEDSTATUSCODES
01579 >>> 250-PIPELINING
01579 >>> 250-EXPN
01579 >>> 250-VERB
01579 >>> 250-8BITMIME
01579 >>> 250-SIZE
01579 >>> 250-DSN
01579 >>> 250-ETRN
01579 >>> 250-DELIVERBY
01579 >>> 250 HELP
01579 <<< MAIL From:<ro...@ultra.localhost> SIZE=124
01579 >>> 250 2.1.0 <ro...@ultra.localhost>... Sender ok
01579 <<< RCPT To:<ro...@ultra.localhost>
01579 >>> 250 2.1.5 <ro...@ultra.localhost>... Recipient ok
01579 <<< DATA
01579 >>> 354 Enter mail, end with "." on a line by itself
01579 <<< Received: (from root@localhost)
01579 <<< by ultra.localhost (8.14.2/8.14.2/Submit) id m4S6LptC001578
01579 <<< for root; Tue, 27 May 2008 23:21:51 -0700 (PDT)
01579 <<< Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01579 <<< Message-Id: <200805280621....@ultra.localhost>
01579 <<< To: ro...@ultra.localhost
01579 <<< From: ro...@ultra.localhost
01579 <<< MIME-Version: 1.0
01579 <<< Content-Type: text/plain
01579 <<<
01579 <<< test
01579 <<<
01579 <<< .
01579 >>> 250 2.0.0 m4S6LpqX001579 Message accepted for delivery
01579 <<< QUIT
01579 >>> 221 2.0.0 ultra.localhost closing connection
01580 === EXEC mail -r ro...@ultra.localhost -d root
01580 >>> Return-Path: <ro...@ultra.localhost>
01580 >>> Received: from ultra.localhost (localhost [127.0.0.1])
01580 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4S6LpqX001579
01580 >>> for <ro...@ultra.localhost>; Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> Received: (from root@localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4S6LptC001578
01580 >>> for root; Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: ro...@ultra.localhost
01580 >>> From: ro...@ultra.localhost
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: text/plain
01580 >>>
01580 >>> test
01580 >>>
01580 <<< mail: Options MUST PRECEDE persons
01580 <<< [EOF]
01580 >>> This is a MIME-encapsulated message
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>>
01580 >>> The original message was received at Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> from localhost [127.0.0.1]
01580 >>>
01580 >>> ----- The following addresses had permanent fatal errors -----
01580 >>> <ro...@ultra.localhost>
01580 >>> (reason: 5)
01580 >>>
01580 >>> ----- Transcript of session follows -----
01580 >>> 451 4.0.0 putbody: write error: Broken pipe
01580 >>> mail: Options MUST PRECEDE persons
01580 >>> 554 5.3.0 unknown mailer error 5
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/delivery-status
01580 >>>
01580 >>> Reporting-MTA: dns; ultra.localhost
01580 >>> Received-From-MTA: DNS; localhost
01580 >>> Arrival-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> Final-Recipient: RFC822; ro...@ultra.localhost
01580 >>> Action: failed
01580 >>> Status: 5.0.0
01580 >>> Diagnostic-Code: X-Unix; 5
01580 >>> Last-Attempt-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/rfc822
01580 >>>
01580 >>> Return-Path: <ro...@ultra.localhost>
01580 >>> Received: from ultra.localhost (localhost [127.0.0.1])
01580 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4S6LpqX001579
01580 >>> for <ro...@ultra.localhost>; Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> Received: (from root@localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4S6LptC001578
01580 >>> for root; Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: ro...@ultra.localhost
01580 >>> From: ro...@ultra.localhost
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: text/plain
01580 >>>
01580 >>> test
01580 >>>
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost--
01580 >>>
01580 === EXEC mail -r MAILER-DAEMON -d root
01580 >>> Return-Path: <MAILER-DAEMON>
01580 >>> Received: from localhost (localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2) id m4S6LpqX001580;
01580 >>> Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: <ro...@ultra.localhost>
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: multipart/report; report-type=delivery-status;
01580 >>> boundary="m4S6LpqX001580.1211955711/ultra.localhost"
01580 >>> Subject: Returned mail: see transcript for details
01580 >>> Auto-Submitted: auto-generated (failure)
01580 >>>
01580 >>> This is a MIME-encapsulated message
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>>
01580 >>> The original message was received at Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> from localhost [127.0.0.1]
01580 >>>
01580 >>> ----- The following addresses had permanent fatal errors -----
01580 >>> <ro...@ultra.localhost>
01580 >>> (reason: 5)
01580 >>>
01580 >>> ----- Transcript of session follows -----
01580 >>> 451 4.0.0 putbody: write error: Broken pipe
01580 >>> mail: Options MUST PRECEDE persons
01580 >>> 554 5.3.0 unknown mailer error 5
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/delivery-status
01580 >>>
01580 >>> Reporting-MTA: dns; ultra.localhost
01580 >>> Received-From-MTA: DNS; localhost
01580 >>> Arrival-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> Final-Recipient: RFC822; ro...@ultra.localhost
01580 >>> Action: failed
01580 >>> Status: 5.0.0
01580 >>> Diagnostic-Code: X-Unix; 5
01580 >>> Last-Attempt-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/rfc822
01580 >>>
01580 >>> Return-Path: <ro...@ultra.localhost>
01580 >>> Received: from ultra.localhost (localhost [127.0.0.1])
01580 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4S6LpqX001579
01580 >>> for <ro...@ultra.localhost>; Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> Received: (from root@localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4S6LptC001578
01580 >>> for root; Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: ro...@ultra.localhost
01580 >>> From: ro...@ultra.localhost
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: text/plain
01580 >>>
01580 >>> test
01580 >>>
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost--
01580 >>>
01580 <<< mail: Options MUST PRECEDE persons
01580 <<< [EOF]
01580 >>> This is a MIME-encapsulated message
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost
01580 >>>
01580 >>> The original message was received at Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> from localhost
01580 >>>
01580 >>> ----- The following addresses had permanent fatal errors -----
01580 >>> <ro...@ultra.localhost>
01580 >>> (reason: 5)
01580 >>>
01580 >>> ----- Transcript of session follows -----
01580 >>> 451 4.0.0 putbody: write error: Broken pipe
01580 >>> mail: Options MUST PRECEDE persons
01580 >>> 554 5.3.0 unknown mailer error 5
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/delivery-status
01580 >>>
01580 >>> Reporting-MTA: dns; ultra.localhost
01580 >>> Received-From-MTA: DNS; localhost
01580 >>> Arrival-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> Final-Recipient: RFC822; ro...@ultra.localhost
01580 >>> Action: failed
01580 >>> Status: 5.0.0
01580 >>> Diagnostic-Code: X-Unix; 5
01580 >>> Last-Attempt-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/rfc822
01580 >>>
01580 >>> Return-Path: <MAILER-DAEMON>
01580 >>> Received: from localhost (localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2) id m4S6LpqX001580;
01580 >>> Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: <ro...@ultra.localhost>
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: multipart/report; report-type=delivery-status;
01580 >>> boundary="m4S6LpqX001580.1211955711/ultra.localhost"
01580 >>> Subject: Returned mail: see transcript for details
01580 >>> Auto-Submitted: auto-generated (failure)
01580 >>>
01580 >>> This is a MIME-encapsulated message
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>>
01580 >>> The original message was received at Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> from localhost [127.0.0.1]
01580 >>>
01580 >>> ----- The following addresses had permanent fatal errors -----
01580 >>> <ro...@ultra.localhost>
01580 >>> (reason: 5)
01580 >>>
01580 >>> ----- Transcript of session follows -----
01580 >>> 451 4.0.0 putbody: write error: Broken pipe
01580 >>> mail: Options MUST PRECEDE persons
01580 >>> 554 5.3.0 unknown mailer error 5
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/delivery-status
01580 >>>
01580 >>> Reporting-MTA: dns; ultra.localhost
01580 >>> Received-From-MTA: DNS; localhost
01580 >>> Arrival-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> Final-Recipient: RFC822; ro...@ultra.localhost
01580 >>> Action: failed
01580 >>> Status: 5.0.0
01580 >>> Diagnostic-Code: X-Unix; 5
01580 >>> Last-Attempt-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/rfc822
01580 >>>
01580 >>> Return-Path: <ro...@ultra.localhost>
01580 >>> Received: from ultra.localhost (localhost [127.0.0.1])
01580 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4S6LpqX001579
01580 >>> for <ro...@ultra.localhost>; Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> Received: (from root@localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4S6LptC001578
01580 >>> for root; Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: ro...@ultra.localhost
01580 >>> From: ro...@ultra.localhost
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: text/plain
01580 >>>
01580 >>> test
01580 >>>
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost--
01580 >>>
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost--
01580 >>>
01580 === EXEC mail -r MAILER-DAEMON -d root
01580 >>> Return-Path: <MAILER-DAEMON>
01580 >>> Received: from localhost (localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2) id m4S6LpqY001580;
01580 >>> Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: postmaster
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: multipart/report; report-type=delivery-status;
01580 >>> boundary="m4S6LpqY001580.1211955711/ultra.localhost"
01580 >>> Subject: Postmaster notify: see transcript for details
01580 >>> Auto-Submitted: auto-generated (postmaster-notification)
01580 >>>
01580 >>> This is a MIME-encapsulated message
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost
01580 >>>
01580 >>> The original message was received at Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> from localhost
01580 >>>
01580 >>> ----- The following addresses had permanent fatal errors -----
01580 >>> <ro...@ultra.localhost>
01580 >>> (reason: 5)
01580 >>>
01580 >>> ----- Transcript of session follows -----
01580 >>> 451 4.0.0 putbody: write error: Broken pipe
01580 >>> mail: Options MUST PRECEDE persons
01580 >>> 554 5.3.0 unknown mailer error 5
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/delivery-status
01580 >>>
01580 >>> Reporting-MTA: dns; ultra.localhost
01580 >>> Received-From-MTA: DNS; localhost
01580 >>> Arrival-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> Final-Recipient: RFC822; ro...@ultra.localhost
01580 >>> Action: failed
01580 >>> Status: 5.0.0
01580 >>> Diagnostic-Code: X-Unix; 5
01580 >>> Last-Attempt-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/rfc822
01580 >>>
01580 >>> Return-Path: <MAILER-DAEMON>
01580 >>> Received: from localhost (localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2) id m4S6LpqX001580;
01580 >>> Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: <ro...@ultra.localhost>
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: multipart/report; report-type=delivery-status;
01580 >>> boundary="m4S6LpqX001580.1211955711/ultra.localhost"
01580 >>> Subject: Returned mail: see transcript for details
01580 >>> Auto-Submitted: auto-generated (failure)
01580 >>>
01580 >>> This is a MIME-encapsulated message
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>>
01580 >>> The original message was received at Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> from localhost [127.0.0.1]
01580 >>>
01580 >>> ----- The following addresses had permanent fatal errors -----
01580 >>> <ro...@ultra.localhost>
01580 >>> (reason: 5)
01580 >>>
01580 >>> ----- Transcript of session follows -----
01580 >>> 451 4.0.0 putbody: write error: Broken pipe
01580 >>> mail: Options MUST PRECEDE persons
01580 >>> 554 5.3.0 unknown mailer error 5
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/delivery-status
01580 >>>
01580 >>> Reporting-MTA: dns; ultra.localhost
01580 >>> Received-From-MTA: DNS; localhost
01580 >>> Arrival-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> Final-Recipient: RFC822; ro...@ultra.localhost
01580 >>> Action: failed
01580 >>> Status: 5.0.0
01580 >>> Diagnostic-Code: X-Unix; 5
01580 >>> Last-Attempt-Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost
01580 >>> Content-Type: message/rfc822
01580 >>>
01580 >>> Return-Path: <ro...@ultra.localhost>
01580 >>> Received: from ultra.localhost (localhost [127.0.0.1])
01580 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4S6LpqX001579
01580 >>> for <ro...@ultra.localhost>; Tue, 27 May 2008 23:21:51
-0700 (PDT)
01580 >>> Received: (from root@localhost)
01580 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4S6LptC001578
01580 >>> for root; Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Date: Tue, 27 May 2008 23:21:51 -0700 (PDT)
01580 >>> Message-Id: <200805280621....@ultra.localhost>
01580 >>> To: ro...@ultra.localhost
01580 >>> From: ro...@ultra.localhost
01580 >>> MIME-Version: 1.0
01580 >>> Content-Type: text/plain
01580 >>>
01580 >>> test
01580 >>>
01580 >>>
01580 >>> --m4S6LpqX001580.1211955711/ultra.localhost--
01580 >>>
01580 >>>
01580 >>> --m4S6LpqY001580.1211955711/ultra.localhost--
01580 >>>
01580 <<< mail: Options MUST PRECEDE persons
01580 <<< [EOF]

Per Hedeland

unread,

May 28, 2008, 7:33:45 PM5/28/08

to

In article <4B6%j.1273$iM3...@flpi150.ffdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>> Hm, removing SASL was perhaps a bit overkill at this point, but at least
>> now you know how to add it back in.:-)
>
>Am I correct in assuming I really don't need it for what I'm trying to
>do?

No, you will need it for sendmail to authenticate towards your ISP's
server.

>>> May 26 20:45:51 ultra sendmail[23746]: [ID 702911 mail.alert] unable to
>>> qualify my own domain name (ultra) -- using short name
>>
>> That's what you get if you don't have any domain at all - if you go with
>> .localhost, you need to rearrange your hosts file a bit so that sendmail
>> can figure out that the name of your host is ultra.localhost - like so:
>>
>> 127.0.0.1 localhost
>> 127.0.0.1 smarthost-local
>> 192.168.69.5 ultra.localhost ultra loghost
>>
>> Possibly you may need to put ultra.localhost at the end of the last line
>> instead of at the beginning to make Solaris happy - the above is the
>> "standard" way (the "canonical name" comes first, the others are
>> aliases), but sendmail can deal with either of them.
>
>Interesting -- the RFC seemed to indicate that I should be pointing to
>the loopback address(127.0.0.1) with this -- Did I misread that, or is
>there some strange magic going on where it's just as valid to point it
>to the real IP?

Well, I think the RFC is rather confusing on this issue - it is indeed
true that the only traditional use of "localhost" is as a
(fully-qualified) host name pointing to the loopback address - but if it
is the intent that it shouldn't be used for anything else, why then
discuss it in this context at all, and with ".localhost" as if it was a
"domain" that you could put host names "in"?

So, either you take the "must point at loppback" stance, in which case
foo.localhost and bar.localhost is out - foo and bar will never be able
to talk to each other:-) - or the "just a private domain that will never
be used on the Internet" stance - in which case you can put whatever
names and address you want there. Of course you *can* always do the
latter just because its all your local stuff anyway - but to avoid
confusion, both your own and others if you ask questions on the net, it
may be best to stick with the "only 'localhost', and must point at
loopback" variant.

Which still leaves you and others in your situation without a "safe"
domain name to use - unfortunately Giorgos didn't (yet) respond to my
question about whether ".priv" was some sort of standard, otherwise that
would be ideal.

But in any case, all sendmail really cares about here is being able to
find a name with a dot in for the local host, starting with the result
of the 'hostname' command (actually gethostname() in the C library).
If your hostname is 'ultra' and there is a line in /etc/hosts that has
both 'ultra' and 'ultra.whatever', it will be happy. If your hostname is
ultra.whatever it will be happy too, and not require that "special" line
in /etc/hosts - but Solaris will probably be unhappy.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 28, 2008, 7:42:37 PM5/28/08

to

In article <fB7%j.1293$iM3...@flpi150.ffdc.sbc.com> Dave Anderson

>02054 >>> 451 4.0.0 putbody: write error: Broken pipe
>02054 >>> mail: Options MUST PRECEDE persons
>02054 >>> 554 5.3.0 unknown mailer error 5

This is actually a FAQ, 3.13 - not very frequently asked anymore though,
since Sun's stuff has been brought more or less in line with the
standard sendmail, and I believe most Solaris users that replace the
sendmail binary either stick with Sun's mail.local or install something
completely different like procmail.

>An examination of the man pages for mail and mail.local indicates that
>for the versions I have(had), -r was a valid option for mail.local but
>not for mail. Do you think there's anything to this or am I chasing my tail?

I think your best bet (better than the advice in the FAQ) is to use
OSTYPE(solaris2.pre5) as I wrote, in case you're going to stick with
/usr/bin/mail - that's what it assumes.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 29, 2008, 2:47:32 AM5/29/08

to

.
.

.
>
> But in any case, all sendmail really cares about here is being able to
> find a name with a dot in for the local host, starting with the result
> of the 'hostname' command (actually gethostname() in the C library).
> If your hostname is 'ultra' and there is a line in /etc/hosts that has
> both 'ultra' and 'ultra.whatever', it will be happy. If your hostname is
> ultra.whatever it will be happy too, and not require that "special" line
> in /etc/hosts - but Solaris will probably be unhappy.
>

Thanks, that helps a lot. For my purposes, there seems to be no downside
to this approach.

Dave Anderson

unread,

May 29, 2008, 3:31:42 AM5/29/08

to

> I think your best bet (better than the advice in the FAQ) is to use
> OSTYPE(solaris2.pre5) as I wrote, in case you're going to stick with
> /usr/bin/mail - that's what it assumes.
>

OK, I changed the ostype as you suggested and now local mail works,
including bounce messages. Great progress, many thanks! :)

Now I'm just struggling with the auth. In the example below, "mailfile"
contains the following:

# cat mailfile
To: reci...@domain.com
From: authori...@domain.com

Test
#

Note that authori...@domain.com must be one of the addresses I set
up in the Yahoo Web tool as authorized "From" addresses that may send
email with my credentials... but the conversation between sendmail and
the smtp server never seems to get that far:

# /usr/lib/sendmail -Am -v -t < /root/mailtest/mailfile
reci...@domain.com... Connecting to smarthost-local.localhost. port
2525 via relay...
220 smtp124.sbc.mail.sp1.yahoo.com ESMTP
>>> EHLO ultra.localhost
250-smtp124.sbc.mail.sp1.yahoo.com
250-AUTH LOGIN PLAIN XYMCOOKIE
250-PIPELINING
250 8BITMIME
>>> MAIL From:<ro...@ultra.localhost> AUTH=ro...@ultra.localhost
530 authentication required - for help go to
http://help.yahoo.com/help/us/sbc/dsl/mail/pop/pop-11.html
/root/dead.letter... Saved message in /root/dead.letter
Closing connection to smarthost-local.localhost.
>>> QUIT
you have mail in /var/mail/root
#

I have done much searching and gnashing of teeth, and experimented with
many of the settings I found at these links(Note that SBC-Yahoo is now
ATT-Yahoo, so this stuff didn't seem completely irrelevant):

http://www.dslreports.com/faq/11247
http://efflandt.freeshell.org/sbc-smtp-auth.html

I'm not really sure what the right thing to do here is -- For now I've
put it back to the config that I copied in to the recent post that had
all of the logs.

One of the things that I find confusing is deciding how I need to set up
authinfo, when I am using stunnel and SMART_HOST is smarthost-local or
smarthost-local.localhost. In this case, is it confusing sendmail when I
tell it to send to that hostname and the response to EHLO is a different
hostname every time I run the command, smtp124..yahoo.com in the above
example? I have tried a number of variations on the following with the
same 530 error in all cases.

AuthInfo:smarthost-local.localhost "l:<uname>" "P:<passwd>" "M:PLAIN"

I thought of just using an IP address, but (a)I'm worried that will
change -- seems they have at least two smtp servers mapped to the same
name, apparently a load balancer -- and (b) I'm confused that I'm seeing
so many smtpxxx..yahoo.com hostnames which do not seem to be aliases of
the stated smtp.att.yahoo.com smtp server:

# nslookup smtp.att.yahoo.com
Server: home
Address: 192.168.69.1

Non-authoritative answer:
Name: smtp.sbc.mail.yahoo4.akadns.net
Address: 68.142.198.11
Aliases: smtp.att.yahoo.com, smtp-sbc.mail.yahoo.com

# nslookup smtp.att.yahoo.com
Server: home
Address: 192.168.69.1

Non-authoritative answer:
Name: smtp.sbc.mail.yahoo4.akadns.net
Address: 69.147.64.31
Aliases: smtp.att.yahoo.com, smtp-sbc.mail.yahoo.com

# nslookup smtp-sbc.mail.yahoo.com
Server: home
Address: 192.168.69.1

Non-authoritative answer:
Name: smtp.sbc.mail.yahoo4.akadns.net
Address: 69.147.64.31
Aliases: smtp-sbc.mail.yahoo.com

#

Per Hedeland

unread,

May 29, 2008, 5:41:01 PM5/29/08

to

In article <CZs%j.2705$N87...@nlpi068.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>Now I'm just struggling with the auth.

That's what you're *expected* to have to struggle with - the stuff
you've done so far should "just work".:-)

> >>> EHLO ultra.localhost
>250-smtp124.sbc.mail.sp1.yahoo.com
>250-AUTH LOGIN PLAIN XYMCOOKIE
>250-PIPELINING
>250 8BITMIME
> >>> MAIL From:<ro...@ultra.localhost> AUTH=ro...@ultra.localhost

So sendmail doesn't even attempt to authenticate (it should send an AUTH
command at the point where it sends MAIL). You did put SASL back in,
right? Better verify:

sendmail -d0.1 -bv root

You should have SASL (or maybe SASL2) in the "Compiled with:" list.

>One of the things that I find confusing is deciding how I need to set up
>authinfo, when I am using stunnel and SMART_HOST is smarthost-local or
>smarthost-local.localhost.

It should be the SMART_HOST name. Though actually, since you only ever
connect to one host, you can leave it out - i.e. have just the
"Authinfo:" tag in the LHS. Beware though that in that case, should you
ever connect somwhere else, sendmail will happily send your
username/password there:-) - it may be good for testing though.

> In this case, is it confusing sendmail when I
>tell it to send to that hostname and the response to EHLO is a different
>hostname every time I run the command, smtp124..yahoo.com in the above
>example?

No.

>AuthInfo:smarthost-local.localhost "l:<uname>" "P:<passwd>" "M:PLAIN"

Is that a posting typo, or do you actually have a lowercase l ("ell") in
there, instead of an uppercase I, for the username? You can probably use
U instead to avoid such errors.:-)

>I thought of just using an IP address, but (a)I'm worried that will
>change -- seems they have at least two smtp servers mapped to the same
>name, apparently a load balancer -- and (b) I'm confused that I'm seeing
>so many smtpxxx..yahoo.com hostnames which do not seem to be aliases of
>the stated smtp.att.yahoo.com smtp server:

In your setup, sendmail has no idea what the actual IP address of the
remote server is - it's talking to a host at 127.0.0.1. But the IP
address isn't relevant anyway.

If none of the above helps, check the log carefully for starters.

--Per Hedeland
p...@hedeland.org

Giorgos Keramidas

unread,

May 29, 2008, 7:58:49 PM5/29/08

to

On Wed, 28 May 2008 23:33:45 +0000 (UTC), p...@hedeland.org (Per Hedeland) wrote:
> Which still leaves you and others in your situation without a "safe"
> domain name to use - unfortunately Giorgos didn't (yet) respond to my
> question about whether ".priv" was some sort of standard, otherwise
> that would be ideal.

Hi Per. I missed that post. Now that I went through the thread more
carefully, I saw it:

: Date: Tue, 27 May 2008 05:58:10 +0000 (UTC)
: From: p...@hedeland.org (Per Hedeland)
: Subject: Re: Solaris 8 - Configuring sendmail relay (NoAuth inbound -> SSL outbound)
: Newsgroups: comp.mail.sendmail
: Message-ID: <g1g7ti$2jog$1...@hedeland.org>
:
: In article <6YK_j.5240$Ri....@flpi146.ffdc.sbc.com> Dave Anderson

: <r-...@pacbell.net> writes:
: >Giorgos Keramidas wrote:
: >>
: >> Instead of "myfake.net" you can use "ultra.anderson.priv".
:
: Is this some kind of standard that I have missed? If so it would seem to
: be just the thing for a setup like Dave's. Googling a bit I see a number
: of suggestions (at least one as a comment specifically to RFC 2606) that
: there is a need for a domain-name equivalent of the private networks
: listed in RFC 1918, but I can't see ".priv" actually being reserved for
: that purpose anywhere. A lookup for NS records gives NXDOMAIN, but that
: doesn't really say anything one way or the other in this case...:-)

No, I'm not aware of any RFC or other standard that recommends ".priv".
It is just one of the `very unlikely to be registered as a real TLD'
suffixes that I've seen used in several places. But as you correctly
write, the fact that it's not a registered TLD today doesn't say much
about any future updates to DNS.

It's arguably less likely that a new ".priv" TLD will appear than a new
subdomain of ".com" called "randomname.com", but that's still a bit of a
gamble :/

Dave Anderson

unread,

May 29, 2008, 11:48:39 PM5/29/08

to

> : >Giorgos Keramidas wrote:
> : >>
> : >> Instead of "myfake.net" you can use "ultra.anderson.priv".
> :
> : Is this some kind of standard that I have missed? If so it would seem to
> : be just the thing for a setup like Dave's. Googling a bit I see a number
> : of suggestions (at least one as a comment specifically to RFC 2606) that
> : there is a need for a domain-name equivalent of the private networks
> : listed in RFC 1918, but I can't see ".priv" actually being reserved for
> : that purpose anywhere. A lookup for NS records gives NXDOMAIN, but that
> : doesn't really say anything one way or the other in this case...:-)
>
> No, I'm not aware of any RFC or other standard that recommends ".priv".
> It is just one of the `very unlikely to be registered as a real TLD'
> suffixes that I've seen used in several places. But as you correctly
> write, the fact that it's not a registered TLD today doesn't say much
> about any future updates to DNS.
>
> It's arguably less likely that a new ".priv" TLD will appear than a new
> subdomain of ".com" called "randomname.com", but that's still a bit of a
> gamble :/
>

Thanks Giorgos, sounds reasonable, and less risky than what I was doing. :)

D

Dave Anderson

unread,

May 30, 2008, 1:07:41 AM5/30/08

to

> You should have SASL (or maybe SASL2) in the "Compiled with:" list.
>

Yes, I should have mentioned I put SASL back in on the last compile and
it passes the above test.

>> AuthInfo:smarthost-local.localhost "l:<uname>" "P:<passwd>" "M:PLAIN"
>
> Is that a posting typo, or do you actually have a lowercase l ("ell") in
> there, instead of an uppercase I, for the username? You can probably use
> U instead to avoid such errors.:-)

Damn and Blast! :) My mistake. Now sendmail is trying to authenticate
after changing that one character to 'I'.

At least, that's the way I read the following lines in the mail.log
file(whole session copied below -- this is initial state after fixing
'I' above)

12931 >>> AUTH PLAIN ci1uL...GF2Mw==
12931 <<< 235 ok, go ahead (#2.0.0)
12931 >>> MAIL From:<ro...@ultra.localhost> AUTH=<>
12931 <<< 553 From: address not verified; see

From the last 2 of those lines, I gather that their end is trying to
match up the address in the "From:" field with one of the approved
senders I had to set up from my account control panel.

I have done some poking around with masquerading and have managed to get
that line to look like:

12798 <<< 235 ok, go ahead (#2.0.0)
12798 >>> MAIL From:<my.e...@att.yahoo.com>
12798 <<< 553 From: address not verified; see

Note that "AUTH=<> was not sent in this case. However,
"my.e...@att.yahoo.com" should pass the verification check.

So I took a step back and removed the masquerading changes I had made, I
am at the stage where I get the log output mentioned below. Even when I
appear to be giving a valid "From:" address it is treated as invalid. I
get about the same result with either of the following two methods of
sending mail:

*METHOD 1*
# mail my.e...@att.yahoo.com
From: my.e...@att.yahoo.com
To: my.e...@att.yahoo.com

TestAgain 9:12
.
#

*METHOD 2*
/usr/lib/sendmail -t -F'$from_name' -f'$from_email'
(mail header & body piped to above command)

Ideally I would like to find a solution that allows $from_email in the
above example to be used for this check and be any one of my "approved"
senders -- there are 10 AFAIK though I have seven configured.
Thunderbird pulls this off, using only the set of credentials mentioned
in authinfo. If I can get method 1 (or a variation) to work that's a
bonus but not essential.

The smtp server seems to be ignoring the "From:" that I send in this
way. My guess is that this is what's tripping me up:

Return-Path: <ro...@ultra.localhost>

If this is the problem then I need to know the proper way to masquerade
this so that all relevant fields have the proper return path/From:/etc/
whether I am trying to send a mail that looks like it's from
"my.e...@att.yahoo.com" or "f...@bar.com". I would like my scripts to be
able to determine who the emails appear to be from, as I've done in the
past. It would be better if the "Apparently To:" field didn't contain my
primary email address as it does when I send from one of my "approved"
accounts using Thunderbird but if that can't be helped so be it.

Is there any more detailed logging that will help me understand the
problem, and/or can you point me to any detailed "how-to" info that
covers this contingency?

Thanks and Regards,

Dave A.

==============================
Full Session Log(Method 1) Follows:

sendmail run as: "/usr/lib/sendmail -bd -q1m -X /var/log/mail.log -oL9"

(NOTE: my primary email address has been substituted with
"my.e...@att.yahoo.com" in this log snippet)

12929 >>> 220 ultra.localhost ESMTP Sendmail 8.14.2/8.14.2; Thu, 29 May
2008 21:13:09 -0700 (PDT)
12929 <<< EHLO ultra.localhost
12929 >>> 250-ultra.localhost Hello localhost [127.0.0.1], pleased to
meet you
12929 >>> 250-ENHANCEDSTATUSCODES
12929 >>> 250-PIPELINING
12929 >>> 250-EXPN
12929 >>> 250-VERB
12929 >>> 250-8BITMIME
12929 >>> 250-SIZE
12929 >>> 250-DSN
12929 >>> 250-ETRN
12929 >>> 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
12929 >>> 250-DELIVERBY
12929 >>> 250 HELP
12929 <<< MAIL From:<ro...@ultra.localhost> SIZE=161
AUTH=ro...@ultra.localhost
12929 >>> 250 2.1.0 <ro...@ultra.localhost>... Sender ok
12929 <<< RCPT To:<my.e...@att.yahoo.com>
12929 >>> 250 2.1.5 <my.e...@att.yahoo.com>... Recipient ok
12929 <<< DATA
12929 >>> 354 Enter mail, end with "." on a line by itself
12929 <<< Received: (from root@localhost)
12929 <<< by ultra.localhost (8.14.2/8.14.2/Submit) id m4U4D8s7012928
12929 <<< for my.e...@att.yahoo.com; Thu, 29 May 2008 21:13:08
-0700 (PDT)
12929 <<< Date: Thu, 29 May 2008 21:13:08 -0700 (PDT)
12929 <<< Message-Id: <200805300413....@ultra.localhost>
12929 <<< From: my.e...@att.yahoo.com
12929 <<< To: my.e...@att.yahoo.com
12929 <<< MIME-Version: 1.0
12929 <<< Content-Type: text/plain
12929 <<<
12929 <<< TestAgain 9:12
12929 <<<
12929 <<< .
12929 >>> 250 2.0.0 m4U4D981012929 Message accepted for delivery
12929 <<< QUIT
12929 >>> 221 2.0.0 ultra.localhost closing connection
12931 === CONNECT smarthost-local.localhost.
12931 <<< 220 smtp124.sbc.mail.sp1.yahoo.com ESMTP
12931 >>> EHLO ultra.localhost
12931 <<< 250-smtp124.sbc.mail.sp1.yahoo.com
12931 <<< 250-AUTH LOGIN PLAIN XYMCOOKIE
12931 <<< 250-PIPELINING
12931 <<< 250 8BITMIME
12931 >>> AUTH PLAIN ci1uL...GF2Mw==
12931 <<< 235 ok, go ahead (#2.0.0)
12931 >>> MAIL From:<ro...@ultra.localhost> AUTH=<>
12931 <<< 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html553
From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html
12931 >>> This is a MIME-encapsulated message
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost
12931 >>>
12931 >>> The original message was received at Thu, 29 May 2008 21:13:10
-0700 (PDT)
12931 >>> from localhost [127.0.0.1]
12931 >>>
12931 >>> ----- The following addresses had permanent fatal errors -----
12931 >>> <my.e...@att.yahoo.com>
12931 >>> (reason: 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-0...om:
address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html)
12931 >>>
12931 >>> ----- Transcript of session follows -----
12931 >>> ... while talking to smarthost-local.localhost.:
12931 >>> >>> MAIL From:<ro...@ultra.localhost> AUTH=<>
12931 >>> <<< 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html553
From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html
12931 >>> 501 5.6.0 Data format error
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost
12931 >>> Content-Type: message/delivery-status
12931 >>>
12931 >>> Reporting-MTA: dns; ultra.localhost
12931 >>> Received-From-MTA: DNS; localhost
12931 >>> Arrival-Date: Thu, 29 May 2008 21:13:10 -0700 (PDT)
12931 >>>
12931 >>> Final-Recipient: RFC822; my.e...@att.yahoo.com
12931 >>> Action: failed
12931 >>> Status: 5.1.3
12931 >>> Diagnostic-Code: SMTP; 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html553
From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html
12931 >>> Last-Attempt-Date: Thu, 29 May 2008 21:13:14 -0700 (PDT)
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost
12931 >>> Content-Type: message/rfc822
12931 >>>
12931 >>> Return-Path: <ro...@ultra.localhost>
12931 >>> Received: from ultra.localhost (localhost [127.0.0.1])
12931 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4U4D981012929
12931 >>> for <my.e...@att.yahoo.com>; Thu, 29 May 2008 21:13:10
-0700 (PDT)
12931 >>> Received: (from root@localhost)
12931 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4U4D8s7012928
12931 >>> for my.e...@att.yahoo.com; Thu, 29 May 2008 21:13:08
-0700 (PDT)
12931 >>> Date: Thu, 29 May 2008 21:13:08 -0700 (PDT)
12931 >>> Message-Id: <200805300413....@ultra.localhost>
12931 >>> From: my.e...@att.yahoo.com
12931 >>> To: my.e...@att.yahoo.com
12931 >>> MIME-Version: 1.0
12931 >>> Content-Type: text/plain
12931 >>>
12931 >>> TestAgain 9:12
12931 >>>
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost--
12931 >>>
12931 === EXEC mail -f MAILER-DAEMON -d root
12931 >>> Received: from localhost (localhost)
12931 >>> by ultra.localhost (8.14.2/8.14.2) id m4U4DE81012931;
12931 >>> Thu, 29 May 2008 21:13:14 -0700 (PDT)
12931 >>> Date: Thu, 29 May 2008 21:13:14 -0700 (PDT)
12931 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
12931 >>> Message-Id: <200805300413....@ultra.localhost>
12931 >>> To: <ro...@ultra.localhost>
12931 >>> MIME-Version: 1.0
12931 >>> Content-Type: multipart/report; report-type=delivery-status;
12931 >>> boundary="m4U4DE81012931.1212120794/ultra.localhost"
12931 >>> Subject: Returned mail: see transcript for details
12931 >>> Auto-Submitted: auto-generated (failure)
12931 >>>
12931 >>> This is a MIME-encapsulated message
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost
12931 >>>
12931 >>> The original message was received at Thu, 29 May 2008 21:13:10
-0700 (PDT)
12931 >>> from localhost [127.0.0.1]
12931 >>>
12931 >>> ----- The following addresses had permanent fatal errors -----
12931 >>> <my.e...@att.yahoo.com>
12931 >>> (reason: 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-0...om:
address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html)
12931 >>>
12931 >>> ----- Transcript of session follows -----
12931 >>> ... while talking to smarthost-local.localhost.:
12931 >>> >>> MAIL From:<ro...@ultra.localhost> AUTH=<>
12931 >>> <<< 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html553
From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html
12931 >>> 501 5.6.0 Data format error
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost
12931 >>> Content-Type: message/delivery-status
12931 >>>
12931 >>> Reporting-MTA: dns; ultra.localhost
12931 >>> Received-From-MTA: DNS; localhost
12931 >>> Arrival-Date: Thu, 29 May 2008 21:13:10 -0700 (PDT)
12931 >>>
12931 >>> Final-Recipient: RFC822; my.e...@att.yahoo.com
12931 >>> Action: failed
12931 >>> Status: 5.1.3
12931 >>> Diagnostic-Code: SMTP; 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html553
From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html
12931 >>> Last-Attempt-Date: Thu, 29 May 2008 21:13:14 -0700 (PDT)
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost
12931 >>> Content-Type: message/rfc822
12931 >>>
12931 >>> Return-Path: <ro...@ultra.localhost>
12931 >>> Received: from ultra.localhost (localhost [127.0.0.1])
12931 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m4U4D981012929
12931 >>> for <my.e...@att.yahoo.com>; Thu, 29 May 2008 21:13:10
-0700 (PDT)
12931 >>> Received: (from root@localhost)
12931 >>> by ultra.localhost (8.14.2/8.14.2/Submit) id m4U4D8s7012928
12931 >>> for my.e...@att.yahoo.com; Thu, 29 May 2008 21:13:08
-0700 (PDT)
12931 >>> Date: Thu, 29 May 2008 21:13:08 -0700 (PDT)
12931 >>> Message-Id: <200805300413....@ultra.localhost>
12931 >>> From: my.e...@att.yahoo.com
12931 >>> To: my.e...@att.yahoo.com
12931 >>> MIME-Version: 1.0
12931 >>> Content-Type: text/plain
12931 >>>
12931 >>> TestAgain 9:12
12931 >>>
12931 >>>
12931 >>> --m4U4DE81012931.1212120794/ultra.localhost--
12931 >>>
12931 <<< [EOF]
12931 >>> QUIT
12931 <<< [EOF]

Per Hedeland

unread,

May 30, 2008, 2:32:14 AM5/30/08

to

In article <8763swu...@kobe.laptop> Giorgos Keramidas
<kera...@ceid.upatras.gr> writes:
>: From: p...@hedeland.org (Per Hedeland)

>: Is this some kind of standard that I have missed? If so it would seem to
>: be just the thing for a setup like Dave's. Googling a bit I see a number
>: of suggestions (at least one as a comment specifically to RFC 2606) that
>: there is a need for a domain-name equivalent of the private networks
>: listed in RFC 1918, but I can't see ".priv" actually being reserved for
>: that purpose anywhere. A lookup for NS records gives NXDOMAIN, but that
>: doesn't really say anything one way or the other in this case...:-)
>
>No, I'm not aware of any RFC or other standard that recommends ".priv".
>It is just one of the `very unlikely to be registered as a real TLD'
>suffixes that I've seen used in several places.

Thanks for that - and even if it just is, or is becoming, a "de facto"
standard, that may in practice prevent it from becoming a "normal" TLD.
Do you have some references to the "places", in particular discussion by
people whose opinions on the subject may matter?:-) Google wasn't very
helpful due to the many false hits.

> But as you correctly
>write, the fact that it's not a registered TLD today doesn't say much
>about any future updates to DNS.

Yes, even if it *was* a standard, the particular intended use might mean
that it shouldn't be registered anyway (unclear though - .example.com
has NS records, .invalid hasn't).

>It's arguably less likely that a new ".priv" TLD will appear than a new
>subdomain of ".com" called "randomname.com", but that's still a bit of a
>gamble :/

At least new TLDs require some amount of administrativia IIRC...

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 30, 2008, 2:46:45 AM5/30/08

to

In article <DYL%j.3225$co7....@nlpi066.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>
>Damn and Blast! :) My mistake. Now sendmail is trying to authenticate
>after changing that one character to 'I'.
>
>At least, that's the way I read the following lines in the mail.log
>file(whole session copied below -- this is initial state after fixing
>'I' above)

Great! Yes, it is authenticating - successfully.

>12931 >>> AUTH PLAIN ci1uL...GF2Mw==
>12931 <<< 235 ok, go ahead (#2.0.0)
>12931 >>> MAIL From:<ro...@ultra.localhost> AUTH=<>
>12931 <<< 553 From: address not verified; see
>
> From the last 2 of those lines, I gather that their end is trying to
>match up the address in the "From:" field with one of the approved
>senders I had to set up from my account control panel.

Seems likely. Don't they tell you *where* to "see"?

>I have done some poking around with masquerading and have managed to get
>that line to look like:
>
>12798 <<< 235 ok, go ahead (#2.0.0)
>12798 >>> MAIL From:<my.e...@att.yahoo.com>
>12798 <<< 553 From: address not verified; see
>
>Note that "AUTH=<> was not sent in this case. However,
>"my.e...@att.yahoo.com" should pass the verification check.

That seems fine to me - they surely don't require the AUTH=, but AUTH=<>
may throw them off.

>So I took a step back and removed the masquerading changes I had made, I
>am at the stage where I get the log output mentioned below. Even when I
>appear to be giving a valid "From:" address it is treated as invalid. I
>get about the same result with either of the following two methods of
>sending mail:

The address on the MAIL command is the envelope sender address, which
you can set with -f on direct sendmail invocation, and which any SMTP
client will give on its own MAIL command. There's no way to set it with
"stupid" MUAs like 'mail' - with 'mailx' a.k.a. 'Mail' you can specify
an alternative "sendmail" command that can be a script that sets it, but
that's a bit of a pain. This is the stuff that masquerading in sendmail
is for.

>Thunderbird pulls this off, using only the set of credentials mentioned
>in authinfo.

You could perhaps tell T-bird to use your stunnel setup (i.e. port 2525,
no SSL/TLS) and 'truss' stunnel (or use 'snoop') to see what it sends
that is different from sendmail.

>Return-Path: <ro...@ultra.localhost>

Hm, that's weird - the Return-Path is set from the envelope sender
address - whether you use -f or masquerading (including
masquerade_envelope), it should be reflected there. But anyway the
rejection happens before the remote has seen any headers (those come
after DATA), so it can't be that (yet:-).

> It would be better if the "Apparently To:" field didn't contain my
>primary email address as it does when I send from one of my "approved"
>accounts using Thunderbird but if that can't be helped so be it.

Hm, where are you seeing the (presumably) Apparently-To: header?

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 30, 2008, 3:58:30 AM5/30/08

to

>> 12931 >>> AUTH PLAIN ci1uL...GF2Mw==
>> 12931 <<< 235 ok, go ahead (#2.0.0)
>> 12931 >>> MAIL From:<ro...@ultra.localhost> AUTH=<>
>> 12931 <<< 553 From: address not verified; see
>>
>> From the last 2 of those lines, I gather that their end is trying to
>> match up the address in the "From:" field with one of the approved
>> senders I had to set up from my account control panel.
>
> Seems likely. Don't they tell you *where* to "see"?

Yes, it's a link that you wouldn't be able to view without a sign-in,
but I copied the text of the page at that link in this message:
news://news.sf.sbcglobal.net:119/9e77916c-3ca5-4b00...@b5g2000pri.googlegroups.com
(Message I posted here @ 5:35pm PST)

I truncated that for readability -- the full log at the bottom of my
post from earlier today contains the complete message back from the SMTP
server at that point.

>
>> I have done some poking around with masquerading and have managed to get
>> that line to look like:
>>
>> 12798 <<< 235 ok, go ahead (#2.0.0)
>> 12798 >>> MAIL From:<my.e...@att.yahoo.com>
>> 12798 <<< 553 From: address not verified; see
>>
>> Note that "AUTH=<> was not sent in this case. However,
>> "my.e...@att.yahoo.com" should pass the verification check.
>
> That seems fine to me - they surely don't require the AUTH=, but AUTH=<>
> may throw them off.

OK, I don't know how to control that exactly, but it sounds like I
shouldn't worry about that for the moment.

>
>> So I took a step back and removed the masquerading changes I had made, I
>> am at the stage where I get the log output mentioned below. Even when I
>> appear to be giving a valid "From:" address it is treated as invalid. I
>> get about the same result with either of the following two methods of
>> sending mail:
>
> The address on the MAIL command is the envelope sender address, which
> you can set with -f on direct sendmail invocation, and which any SMTP
> client will give on its own MAIL command. There's no way to set it with
> "stupid" MUAs like 'mail' - with 'mailx' a.k.a. 'Mail' you can specify
> an alternative "sendmail" command that can be a script that sets it, but
> that's a bit of a pain. This is the stuff that masquerading in sendmail
> is for.

That's what I thought based on what I've read, I'm just not sure how
exactly to set that up for my situation.

>
>> Thunderbird pulls this off, using only the set of credentials mentioned
>> in authinfo.
>
> You could perhaps tell T-bird to use your stunnel setup (i.e. port 2525,
> no SSL/TLS) and 'truss' stunnel (or use 'snoop') to see what it sends
> that is different from sendmail.

I thought I had posted a packet trace from Thunderbird earlier in this
thread. What you're saying here is compare T-bird vs sendmail
truss/snoop output?

>
>> Return-Path: <ro...@ultra.localhost>
>
> Hm, that's weird - the Return-Path is set from the envelope sender
> address - whether you use -f or masquerading (including
> masquerade_envelope), it should be reflected there. But anyway the
> rejection happens before the remote has seen any headers (those come
> after DATA), so it can't be that (yet:-).

Could it be checking DNS for a valid domain name based on this -- and
choking?

12931 >>> EHLO ultra.localhost

>
>> It would be better if the "Apparently To:" field didn't contain my
>> primary email address as it does when I send from one of my "approved"
>> accounts using Thunderbird but if that can't be helped so be it.
>
> Hm, where are you seeing the (presumably) Apparently-To: header?

I'm seeing that in the header when I use T-bird to send from one of
these "approved" addresses to my primary email address. This is a
problem when, for example, my girlfriend wants to use one of my scripts
to send out a newsletter to a list of her clients. I prefer not to have
my private email address go out in her business correspondence - even if
it's in a relatively obscure header field that doesn't show up by
default in most mail clients.

Per Hedeland

unread,

May 30, 2008, 4:29:01 PM5/30/08

to

In article <LsO%j.5152$mh5....@nlpi067.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>> Seems likely. Don't they tell you *where* to "see"?
>
>Yes, it's a link that you wouldn't be able to view without a sign-in,
>but I copied the text of the page at that link in this message:

Aha, that old stuff again:-) - doesn't say anything about address
verification though as far as I can see.

>> The address on the MAIL command is the envelope sender address, which
>> you can set with -f on direct sendmail invocation, and which any SMTP
>> client will give on its own MAIL command. There's no way to set it with
>> "stupid" MUAs like 'mail' - with 'mailx' a.k.a. 'Mail' you can specify
>> an alternative "sendmail" command that can be a script that sets it, but
>> that's a bit of a pain. This is the stuff that masquerading in sendmail
>> is for.
>
>That's what I thought based on what I've read, I'm just not sure how
>exactly to set that up for my situation.

As far as could be judged from the SMTP session, your setup looked fine.

>I thought I had posted a packet trace from Thunderbird earlier in this
>thread.

Quite possible, but I don't expect to be able to find even though I have
the latest month worth of posts sitting on local disk... - and I
wouldn't expect it to be useful either:

> What you're saying here is compare T-bird vs sendmail
>truss/snoop output?

Yes, but the packet trace as such is irrelevant, it's the cleartext
content of the SMTP session that could be interesting to compare. No
need to truss/snoop sendmail for that, it will happily show it to you as
you've found out - but AFAIK there's no way to get T-bird to do the
same, and if you've done a packet trace of its SSL session it is of
course completely useless for that purpose. But if you get T-bird to
talk cleartext to ssltunnel, you could capture the cleartext.

>Could it be checking DNS for a valid domain name based on this -- and
>choking?
>
>12931 >>> EHLO ultra.localhost

Very unlikely - in general a spam-fighting MTA could do that even though
it would violate the RFCs, but there's no way the SMTP server provided
for the use of ISP customers could get away with it I think. But if
you're running sendmail 8.14.x, you could set it with confHELO_NAME in
the .mc file - the domain-part (i.e. everything after '@') of your
"primary" e-mail address might be a good choice - it's totally wrong,
but that's what GUI MUAs tend to do.

>> Hm, where are you seeing the (presumably) Apparently-To: header?
>
>I'm seeing that in the header when I use T-bird to send from one of
>these "approved" addresses to my primary email address.

Uh, let me rephrase - does this have anything at all to do with your
sendmail installation? And if so what?

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 31, 2008, 1:27:07 PM5/31/08

to

Per Hedeland wrote:
> In article <LsO%j.5152$mh5....@nlpi067.nbdc.sbc.com> Dave Anderson
> <r-...@pacbell.net> writes:
>>> Seems likely. Don't they tell you *where* to "see"?
>> Yes, it's a link that you wouldn't be able to view without a sign-in,
>> but I copied the text of the page at that link in this message:
>
> Aha, that old stuff again:-) - doesn't say anything about address
> verification though as far as I can see.

Right, it's not mentioned there, but it's mentioned on another page
that, again, provides no technical details -- only that the user must go
through their web UI, specify that some.oth...@domain.com is
allowed to send using the user's credentials. After entering this info,
an email is sent to some.oth...@domain.com with a verification code
to be entered (again, in the ISP's web UI) before sending "From:
some.oth...@domain.com" is allowed.
>

> But if you get T-bird to
> talk cleartext to ssltunnel, you could capture the cleartext.
>

OK, I accomplished this, and it was so clear to me that the proper email
was being submitted for verification that I won't bother posting the
details here. The thing that I realized during this experiment was that
T-bird was having no problem sending when it passed
first...@myotherdomain.com but when I changed it to
second...@myotherdomain.com (which is used by the script I was
testing) T-bird was also provoking the 553 error. I set up the script to
use second...@myotherdomain.com and it was able to send email!

So I called the ISP support line and after a frustrating ~30 minutes
talking with the Hindi-as-a-first-language support rep named Melissa
(LOL) and going through a mind-numbing repetition of the steps that they
describe on their site(Which I had done before a few times) the call was
escalated to a second-level support rep who clearly had a lot more
expertise with this than the canned info available from first-level support.

This second-level support rep was very sharp and on the ball, and she
wiped the database of "Approved senders" from my account and stepped me
through setting them up again. Due to her actions, these setup steps
worked a bit differently this time, presenting new UI elements that had
not been there before("Verify" button where none was appearing before),
and it solved the problem. Apparently it was a glitch on their end;
apparently not all of the "Approved senders" lists had been migrated
properly during some recent work they have been doing.

So now I can:

1) Relay from my insecure clients
2) Send email from my script
3) Send email from /usr/bin/mail by piping a file with proper headers
(via "/usr/lib/sendmail -Am -v -t < /root/mailtest/mailfile")

So -- again many thanks for your help -- the problem is solved, my
initial requirements are met! I truly appreciate your patience and
expertise.

>>> Hm, where are you seeing the (presumably) Apparently-To: header?
>> I'm seeing that in the header when I use T-bird to send from one of
>> these "approved" addresses to my primary email address.
>
> Uh, let me rephrase - does this have anything at all to do with your
> sendmail installation? And if so what?
>

OK, I am only seeing that in situations where I don't care -- when
relaying from one of my insecure clients, when sending via T-bird either
directly via SSL or via stunnel. However, when sending from one of my
scripts, e.g. when the better half wants to send emails to her client
list, I am seeing stuff in the header that I would prefer not to reveal
in such cases. Consider the following message source:

====================[Begin message source]====================
From - Sat May 31 08:27:41 2008
X-Account-Key: account5
X-UIDL: 1k2sUUPr3NZFmD1
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:

Status: U
Return-Path: <sen...@sender.com>
Received: from noehlo.host ([127.0.0.1])
by whmx-joyous.pas.sa.earthlink.net (EarthLink SMTP Server) with SMTP
id 1k2sUUPr3NZFmD0; Sat, 31 May 2008 08:22:48 -0700 (PDT)
Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90])
by whmx-joyous.pas.sa.earthlink.net (EarthLink SMTP Server) with SMTP
id 1k2sUU6R73NZFmD0
for <2nd.re...@recipient.com>; Sat, 31 May 2008 08:22:48 -0700 (PDT)
Received: (qmail 53263 invoked from network); 31 May 2008 15:22:48 -0000
Received: from unknown (HELO ultra.localhost)
(primary...@pacbell.net@71.101.70.4 with plain)
by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 31 May 2008 15:22:47 -0000
X-YMail-OSG:
koUKnTAVM1nYWzxu5x9R6u9Eqdy16coUEDAEJudHVZnNxG6zuCRTMOdz2vk9OENB.gLogUQCpGud2zDBmw.DNOo9CKnVKpPne4QtgVQf8t0YQ_wmC_K0n_W0VRx_MCQOFYw-
X-Yahoo-Newman-Property: ymail-3

Received: from ultra.localhost (localhost [127.0.0.1])

by ultra.localhost (8.14.2/8.14.2) with ESMTP id m4VFMkce015481
for <2nd.re...@recipient.com>; Sat, 31 May 2008 08:22:46 -0700 (PDT)
Received: (from nobody@localhost)
by ultra.localhost (8.14.2/8.14.2/Submit) id m4VFMk9R015480;
Sat, 31 May 2008 08:22:46 -0700 (PDT)
Date: Sat, 31 May 2008 08:22:46 -0700 (PDT)
From: sen...@sender.com
Message-Id: <200805311522....@ultra.localhost>
X-Authentication-Warning: ultra.localhost: nobody set sender to
sen...@sender.com using -f
To: 2nd.re...@recipient.com
Subject: Product Feedback
X-ELNK-Received-Info: spv=0;
X-ELNK-AV: 0
X-ELNK-Info: sbv=0; sbrc=.0; sbf=00; sbw=000;

Mail from: te...@domain.com

test 5/31 8:22am
====================[End message source]====================

Most of this looks fine; I am not worried about revealing the
ultra.localhost stuff, but if I can avoid seeing
"primary...@pacbell.net@71.101.70.4" (or at least, avoid seeing
"primary...@pacbell.net") in the header of the email that is
ultimately received as a result of this process, I would be very pleased.

Is this possible with a reasonable amount of effort? These emails
should, even on close inspection of the headers, appear to be from
sen...@sender.com. Maybe that falls into the "unacceptable spammer-like
hacks" territory, but I have a legit reason for wanting to do this;
emails that she sends related to her business should not contain my
private email address if at all possible.

Thanks and regards,

Dave A.

Dave Anderson

unread,

May 31, 2008, 1:29:32 PM5/31/08

to

Should have added -- I am almost done with my write-up, I'd like to send
it to you for review before posting here in case I've missed something,
or in case it ought to contain more caveats and cautions. Would you mind
taking a look?

Per Hedeland

unread,

May 31, 2008, 4:18:53 PM5/31/08

to

In article <6Wf0k.1463$89....@nlpi069.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>Should have added -- I am almost done with my write-up, I'd like to send
>it to you for review before posting here in case I've missed something,
>or in case it ought to contain more caveats and cautions. Would you mind
>taking a look?

Yeah, I guess I can do that.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

May 31, 2008, 4:16:52 PM5/31/08

to

In article <VTf0k.1462$89....@nlpi069.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>3) Send email from /usr/bin/mail by piping a file with proper headers
>(via "/usr/lib/sendmail -Am -v -t < /root/mailtest/mailfile")

-Am is fine for testing, but requires root privilege - no reason to use
it for general mail sending.

>>>> Hm, where are you seeing the (presumably) Apparently-To: header?
>>> I'm seeing that in the header when I use T-bird to send from one of
>>> these "approved" addresses to my primary email address.
>>
>> Uh, let me rephrase - does this have anything at all to do with your
>> sendmail installation? And if so what?
>>
>
>OK, I am only seeing that in situations where I don't care -- when
>relaying from one of my insecure clients, when sending via T-bird either
>directly via SSL or via stunnel.

Still no answer...:-) - but at least your T-bird sending does not
involve your sendmail installation at all as far as I can see (it could
though).

> However, when sending from one of my
>scripts, e.g. when the better half wants to send emails to her client
>list, I am seeing stuff in the header that I would prefer not to reveal
>in such cases. Consider the following message source:

[snip]

>Received: from unknown (HELO ultra.localhost)
>(primary...@pacbell.net@71.101.70.4 with plain)
> by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 31 May 2008 15:22:47 -0000

>Most of this looks fine; I am not worried about revealing the

>ultra.localhost stuff, but if I can avoid seeing
>"primary...@pacbell.net@71.101.70.4" (or at least, avoid seeing
>"primary...@pacbell.net") in the header of the email that is
>ultimately received as a result of this process, I would be very pleased.

This is added by your ISP's mail server ("by
smtp117.sbc.mail.sp1.yahoo.com"), apparently based on your
authentication.

>Is this possible with a reasonable amount of effort?

Well, you're the one with experience of talking to your ISP:-) - that's
the only way to get it changed, there's nothing you can do to your local
setup to affect it.

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

May 31, 2008, 5:59:03 PM5/31/08

to

Per Hedeland wrote:
> In article <VTf0k.1462$89....@nlpi069.nbdc.sbc.com> Dave Anderson
> <r-...@pacbell.net> writes:
>> 3) Send email from /usr/bin/mail by piping a file with proper headers
>> (via "/usr/lib/sendmail -Am -v -t < /root/mailtest/mailfile")
>
> -Am is fine for testing, but requires root privilege - no reason to use
> it for general mail sending.
>

Yes, that is just for testing -- one of the various use cases that I
tried to verify that all was well.

>>>>> Hm, where are you seeing the (presumably) Apparently-To: header?
>>>> I'm seeing that in the header when I use T-bird to send from one of
>>>> these "approved" addresses to my primary email address.
>>> Uh, let me rephrase - does this have anything at all to do with your
>>> sendmail installation? And if so what?
>>>
>> OK, I am only seeing that in situations where I don't care -- when
>> relaying from one of my insecure clients, when sending via T-bird either
>> directly via SSL or via stunnel.
>
> Still no answer...:-) - but at least your T-bird sending does not
> involve your sendmail installation at all as far as I can see (it could
> though).
>

OK, I apologize for being obtuse; Initially I saw it when using T-bird
to send mail from one of my "approved" email addresses to my primary
email account(I manage all email for both of these accounts in the same
T-bird profile). At that point in time sendmail was not working for me
in this scenario and I was observing the behavior of T-bird in order to
better understand what steps sendmail needed to perform in order to send
successfully.

I was asking if this behavior would carry over to my sendmail
implementation, and if so what could I do to prevent that information
from being received by the recipient. Along the way I noticed that my
primary email was being revealed not only on the "Apparently-To:" line
but also on the "Received:" line, prompting the question below.

>> Most of this looks fine; I am not worried about revealing the
>> ultra.localhost stuff, but if I can avoid seeing
>> "primary...@pacbell.net@71.101.70.4" (or at least, avoid seeing
>> "primary...@pacbell.net") in the header of the email that is
>> ultimately received as a result of this process, I would be very pleased.
>
> This is added by your ISP's mail server ("by
> smtp117.sbc.mail.sp1.yahoo.com"), apparently based on your
> authentication.
>
>> Is this possible with a reasonable amount of effort?
>
> Well, you're the one with experience of talking to your ISP:-) - that's
> the only way to get it changed, there's nothing you can do to your local
> setup to affect it.
>

OK, thanks. Scratch that idea. I don't think any email client would
display that unless it were showing full headers; most folks would never
see it so it's not a big deal. I was just trying to keep it tidy. :)

Dave Anderson

unread,

May 31, 2008, 7:24:15 PM5/31/08

to

Thanks, it's on its way. I appreciate it, most of the information was
gathered wiwth your help. :)

D

Per Hedeland

unread,

Jun 1, 2008, 6:33:13 PM6/1/08

to

In article <G6l0k.5821$mh5....@nlpi067.nbdc.sbc.com> Dave Anderson

<r-...@pacbell.net> writes:
>Per Hedeland wrote:
>> In article <6Wf0k.1463$89....@nlpi069.nbdc.sbc.com> Dave Anderson
>> <r-...@pacbell.net> writes:
>>> Should have added -- I am almost done with my write-up, I'd like to send
>>> it to you for review before posting here in case I've missed something,
>>> or in case it ought to contain more caveats and cautions. Would you mind
>>> taking a look?
>>
>> Yeah, I guess I can do that.

>Thanks, it's on its way. I appreciate it, most of the information was

>gathered wiwth your help. :)

Unfortunately the reply bounces, since pbimail8.prodigy.net claims that
my IP address is blocked, and to get it unblocked I apparently have to
tell them that I have corrected some problem - but they're not saying
why they have blocked the IP address in the first place...

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

Jun 1, 2008, 11:15:08 PM6/1/08

to

> Unfortunately the reply bounces, since pbimail8.prodigy.net claims that
> my IP address is blocked, and to get it unblocked I apparently have to
> tell them that I have corrected some problem - but they're not saying
> why they have blocked the IP address in the first place...
>
> --Per Hedeland
> p...@hedeland.org

You probably already know this, but for those reading along you may have
been improperly blacklisted. Some info on this sort of thing here:

http://dedicated.pacbell.net/faq/FAQs_blacklist.html

Giorgos Keramidas

unread,

Jun 1, 2008, 10:33:28 PM6/1/08

to

On Fri, 30 May 2008 06:32:14 +0000 (UTC), p...@hedeland.org (Per Hedeland) wrote:
> In article <8763swu...@kobe.laptop> Giorgos Keramidas writes:
>>: From: p...@hedeland.org (Per Hedeland)
>>: Is this some kind of standard that I have missed? If so it would
>>: seem to be just the thing for a setup like Dave's. Googling a bit I
>>: see a number of suggestions (at least one as a comment specifically
>>: to RFC 2606) that there is a need for a domain-name equivalent of
>>: the private networks listed in RFC 1918, but I can't see ".priv"
>>: actually being reserved for that purpose anywhere. A lookup for NS
>>: records gives NXDOMAIN, but that doesn't really say anything one way
>>: or the other in this case...:-)
>>
>> No, I'm not aware of any RFC or other standard that recommends
>> ".priv". It is just one of the `very unlikely to be registered as a
>> real TLD' suffixes that I've seen used in several places.
>
> Thanks for that - and even if it just is, or is becoming, a "de facto"
> standard, that may in practice prevent it from becoming a "normal"
> TLD. Do you have some references to the "places", in particular
> discussion by people whose opinions on the subject may matter?:-)
> Google wasn't very helpful due to the many false hits.

Hi Per,

I'm sorry, but no. At least not references from people whose opinion
would count a lot, because they _are_ involved in TLD registration or
the design of DNS.

I've just seen ".priv" in 2-3 companies that I've worked for as an
employee, and a few which hired me as a consultant. Most of these are
small-ish companies around Greece.

Per Hedeland

unread,

Jun 2, 2008, 4:13:41 PM6/2/08

to

In article <8BJ0k.4168$jI5....@flpi148.ffdc.sbc.com> Dave Anderson
<r-...@pacbell.net> writes:
>[I wrote:]

>> Unfortunately the reply bounces, since pbimail8.prodigy.net claims that
>> my IP address is blocked, and to get it unblocked I apparently have to
>> tell them that I have corrected some problem - but they're not saying
>> why they have blocked the IP address in the first place...

>You probably already know this, but for those reading along you may have
>been improperly blacklisted.

Undoubtedly, but apparently only at your ISP / e-mail provider (the IP
address is not listed by any of the 3 3rd party dnsbls they refer to).
Since they're blocking e-mail that you have specifically asked for, I
thought you might want to know.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,

Jun 2, 2008, 4:17:17 PM6/2/08

to

In article <877id8f...@kobe.laptop> Giorgos Keramidas

<kera...@ceid.upatras.gr> writes:
>On Fri, 30 May 2008 06:32:14 +0000 (UTC), p...@hedeland.org (Per
>Hedeland) wrote:

>> [ about .priv TLD ]

>>
>> Thanks for that - and even if it just is, or is becoming, a "de facto"
>> standard, that may in practice prevent it from becoming a "normal"
>> TLD. Do you have some references to the "places", in particular
>> discussion by people whose opinions on the subject may matter?:-)
>> Google wasn't very helpful due to the many false hits.

>I'm sorry, but no. At least not references from people whose opinion

>would count a lot, because they _are_ involved in TLD registration or
>the design of DNS.

OK, thanks anyway - I guess we'll just work towards making it more "de
facto" by recommending its use then.:-)

--Per Hedeland
p...@hedeland.org

Dave Anderson

unread,

Jun 7, 2008, 10:45:31 AM6/7/08

to

First of all, many heartfelt thanks to Per Hedeland for his patience and
expertise helping me though this. Without his aid there is not telling
how long I might have been chasing my tail.

====================[Problem]====================
AT&T Yahoo has recently tightened up their SMTP security. If your smtp
server is smtp.att.yahoo.com (probably others they control as well) then
the default sendmail installed with Solaris 8 will no longer be able to
send mail. Their goal is to disallow any email client software that
cannot make an SSL connection to smpt.att.yahoo.com port 465.

In addition to killing sendmail for me, this change has broken several
utility clients that I have which send emails when certain error or
warning condidtions arise -- power outage, RAID system drive failure,
etc. since they do not support SSL, let alone port assignment.

Also note, many of the problems that I had are particular to Solaris 8.
Solaris 10 should have most of this already installed. As I say below --
if you're not sure, ASK QUESTIONS.

This solution is also specific to AT&T Yahoo, since they do not support
STARTTLS and I needed an SMTPS version of SSL that is not a part of
sendmail. I am no expert in these matters, but I gather that if they did
support STARTTLS a different approach altogether would have been
appropriate. I personally chose not to go with Solaris 10 because for my
purposes Solaris 8 is entirely adequate. The pain and suffering of
getting sendmail to work properly ended up being far less trouble, in my
opinion, than installing Solaris 10 and migrating all of my other apps,
utilities, KDE, etc. -- your mileage may vary.

DO NOT ATTEMPT TO FOLLOW THESE STEPS VERBATIM UNLESS YOU ARE TRYING TO
GET SOLARIS 8 TO SEND/RELAY TO smtp.att.yahoo.com. If you are not trying
to solve the exact same problem, read through the rest of this thread
where the problem was characterized, e.g. telnet to the mail server and
examine the output, make sure you proceed in the correct manner
depending on what that tells you. Unless you know EXACTLY what you are
doing, ask questions. There is a lot of expertise on comp.mail.sendmail
and asking a few questions and doing a little homework before you do
anything will save you a lot of grief REGARDLESS of your specific
requirements.

====================[Requirements]====================
To recap, here were my requirements:

1) Have the ability to test CGI scripts that I am developing, which
attempt to send emails in a safe manner.*

2) Have the ability to send emails to myself and other interested parties
from utility scripts that I run from cron.**

3) Relay mail from insecure clients such as my APC Powerchute Business
Edition email notifications, my 3ware RAID controller email notifications,
and others to an SMTP server that requires SSL, namely smtp.att.yahoo.com
port 465.

And my non-requirements(I'm behind a good firewall/router/NAT):

1) I am not worried about spammers being able to hijack my relay.
2) I am not worried about any kind of malware taking advantage of my less
than optimal config.
3) I am not worried about users doing nasty things with sendmail. For all
intents and purposes, I am the only user.

* e.g.:

1: #!/usr/bin/perl -T
2: .
3: .
4: .
5: open MAIL, "| /usr/lib/sendmail -t -F'$from_name'
-f'$from_email'"
6: or die "Could not open sendmail: $!";
7: print MAIL <<END_OF_HEADER;
8: To: $email
9: Reply-to: $from_email
10: Subject: $sub
11: $type_string
12: END_OF_HEADER
13: open(FILE, "< ./reports/$rpt_file.$type")
14: or die "Couldn't open $rpt_file.$type for reading:
$!\n";
15: while (<FILE>) {
16: chomp($_);
17: print MAIL "$_\n";
18: }
19: close(FILE);
20: if($type_string) {
21: print MAIL end_html();
22: }
23: close MAIL or die "Error closing sendmail: $!";
24: print "<li>Sent $sub.</li><br>\n";
25: }

** e.g. "/usr/lib/sendmail -t -F'Daves SplitScanner'
-fmy_scan...@domain.com < tosend.txt"

====================[Resolution]====================

*NOTES:*

This setup is specific to a Solaris 8 host sitting on a private
NAT'ed network, using a DSL connection which gets it's public
IP via DHCP. The solaris machine is *NOT* in the DMZ; I do not
guarantee that any of this is "safe" for a machine that
is exposed to the internet. It *did* work for me in my situation
though.

Part of the problem was getting emails with a "From:" address
other than my primary email address with my ISP to send
properly. That was another issue and I will clearly delineate
where that particular problem was resolved.

uname -a output:
SunOS ultra 5.8 Generic_117350-54 sun4u sparc SUNW,Ultra-5_10

Here are the steps needed to make this work:

1) Removed SUNWsndmr and SUNWsndmu. The reason I pulled these out is
because future Sun patch clusters might overwrite parts of my sendmail
implementation if these packages were present.

2) Download, compile and install per instructions openssl-0.9.8g.
stunnel and SASL will need to be compiled with SSL libs.

3) Download cyrus-sasl-2.1.22 -- this will provide the authentication
functionality that sendmail needs in this case.

4) Configure SASL with: "CFLAGS=-DOPENSSL_DISABLE_OLD_DES_SUPPORT=1
./configure --with-openssl=/usr/local/ssl" to work around the following
error:

In file included from auth_getpwent.c:53:
/usr/include/crypt.h:22: parse error before '(' token
/usr/include/crypt.h:22: parse error before "const"
make[3]: *** [auth_getpwent.o] Error 1

5) Run "make" and "make install" in cyrus SASL source dir

6) Download, gunzip & untar BerkeleyDB.4.2; install per the README. I
added this because I wanted hash database(NEWDB) support; while I don't
think it was strictly necessary for my situation, I wanted BerkeleyDB
for other reasons(not related to sendmail). Without these lines I would
get a db.h error when building sendmail, and when I found that
BerkeleyDB offers one possible solution to this I simply installed it a
bit earlier than I had originally planned. If you decide to skip this,
you should not add the lines that I indicate below in the "hash database
functionality" section of my site.config.m4. You may have to replace
those lines with something more appropriate to your situation, or not --
just know that they are tied in with this step.

7) Download, gunzip & untar sendmail-8.14.2; top level of source dir
later referred to as <smsrc>

8) Create <smsrc>/devtools/Site/site.config.m4 with following
contents(file should not have the indents that I used here for clarity):

# These two lines needed for authentication functionality
#

APPENDDEF(`confENVDEF', `-DSASL=2')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')

# These lines enable hash database functionality
#

APPENDDEF(`confENVDEF', `-DNEWDB')
APPENDDEF(`confLIBDIRS', `-L/usr/local/BerkeleyDB.4.2/lib')
APPENDDEF(`confINCDIRS', `-I/usr/local/BerkeleyDB.4.2/include')

# Without the next line, I was getting the following error in my apache
# error_log, even though at that point relaying from insecure clients
# on another host was working:
#
# ld.so.1: sendmail: fatal: libsasl2.so.2: open failed: No such file
or directory
#

APPENDDEF(`confLIBDIRS', `-R/usr/local/lib')

9) Compile sendmail. The INSTALL file recommends doing this with "sh
./Build" from <smsrc>/sendmail but I recommend you use "sh ./Build -c"
which forces a rebuild of everything. I had to recompile repeatedly as I
experimented with the site.config.m4 file; ./Build did not detect
changes to this file and would exit without doing anything.
Additionally, you will want to install makemap from <smsrc>/makemap.
Verify that the new makemap is getting installed in the right place! run
"ls -l `which makemap`" before and after to verify the file is replaced.

10) Install sendmail; from <smsrc>/sendmail -- run "sh ./Build install".

11) Verify that SASL compiled in properly(SASLv2 in output):

# /usr/lib/sendmail -d0.1 -bt < /dev/null
Version 8.14.2
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS NISPLUS
PIPELINING SASLv2 SCANF STARTTLS USERDB XDEBUG

NOTE: The above may not work until you build and install your
sendmail.cf file, step 15 below.

12) Download, gunzip & untar stunnel-4.24. build and install it per the
instructions. stunnel is needed because sendmail simply does not have
the capability to use the SMTPS version of SSL that was needed in this
particular case.

13) Move /etc/stunnel/stunnel.conf to
/usr/local/etc/stunnel/stunnel.conf (If it's not there, copy from
stunnel-4.24/tools/stunnel.conf) and edit it as follows(my file had all
lines not mentioned below commented out):

---[snip]---
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

debug = 7
output = stunnel.log

client = yes

[rev-smtps]
accept = 127.0.0.1:2525
connect = smtp.att.yahoo.com:465
---[snip]---

NOTE: The "accept" address is the port sendmail will connect to when
trying to send mail -- details in step (15) below. The "connect" address
is the smtp server that I want to send my mail to/through. The idea is
that when sendmail connects to the "accept" address it is completely
unaware that the connection is being tunneled transparently to the
"connect" address with SSL encryption. You can test this as follows:

telnet localhost 2525

This should give you "cleartext connectivity" to smtp.att.yahoo.com,
i.e. you should see the SMTP greeting, be able to type EHLO and get a
response etc. If this doesn't work, you need to debug the stunnel setup.

14) Run "mkdir -p /usr/local/var/run/stunnel" so that stunnel can create
its pidfile,

15) Copy the sendmail and stunnel init scripts to /etc/init.d and set up
the rc links(you may find different numbers are appropriate for your
system; again, this is what worked out for me). Output edited to remove
filenames not relevant to this discussion:

# ls -l /etc/rc2.d
lrwxrwxrwx 1 root other 24 May 21 15:25 S87stunnel ->
/etc/init.d/stunnel.init
lrwxrwxrwx 1 root other 20 May 10 06:51 S88sendmail ->
/etc/init.d/sendmail
# ls -l /etc/rc1.d
lrwxrwxrwx 1 root other 20 May 10 06:53 K36sendmail ->
/etc/init.d/sendmail
lrwxrwxrwx 1 root other 24 May 21 15:25 K37stunnel ->
/etc/init.d/stunnel.init
#

16) Copy <smsrc>/cf/cf/generic-solaris.mc to <smsrc>/cf/cf/sendmail.mc.
Below is the important stuff that I needed in my sendmail.mc. VERY
IMPORTANT -- after removing the Sun packages above, you will not have
mail.local and you don't want the one that comes with sendmail(unless
you do, and you know what you're getting into). To get sendmail to
properly interface with /usr/bin/mail be sure you use the same OSTYPE
that I did below.

divert(0)dnl
VERSIONID(`$Id: sendmail.mc,v 8.13 2008/05/29 11:46:30 Dave Exp $')

OSTYPE(solaris2.pre5)dnl
DOMAIN(generic)dnl

FEATURE(`access_db')dnl
FEATURE(`authinfo')dnl

define(`SMART_HOST', `smarthost-local.localhost')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 2525')dnl
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')dnl

MAILER(local)dnl
MAILER(smtp)dnl

17) Now build and install sendmail.cf and submit.cf:

From <smsrc>/cf/cf:
sh ./Build sendmail.cf
sh ./Build install-cf

18) You will need to tweak /etc/hosts(sendmail resides on ultra):

127.0.0.1 localhost
127.0.0.1 smarthost-local
192.168.1.5 ultra.localhost ultra loghost

NOTE: The .localhost was added to get a proper canonical name; the risk
of using anythng that looks like a real domain name is that someone may
eventually register that name, even if it seems available today(happened
to me...). Again, sendmail provides a mechanism to check this:

# /usr/lib/sendmail -d0.1 -bt < /dev/null

.
.
.
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = ultra
(canonical domain name) $j = ultra.localhost
(subdomain name) $m = localhost
(node name) $k = ultra
========================================================

19) Make sure there is no "domain" line in /etc/resolv.conf

20) Create /etc/mail/access to allow relaying from your subnet:

Connect:192.168.1 RELAY

Now run "makemap hash access < access" from /etc/mail

21) Create /etc/mail/authinfo with an entry to hold your att.yahoo user
ID and password(chmod 400 authinfo for security).

AuthInfo: "I:<user@domain>" "P:<password>" "M:PLAIN"

Now run "makemap hash authinfo < authinfo" from /etc/mail

NOTE: the letter after the first double quote in the line above is an
uppercase 'i', not a lowercase 'L'.

NOTE: Be careful if you have no hostname after "Authinfo:" -- If you
connect to *any* different SMTP server it will send these credentials! I
was not able to get sendmail to authenticate with a hostname here.

22) Copy <smsrc>/sendmail/aliases to /etc/mail. Rebuild the aliases.db
file with

# /usr/lib/sendmail -bi
/etc/mail/aliases: 25 aliases, longest 10 bytes, 279 bytes total
#

23) Put the following two entries in /etc/relay-domains and
/etc/local-host-names:

<hostname>
<hostname>.localhost

So, that's what was needed to get sendmail to work. If you want the gory
details of how this solution was arrived at, it's all in this thread. Enjoy!

Dave Anderson

====================[From: Addr. not primary Addr.]====================

There was much gnashing of teeth and tearing of hair on my part due to
the fact that smtp.att.yahoo.com wants to make sure that when you send
email, the "From:" address is on your list of approved senders. And
sendmail was properly providing an email address that should have been
"approved". And it wasn't working. o_O

It was returning the following error:

13900 >>> >>> MAIL From:<approve...@address.com>
13900 >>> <<< 553 From: address not verified; see
http://help.yahoo.com/l/us/yahoo/mail/original/manage/sendfrom-07.html

If you always use your primary address for "From" you probably won't
have an issue.

If you have a Yahoo ID, you will be able to view that page. Follow the
steps listed on that page, and if it's still acting like your "approved"
sender is not "approved", call support and tell them that you need them
to look at it. When I called, the first-line support person ran me
through the instructions on that page a couple times before escalating
the call to second-line support. This person reset something on their
end, then asked me to delete and re-submit my info to verify(approve)
the secondary email address. After that it worked!

Below are mail logs where my relay successfully relayed from my insecure
clients.

=========================[Mail Logs]===============================

These logs are produced by modifying the line in /etc/init.d/sendmail
that actually launches sendmail to the following; I recommend commenting
the original line and pasting the following line above or below it;
restore the original line when you are finished debugging so you don't
have an ever-expanding log file that you don't need.

/usr/lib/sendmail -bd -X /var/log/mail.log -oL9 &

01978 >>> 220 ultra.localhost ESMTP Sendmail 8.14.2/8.14.2; Mon, 2 Jun
2008 22:31:38 -0700 (PDT)
01978 <<< EHLO localhost
01978 >>> 250-ultra.localhost Hello Flash [192.168.1.8], pleased to meet you
01978 >>> 250-ENHANCEDSTATUSCODES
01978 >>> 250-PIPELINING
01978 >>> 250-EXPN
01978 >>> 250-VERB
01978 >>> 250-8BITMIME
01978 >>> 250-SIZE
01978 >>> 250-DSN
01978 >>> 250-ETRN
01978 >>> 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
01978 >>> 250-DELIVERBY
01978 >>> 250 HELP
01978 <<< MAIL FROM:<primar...@pacbell.net>
01978 >>> 250 2.1.0 <primar...@pacbell.net>... Sender ok
01978 <<< RCPT TO:<my.cel...@email.com>
01978 >>> 250 2.1.5 <my.cel...@email.com>... Recipient ok
01978 <<< RCPT TO:<primar...@pacbell.net>
01978 >>> 250 2.1.5 <primar...@pacbell.net>... Recipient ok
01978 <<< DATA
01978 >>> 354 Enter mail, end with "." on a line by itself
01978 <<< Message-ID: <18930211.1212471097749.JavaMail.SYSTEM@Flash>
01978 <<< Date: Mon, 2 Jun 2008 22:31:37 -0700 (PDT)
01978 <<< From: primar...@pacbell.net
01978 <<< To: my.cel...@email.com
01978 <<< To: primar...@pacbell.net
01978 <<< Subject: Flash : Test email from PowerChute Business Edition
01978 <<< Mime-Version: 1.0
01978 <<< Content-Type: text/plain; charset=us-ascii
01978 <<< Content-Transfer-Encoding: 7bit
01978 <<<
01978 <<<
01978 <<< This email was sent to test your configuration settings
01978 <<<
01978 <<< .
01978 >>> 250 2.0.0 m535VcHe001978 Message accepted for delivery
01978 <<< QUIT
01978 >>> 221 2.0.0 ultra.localhost closing connection
01980 === CONNECT smarthost-local.localhost.
01980 <<< 220 smtp120.sbc.mail.sp1.yahoo.com ESMTP
01980 >>> EHLO ultra.localhost
01980 <<< 250-smtp120.sbc.mail.sp1.yahoo.com
01980 <<< 250-AUTH LOGIN PLAIN XYMCOOKIE
01980 <<< 250-PIPELINING
01980 <<< 250 8BITMIME
01980 >>> AUTH PLAIN ci1u...(edited)...F2Mw==
01980 <<< 235 ok, go ahead (#2.0.0)
01980 >>> MAIL From:<primar...@pacbell.net>
01980 <<< 250 ok
01980 >>> RCPT To:<primar...@pacbell.net>
01980 >>> RCPT To:<my.cel...@email.com>
01980 >>> DATA
01980 <<< 250 ok
01980 <<< 250 ok
01980 <<< 354 go ahead
01980 >>> Received: from localhost (FLASH [192.168.1.8])
01980 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m535VcHe001978;
01980 >>> Mon, 2 Jun 2008 22:31:38 -0700 (PDT)
01980 >>> Message-ID: <18930211.1212471097749.JavaMail.SYSTEM@Flash>
01980 >>> Date: Mon, 2 Jun 2008 22:31:37 -0700 (PDT)
01980 >>> From: primar...@pacbell.net
01980 >>> To: my.cel...@email.com
01980 >>> To: primar...@pacbell.net
01980 >>> Subject: Flash : Test email from PowerChute Business Edition
01980 >>> Mime-Version: 1.0
01980 >>> Content-Type: text/plain; charset=us-ascii
01980 >>> Content-Transfer-Encoding: 7bit
01980 >>>
01980 >>>
01980 >>> This email was sent to test your configuration settings
01980 >>>
01980 >>> .
01980 <<< 250 ok 1212471100 qp 62087
01980 >>> QUIT
01980 <<< 221 smtp120.sbc.mail.sp1.yahoo.com

01982 >>> 220 ultra.localhost ESMTP Sendmail 8.14.2/8.14.2; Mon, 2 Jun
2008 22:32:01 -0700 (PDT)
01982 <<< EHLO Flash
01982 >>> 250-ultra.localhost Hello Flash [192.168.1.8], pleased to meet you
01982 >>> 250-ENHANCEDSTATUSCODES
01982 >>> 250-PIPELINING
01982 >>> 250-EXPN
01982 >>> 250-VERB
01982 >>> 250-8BITMIME
01982 >>> 250-SIZE
01982 >>> 250-DSN
01982 >>> 250-ETRN
01982 >>> 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
01982 >>> 250-DELIVERBY
01982 >>> 250 HELP
01982 <<< MAIL From:<primar...@pacbell.net>
01982 >>> 250 2.1.0 <primar...@pacbell.net>... Sender ok
01982 <<< RCPT To:<my.cel...@email.com>
01982 >>> 250 2.1.5 <my.cel...@email.com>... Recipient ok
01982 <<< RCPT To:<primar...@pacbell.net>
01982 >>> 250 2.1.5 <primar...@pacbell.net>... Recipient ok
01982 <<< DATA
01982 >>> 354 Enter mail, end with "." on a line by itself
01982 <<< Date: Mon, 02 Jun 2008 22:32:00 -0800
01982 <<< From: primar...@pacbell.net
01982 <<< To: my.cel...@email.com,primar...@pacbell.net
01982 <<< Subject: 3ware 3DM2 alert -- host: Flash
01982 <<<
01982 <<< This is a test e-mail generated by 3ware 3DM2
01982 <<<
01982 <<< .
01982 >>> 250 2.0.0 m535W1DS001982 Message accepted for delivery
01982 <<< QUIT
01982 >>> 221 2.0.0 ultra.localhost closing connection
01984 === CONNECT smarthost-local.localhost.
01984 <<< 220 smtp120.sbc.mail.sp1.yahoo.com ESMTP
01984 >>> EHLO ultra.localhost
01984 <<< 250-smtp120.sbc.mail.sp1.yahoo.com
01984 <<< 250-AUTH LOGIN PLAIN XYMCOOKIE
01984 <<< 250-PIPELINING
01984 <<< 250 8BITMIME
01984 >>> AUTH PLAIN ci1u...(edited)...F2Mw==
01984 <<< 235 ok, go ahead (#2.0.0)
01984 >>> MAIL From:<primar...@pacbell.net>
01984 <<< 250 ok
01984 >>> RCPT To:<primar...@pacbell.net>
01984 >>> RCPT To:<my.cel...@email.com>
01984 >>> DATA
01984 <<< 250 ok
01984 <<< 250 ok
01984 <<< 354 go ahead
01984 >>> Received: from Flash (Flash [192.168.1.8])
01984 >>> by ultra.localhost (8.14.2/8.14.2) with ESMTP id
m535W1DS001982;
01984 >>> Mon, 2 Jun 2008 22:32:01 -0700 (PDT)
01984 >>> Message-Id: <200806030532....@ultra.localhost>
01984 >>> Date: Mon, 02 Jun 2008 22:32:00 -0800
01984 >>> From: primar...@pacbell.net
01984 >>> To: my.cel...@email.com, primar...@pacbell.net
01984 >>> Subject: 3ware 3DM2 alert -- host: Flash
01984 >>>
01984 >>> This is a test e-mail generated by 3ware 3DM2
01984 >>>
01984 >>> .
01984 <<< 250 ok 1212471122 qp 62717
01984 >>> QUIT
01984 <<< 221 smtp120.sbc.mail.sp1.yahoo.com