##
##  Copyright (c) 2001 The OSSP Project <http://www.ossp.org/>
##  Copyright (c) 2001 Cable & Wireless Deutschland <http://www.cw.com/de/>
##
##  This file is part of OSSP lmtp2nntp, an LMTP speaking local
##  mailer which forwards mails as Usenet news articles via NNTP.
##  It can be found at http://www.ossp.org/pkg/lmtp2nntp/.
##
##  This program is free software; you can redistribute it and/or
##  modify it under the terms of the GNU General Public  License
##  as published by the Free Software Foundation; either version
##  2.0 of the License, or (at your option) any later version.
##
##  This program is distributed in the hope that it will be useful,
##  but WITHOUT ANY WARRANTY; without even the implied warranty of
##  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
##  General Public License for more details.
##
##  You should have received a copy of the GNU General Public License
##  along with this file; if not, write to the Free Software
##  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
##  USA, or contact the OSSP project <ossp@ossp.org>.
##
##  lmtp2nntp.pod: LMTP to NNTP (manual page)
##

=pod

=head1 NAME

B<OSSP lmtp2nntp> - mail to news gateway

=head1 SYNOPSIS

B<lmtp2nntp>
[B<-C> I<childsmax>]
[B<-D>]
[B<-K>]
[B<-P> I<pidfile>]
[B<-V>]
[B<-a> I<addr>/I<mask>[,I<addr>/I<mask>[,...]]
[B<-b> I<addr>[I<:port>]|C<->|I<path>[:perms]]
[B<-c> I<addr>[I<:port>]]
[B<-d> I<addr>[I<:port>][,I<addr>[I<:port>], ...]]
[B<-g> I<groupmode>]
[B<-h> I<header>:<value>]
[B<-l> I<level>[:I<logfile>]]
[B<-m> I<mailfrom>]
[B<-n> I<nodename>]
[B<-o> I<operationmode>]
[B<-r> I<restrictheader>]
[B<-s> I<size>]
[B<-t> I<name>=I<sec>[,I<name>=I<sec>[,...]]
[B<-u> I<uid>]
[B<-v>]
I<newsgroup> [I<newsgroup> ...]

=head1 DESCRIPTION

The B<OSSP lmtp2nntp> program is an LMTP service for use in conjunction
with an MTA (like Sendmail), providing a reliable real-time mail to news
gateway. Input messages get their headers slightly reformatted to match
Usenet news article format. The article is then posted or feeded into
a remote NNTP service (like INN). Delivery must take place immediately
or the transaction fails. B<OSSP lmtp2nntp> relies on the queuing
capabilities of the MTA in order to provide a fully reliable service.
For this the program returns proper delivery status notification which
indicates successful completed action, persistent transient failure or
permanent failure.

The following command line options and arguments are available:

=over 4

=item B<-h> I<header>:<value>

Header with value to to be inserted into message before delivery.  This option
can be specified more than once.  Useful for specifiying an moderator Email
address to all outgoing news messages by applying an "Approved:" header.

=item B<-C> I<childsmax>

Childs the daemon spawns at maximum. Default is 10.

=item B<-D>

Daemonize program and detach from current terminal.

=item B<-K>

Kill the daemon. After processing this option the program is terminated so
this option effectivly renders most other options invalid not including
specification of a pidfile and logging. The pid must be listed in pidfile.

=item B<-P> I<pidfile>

Pidfile to remember the process ID when running as or killing the daemon. Care
must be taken when using relative path names as daemonizing changes the
current working directory to '/'.

=item B<-V>

Very verbose logging. This means logging is unbuffered.

=item B<-a> I<addr>/I<mask>[,I<addr>/I<mask>[,...]] (LMTP daemon ACL)

Access control list specifying TCP INET addresses and masks where incoming
LMTP connections are accepted from. This option can be specified more than
once and it is possible to specify more than one addr/ mask per option as a
comma-separated list. Omitting a mask defaults to a host comparison. The mask
is a CIDR style bitmask where /0 means no comparison and enforces a match.
Omitting the wholly option defaults to 0.0.0.0/0 which allows access from
everywhere.  It is possible to specify both inclusive and exclusive addresses,
the latter have to prefixed with an exclamation mark. In order to pass the ACL
a client must match any inclusion and not match any exclusion. If you do not
specify any inclusions a fake inclusion of 0.0.0.0/0 is appended internally.
Any addr can be a name to be resolved first.

=item B<-b> I<addr>[I<:port>]|C<->|I<path[:perms]> (LMTP daemon bind)

Bind address accepting incoming LMTP connections. Supported are "C<->" for
stdio, I<path>[:perms] for Unix Domain socket with optional chmod-like
permissions and I<addr>[I<:port>] for TCP INET socket. Omitting this option
defaults to stdio. The path for a UNIX domain socket must start with a slash.
The addr can be a name to be resolved first.

=item B<-c> I<addr>[I<:port>] (NNTP client bind)

Client connections for outgoing NNTP communication bind to this address. If an
address is specified but port is omitted the kernel chooses an ephemeral port.
If you want to specify a port but no address replace address with all zeroes.
If completely omitted, 0.0.0.0:0 is assumed which causes the kernel to choose
an address based on routing information and an ephemeral port.  The addr can
be a name to be resolved first.

=item B<-d> I<addr>[I<:port>][,I<addr>[I<:port>], ...] (NNTP client peer)

Destination hostname or address and optional TCP port of a NNTP service.
Unless a port is specified, getserbyname(nntp) is queried with fallback to
119/tcp. If C<-d> option is ommited, the environment variable C<NNTPSERVER> is
read, if this is undefined or empty C<news> is used and if this doesn't
resolve, C<localhost> is assumed.  This option can be specified more than once
and it is possible to specify more than one host/ port per option as a
comma-separated list.  Any addr can be a name to be resolved first.  It is
assumed that multiple servers are used to increase the reliability of the news
system and to speed up distribution by posting the same article to more than
one server.  In regard to this program they must provide the same groups and
talk to each other. 

=item B<-g> I<groupmode>

Possible values for I<groupmode> are C<arg> (default), C<envelope> and
C<header>. In C<arg> mode, the C<newsgroup>s specified as command line
arguments are ultimate destinations for the received messages.  Addresses from
envelope and headers are ignored.  In C<envelope> mode the newsgroup(s) are
taken from the LMTP envelope, in C<header> mode the newsgroup(s) are taken
from the header.  In all modes C<Newsgroups:> header is rewritten. In
C<envelope> and C<header> mode groups must still be specified as command line
arguments. However, in these modes the command line arguments are filters
representing allowed groups. Filters can be specified as wildmat's.

=item B<-l> I<level>[:I<logfile>]

The level measures the degree and importance of output and can be any of
PANIC, CRITICAL, ERROR, WARNING, NOTICE, INFO, TRACE or DEBUG. The recommended
level for daily operations is NOTICE. The default name for logfile is
"logfile".  This program is using the logging library (l2) which is currently
under development. An early access snapshot with limited functionality has
been included.  Currently the common denominator of usage between lmtp2nntp
and l2 is to use logging into a file only. Note that this will change soon as
during integration of l2 into lmtp2nntp logging channels for local syslog and
a SMTP client were already finished and IRC and NNTP clients are under
development.

=item B<-m> I<mailfrom>

"MAIL From:" filter to limit sender addresses. If ommitted, anyone can send
mail. The value to be compared includes the angle brackets. Use a PCRE (Perl
compatible reguar expression) for I<mailfrom>.

=item B<-n> I<nodename>

Own FQDN used in LMTP and NNTP protocols. This overrides the nodename returned
by uname(3).

=item B<-o> I<operationmode>

Possible values for I<operationmode> are C<post>, C<feed> or a string in
"LLL/D.D.D" format used to fake a LMTP return code.  In C<post> mode articles
are sent to the NNTP server(s) using POST command. Before posting, a duplicate
check using STAT command is issued. In C<feed> mode articles are sent to the
NNTP server(s) using IHAVE command.  Specifying a return code and DSN replaces
the post/ feed logic by a noop and assumes the given string must be returned
to the LMTP side.  The slash is replaced by a space internally. The default is
"553/5.7.1" meaning "Requested action not taken: mailbox name not allowed/
Delivery not authorized, message refused".  This is useful for debugging LMTP
setups without engaging NNTP.  Fake mode makes it possible to run without any
B<-d> option. However, if B<-d> option is given the NNTP client tries to
connect but it's return codes are ignored.

=item B<-r> I<restrictheader>

Restricted headers. Messages with a matching restrictheader are rejected.  If
ommitted no restrictions apply. Matching is done before -h headers are
appended. Use a PCRE (Perl compatible reguar expression) for
I<restrictheader>.

=item B<-s> I<size>

Size limitation on message in bytes. Default is 8388608 (8M). Values below 64
are considered unacceptable small.

=item B<-t> I<name>=I<sec>[,I<name>=I<sec>[,...]

Timeout for various actions. Possible names are C<lmtp> for any LMTP and
C<nntp> for any NNTP actions. More granular actions can be specified according
to the following table, which also lists the system defaults.  Setting sec to
zero means to wait infinite. Note that LMTP timeouts only apply to socket
operations, stdio always waits infinite.

    lmtp:accept  = 0
    lmtp:read    = 10
    lmtp:write   = 10
    nntp:connect = 360
    nntp:read    = 60
    nntp:write   = 60

=item B<-u> I<uid>

UID or login name to resolve to a UID to be set for program execution.

=item B<-v>

Print version information.

=item I<newsgroup> [I<newsgroup> ...]

Newsgroup to post the message to or filter, depending on groupmode.  Multiple
groups can be specified.  Crosspostings succeed if delivery to I<any> group
succeeds.

=back

=head1 SIGNALS

Sending a USR1 signal to the program will flush the logging stream.

=head1 DIAGNOSTICS

If invoked it returns 0 on successful execution (not neccessarily
meaning successful delivery!) or 1 on failed execution. Returning proper
delivery status notification is part of the LMTP protocol.

=head1 STANDARDS

=over 4

=item RFC0821

Simple Mail Transfer Protocol.  J. Postel. Aug-01-1982. (Format: TXT=124482
bytes) (Obsoletes RFC0788 ) (Obsoleted by RFC2821) (Also STD0010) (Status:
STANDARD )

=item RFC0822

Standard for the format of ARPA Internet text messages.  D. Crocker.
Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733) (Obsoleted by
RFC2822) (Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also
STD0011) (Status: STANDARD)

=item RFC0977

Network News Transfer Protocol.  B. Kantor, P. Lapsley. Feb-01-1986. (Format:
TXT=55062 bytes) (Status: PROPOSED STANDARD)

=item RFC1035

Domain names - implementation and specification.  P.V. Mockapetris.
Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883)
(Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996,
RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845) (Also STD0013)
(Status: STANDARD)

=item RFC1652

SMTP Service Extension for 8bit-MIMEtransport.  J. Klensin, N. Freed, M. Rose,
E. Stefferud, D. Crocker. July 1994.  (Format: TXT=11842 bytes) (Obsoletes
RFC1426) (Status: DRAFT STANDARD)

=item RFC1854

SMTP Service Extension for Command Pipelining.  N. Freed. October 1995.
(Format: TXT=14097 bytes) (Obsoleted by RFC2197) (Status: PROPOSED STANDARD)

=item RFC1893

Enhanced Mail System Status Codes.  G. Vaudreuil. January 1996. (Format:
TXT=28218 bytes) (Status: PROPOSED STANDARD)

=item RFC1894

An Extensible Message Format for Delivery Status Notifications.  K. Moore, G.
Vaudreuil. January 1996. (Format: TXT=77462 bytes) (Updated by RFC2852)
(Status: PROPOSED STANDARD)

=item RFC2034

SMTP Service Extension for Returning Enhanced Error Codes.  N. Freed. October
1996. (Format: TXT=10460 bytes) (Status: PROPOSED STANDARD)

=item RFC2606

Reserved Top Level DNS Names.  D. Eastlake, A. Panitz. June 1999. (Format:
TXT=8008 bytes) (Also BCP0032) (Status: BEST CURRENT PRACTICE)

=item RFC2821

Simple Mail Transfer Protocol.  J. Klensin, Editor. April 2001.  (Format:
TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) (Status: PROPOSED
STANDARD)

=item RFC2980

Common NNTP Extensions.  S. Barber. October 2000. (Format: TXT=57165 bytes)
(Status: INFORMATIONAL)

=back

=cut

