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.)