On Wed, 19 Nov 2008 23:02:42 -0500, Paul Russell <[log in to unmask]> wrote:

>Technically, this is do-able, but it requires changes to both the LISTSERV
>service configuration, and the mail server configuration on the MX host(s)
>for the rider.edu domain.  The LISTSERV changes are necessary to force
>LISTSERV to use the domain name, rather than the server FQDN, as the domain
>portion of the sender address on outbound messages.  The mail server changes
>are necessary to ensure delivery of inbound messages.

Yes.  This needs to include getting non-delivery reports (bounces) back to
LISTSERV so that bad (non-deliverable) addresses can be removed from lists.
Failure to do this will negatively affect your email sender reputation and that
will impact your ability (or not) to successfully deliver email to the larger
recipient domains such as aol.com, Google (gmail), Microsoft (MSN, Hotmail,
Live), and Yahoo.com among others.

>The MX host(s) must be able to verify that a given recipient address in the
>rider.edu domain is valid, and identify the internal host to which the message
>should be routed for delivery.  Ideally, recipient address verification should
>occur during the SMTP session when a message is presented for delivery, so the
>server can reject messages for invalid recipient addresses during the SMTP
>session, rather than accepting those messages, then generating delivery error
>messages to the apparent, but often forged, sender addresses.

Agreed.  It is far better to reject/not accept invalid emails at the gateway MX
transaction.

>There are at least two ways to achieve this goal.  You can maintain alias
>files and routing tables on the MX host(s), or you can configure the MX host(s)
>to use an LDAP service for recipient address verification and mail routing.
>Implementation details are left as an exercise for the reader.

On Unix platforms, there are 8 email alias addresses associated with each
LISTSERV list.  The Makefile in the install kit includes a utility to easily
create these aliases.  The big problem with an alias or ldap lookup at the MX
transaction is that it will have difficulty validating LISTSERV PROBE style
return-path addresses from some % of error bounces which use this format.  If
you are also using LISTSERV Maestro then 100% of the outgoing emails will use
this kind of bounce address format.  So you need to be prepared to handle this
when it comes back:

List mail:

 <owner-listname*bparker**POP*-EXAMPLE*[log in to unmask]>
  |fix-|-varys--|------varys---------------|-------fixed-------|

Non-list mail (e.g. Maestro mailings):


<owner-nolist-081111A-fn80vz10*bparker**POP*-EXAMPLE*[log in to unmask]>
  |---fixed---|-varys-|-fixed--|------varys---------------|-------fixed------|

  (The 'fn80vz10' will vary by site, but will be a fixed value for your site.)