>A note that might be useful for new users of 8.12:
>sendmail 8.12.x and the "double delivery" (first to a local queue,
>then to a listener on port 25) means that it's hard to "watch"
>deliveries by hand.  "date| Mail -v nobody@example.com" will show
>an SMTP connection to localhost.

and, so that the logs don't get too confusing, the sendmail daemon and
the client queue runner run with -Lsm-mta and -Lsm-msp-queue (these
are set in the default *_flags values in /etc/defaults/rc.conf) so
that you can differentiate between local submission, queue runner
activities, and smtp daemon activity.

>Sendmail is no longer setuid, so sendmail invoked from the command
>line as a user cannot write to the mqueue directory any longer.
>This is good.
>
>date | sendmail -v -Am nobody@example.com
>will force it to use the connection directly.  As root. 

you mean "this will only work if you are root".

>One of the bigger 8.12 advantages is queue groups:
>You can have a queue or group of queues set for mail to, say,
>inbound vs. outbound or mail to a partner can go into a special
>set of queues.  Mail FROM certain addresses can be put in queues.
>Hell, write the right rules and you can have queue groups by hour
>of day.
>
>These queue groups can have things like queue runners waiting
>and running continuously (useful where inbound should ALWAYS be
>up and waiting where outbound mail should get the usual "run a queue
>runner every 30 or 60 minutes behavior).  You can nice down queue
>runners, etc, etc.  Basically it's easier to tune up sendmail
>to get the max performance and throughput.

well...i wasn't going to go into all the new features, there's also a
BadRcptThrottle (throttles back responses on connections requesting a
lot of recipients that are bad to slow down the spammers), and a nice
new "enhanced dns bl" feature that you that allows you to much more
finely control what information you use (and how you use it) from a
dnsbl lookup.

>Additionally, there are several variables introduces and exposed
>to the cf rules and you can now enforce that connections to/from
>certain domains are using TLS.  This is useful if you want to
>be SURE that when you send to "partner.com" or a remote office
>of yours that you have TLS running.  Or when using SMTP-AUTH :)
>
>(remote offices actually do better with IPSec as a longer living
>connection rather than beating the machines with short SSL sessions).

true, very true...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."