From: John E. Hein on
"jmaimon(a)ttec.com" <jmaimon(a)ttec.com> writes:
> Do you want recipient checks or do you want to actually send the whole
> message downstream before reporting 250 after the smtp DATA phase?
>
> The former is the common problem.

I would be interested in hearing about a solution to hold an email
until the full email was checked downstream (in case, for instance,
the downstream server used something like spamass-milter with a
rejection threshold). But I could see how that could get
problematic in terms of processing time.

To answer your question, I would be happy at this point with a
solution that did full envelope checks on the downstream server before
accepting the mail on my server. It may not be just the recipient
that the downstream server rejects (the envelope could contain a
sending domain that the next server considers invalid whereas my
server might not for whatever reason).

That would prevent most of the MAILER-DAEMON bounces I see.
From: John E. Hein on
"jmaimon(a)ttec.com" <jmaimon(a)ttec.com> writes:
> "How do I let my mx gateway server recognize which recipients are
> valid
> on the final destionation/next hop server and which are not?"
>
> Which has hit the newsgroup so frequently it really needs to be a faq
> entry.
>
> The short answers are:
>
> *
>
> Use ldap routing
>
> see cf/README
>
> +--------------+
> | LDAP ROUTING |
> -++--------------+
>
> http://www.sendmail.org/m4/ldap_routing.html

This doesn't help me.
That would still involve accepting a mail and relaying to the
downstream host which might then reject it causing bounce
messages from MAILER-DAEMON on my server.


> *
>
> Use virtusertable with undocumented feature and an entry for each
> valid user and a catchall entry that @domain.com error:nouser
>
> _VIRTUSER_STOP_ONE_LEVEL_RECURSION_

I'm pretty sure this feature does not address my problem either.

from proto.m4 ...
dnl this is not a documented option
dnl it stops looping in virtusertable mapping if input and output
dnl are identical, i.e., if address A is mapped to A.
dnl it does not deal with multi-level recursion

> *
>
> Use virtusertable with a RHS of "!" for each valid user and a
> catchall entry that @domain.com error:nouser

Same issues. Unknown user downstream is not really a problem
in my case. It may happen on occasion when a downstream
server (not under my control) deletes an account or one of
my users supplies an erroneous forwarding account. But
I don't have a problem with seeing bounces from those.
It's the bounces that aren't really errors that are the
problems (e.g., slightly different envelope rejection criteria
on the downstream server).


> *
>
> Use access db with undocumented feature
>
> define(`_RELAY_FULL_ADDR_', `1')
>
> And put all your users in there
>
> To:u...(a)example.com RELAY
>

Doesn't help me either.


> *
> use a milter of which there are several.
>
> milter-ahead
> j-chkmail
> mimedefang
> dnsbl
> callahead-milter
> milter-sav
>
> A list of milters is available at
> http://www.jmaimon.com/sendmail/milters

Some of those (not mimedefang, not dnsbl, as far as I can see) may do
the trick. I'll check them out. Thanks.
From: Dennis Peterson on
John E. Hein wrote:
> "jmaimon(a)ttec.com" <jmaimon(a)ttec.com> writes:
>> Do you want recipient checks or do you want to actually send the whole
>> message downstream before reporting 250 after the smtp DATA phase?
>>
>> The former is the common problem.
>
> I would be interested in hearing about a solution to hold an email
> until the full email was checked downstream (in case, for instance,
> the downstream server used something like spamass-milter with a
> rejection threshold). But I could see how that could get
> problematic in terms of processing time.
>
> To answer your question, I would be happy at this point with a
> solution that did full envelope checks on the downstream server before
> accepting the mail on my server. It may not be just the recipient
> that the downstream server rejects (the envelope could contain a
> sending domain that the next server considers invalid whereas my
> server might not for whatever reason).
>
> That would prevent most of the MAILER-DAEMON bounces I see.

You heard it - sendmail does not provide this. It is an MTA, first and
last, has some basic rules you can use, but it quickly becomes
cumbersome. You extend it with milters. A milter that does exactly what
you want is milter-ahead. Your other choice is to maintain a list in the
virtusertable or access_db on the gateway system of all the valid
addresses it is expected to relay for and rejects the rest and I assure
you that can be a lot of work. Using LDAP/Active Directory is an option
but not a light weight one.

At least in the case of milter-ahead it caches the results of what it
finds which reduces the call-ahead retry traffic. Milter-ahead looks at
your mailertable to determine which domains to call ahead to, so it
doesn't get bogged down trying pre-contacting every domain you relay for.

dp
From: jmaimon on
On Jan 30, 11:35 pm, j...(a)gromit.timing.com (John E. Hein) wrote:
> "jmai...(a)ttec.com" <jmai...(a)ttec.com> writes:
> > Do you want recipient checks or do you want to actually send the whole
> > message downstream before reporting 250 after the smtp DATA phase?
>
> > The former is the common problem.
>
> I would be interested in hearing about a solution to hold an email
> until the full email was checked downstream (in case, for instance,
> the downstream server used something like spamass-milter with a
> rejection threshold). But I could see how that could get
> problematic in terms of processing time.
>
> To answer your question, I would be happy at this point with a
> solution that did full envelope checks on the downstream server before
> accepting the mail on my server. It may not be just the recipient
> that the downstream server rejects (the envelope could contain a
> sending domain that the next server considers invalid whereas my
> server might not for whatever reason).
>
> That would prevent most of the MAILER-DAEMON bounces I see.


Some of the milters on the list support rcpt checking and sender
checking both on the recipient servers and on the purported sender's
server.


From: David F. Skoll on
John E. Hein wrote:

> Some of those (not mimedefang, not dnsbl, as far as I can see) may do
> the trick.

Of course MIMEDefang will do the trick. It has a function specifically
for this purpose.

--
David.