I've been digging for the past week and haven't been able to find the
right way to get this done.

I have a sendmail relay server that relays inbound mail for my entire
domain. Behind it I have a domino server configured to only accept
mail for fully qualified recipients that match exactly those in the
directory. Thus, when a message is sent to a recipient that's not in
the directory, a NDR is generated. If the reply to address is spoofed,
I spam the poor saps mail server with a NDR that doesn't belong to
them.

So, I'd like to configured sendmail to do the lookup in LDAP to decide
whether or not it'll relay it into my server. I have a few ideas but I
was hoping someone might be able to give me an experienced point of
view.

Thank you in advance for any assistance.

In article <1159563503.733622.104160@i3g2000cwc.googlegroups. com>
k3ithtaylor@gmail.com writes:
>
>So, I'd like to configured sendmail to do the lookup in LDAP to decide
>whether or not it'll relay it into my server. I have a few ideas but I
>was hoping someone might be able to give me an experienced point of
>view.

Check out the section LDAP ROUTING in cf/README.

--Per Hedeland
per@hedeland.org

per@hedeland.org (Per Hedeland) writes:

> In article <1159563503.733622.104160@i3g2000cwc.googlegroups. com>
> k3ithtaylor@gmail.com writes:
>>
>>So, I'd like to configured sendmail to do the lookup in LDAP to decide
>>whether or not it'll relay it into my server. I have a few ideas but I
>>was hoping someone might be able to give me an experienced point of
>>view.
>
> Check out the section LDAP ROUTING in cf/README.

FEATURE(`ldap_routing') description is also available at:
http://www.sendmail.org/m4/ldap_routing.html

I would suggest you for small/medium site to use "ldap dumps" instead of
asking directly internal LDAP server. It allows to "hide maintanace"
[ ;-) ] of internal mail servers.

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl

k3ithtaylor@gmail.com wrote:
> I've been digging for the past week and haven't been able to find the
> right way to get this done.
>
> I have a sendmail relay server that relays inbound mail for my entire
> domain. Behind it I have a domino server configured to only accept
> mail for fully qualified recipients that match exactly those in the
> directory. Thus, when a message is sent to a recipient that's not in
> the directory, a NDR is generated. If the reply to address is spoofed,
> I spam the poor saps mail server with a NDR that doesn't belong to
> them.
>
> So, I'd like to configured sendmail to do the lookup in LDAP to decide
> whether or not it'll relay it into my server. I have a few ideas but I
> was hoping someone might be able to give me an experienced point of
> view.
>
> Thank you in advance for any assistance.
>

If you don't mind paying for *phone-home ware, milter-ahead will do this
rather easily and doesn't require exposing your LDAP data to your
perimeter. http://snertsoft.com. It isn't free but it's cheaper than
spending time setting up and securing LDAP.

*Each time this product is started it sends an email to the author that
includes your IP and some product version information. Some people find
this offensive or annoying, or both.

dp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 01 Oct 2006 08:38:36 -0700, Dennis Peterson wrote:

[snip]

> If you don't mind paying for *phone-home ware, milter-ahead will do this
> rather easily and doesn't require exposing your LDAP data to your
> perimeter. http://snertsoft.com. It isn't free but it's cheaper than
> spending time setting up and securing LDAP.

> *Each time this product is started it sends an email to the author that
> includes your IP and some product version information. Some people find
> this offensive or annoying, or both.

If you don't like those "features", you could use
<http://www.five-ten-sg.com/dnsbl/> which can be configured to do the same
sort of thing.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFH+T2L6j7milTFsERAojQAKCLvIgU78sdVKXQWfnC+N 335NWs7ACgh8+b
ts+65HtfvADguZbLIW5bjjE=
=nHjO
-----END PGP SIGNATURE-----

Carl Byington wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 01 Oct 2006 08:38:36 -0700, Dennis Peterson wrote:
>
> [snip]
>
>> If you don't mind paying for *phone-home ware, milter-ahead will do this
>> rather easily and doesn't require exposing your LDAP data to your
>> perimeter. http://snertsoft.com. It isn't free but it's cheaper than
>> spending time setting up and securing LDAP.
>
>> *Each time this product is started it sends an email to the author that
>> includes your IP and some product version information. Some people find
>> this offensive or annoying, or both.
>
> If you don't like those "features", you could use
> <http://www.five-ten-sg.com/dnsbl/> which can be configured to do the same
> sort of thing.

It isn't obvious from reading the docs (which are spare) that this
product does any caching of forward lookups. I consider that an
essential feature. Multiple servers querying Exchange for the same
addresses 24x7 seems a bit inefficient.

dp

Thank you to all for your responses. I read the ldap routing docs
before posting and missed the point that it can be conf'd to reject
during the lookup if no addressee is found. On the other hand, the
milter you identified seems tailored to do exactly what I asked. Not
sure which way I'll go yet. I'm surprised this isn't a common issue
give the volume of dictionary attacks these days.

Thanks again,
Keith

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 01 Oct 2006 20:54:02 -0700, Dennis Peterson wrote:

> Carl Byington wrote:

>> If you don't like those "features", you could use
>> <http://www.five-ten-sg.com/dnsbl/> which can be configured to do the
>> same sort of thing.

> It isn't obvious from reading the docs (which are spare) that this
> product
> does any caching of forward lookups. I consider that an essential
> feature.
> Multiple servers querying Exchange for the same addresses 24x7 seems a
> bit
> inefficient.

It does not currently cache the results of the lookups, mainly because
that feature was added to allow backup MX servers to have access to the
valid user list, and the assumption was that the backup MX servers would
not see a lot of traffic other than spam that was blocked by the dnsbl
lookups. You are correct, that if this is used on a primary MX that needs
to see the valid user list on an internal system, then all the valid mail
traffic will go thru this path, so we need to cache the lookups.

I will add that to the to-do list, but the positive and negative cache
TTL values probably need to be configurable as well. Do you have a
suggestion
for default values for those TTLs?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFITHKL6j7milTFsERApYcAJ42iUZkeKHr4CVNAHiAGD qzXpO8RQCfYho3
CWapIj6jRMJm1LrGTGBcNLs=
=Ia/+
-----END PGP SIGNATURE-----

In article <1159800388.305995.298320@i42g2000cwa.googlegroups .com>
k3ithtaylor@gmail.com writes:
>Thank you to all for your responses. I read the ldap routing docs
>before posting and missed the point that it can be conf'd to reject
>during the lookup if no addressee is found. On the other hand, the
>milter you identified seems tailored to do exactly what I asked. Not
>sure which way I'll go yet. I'm surprised this isn't a common issue
>give the volume of dictionary attacks these days.

What makes you think it isn't a common issue? It is frequently brought
up here, most of the time just eliciting a "see the group archives"
response since it has been hashed over so many times and there is quite
a variety of solutions, all with their trade-offs depending on the
user's environment which is rarely fully specified. In your case you
seemed to already have to decided on the method to use, which
simplified the answer (and still you got answers beyond what you asked
for:-).

--Per Hedeland
per@hedeland.org

In article <pan.2006.10.02.15.36.49.568374@five-ten-sg.com> Carl
Byington <carl@five-ten-sg.com> writes:
>
>On Sun, 01 Oct 2006 20:54:02 -0700, Dennis Peterson wrote:
>
>> Carl Byington wrote:
>
>>> If you don't like those "features", you could use
>>> <http://www.five-ten-sg.com/dnsbl/> which can be configured to do the
>>> same sort of thing.
>
>> It isn't obvious from reading the docs (which are spare) that this
>> product
>> does any caching of forward lookups. I consider that an essential
>> feature.
>> Multiple servers querying Exchange for the same addresses 24x7 seems a
>> bit
>> inefficient.
>
>It does not currently cache the results of the lookups, mainly because
>that feature was added to allow backup MX servers to have access to the
>valid user list

Hm? As has been pointed out before here, a backup MX server is the one
place where "SMTP-ahead" (I assume this is what is being discussed) is
less than ideal (understatement:-) - the point of having a backup MX (if
any) is that it should accept mail when the primary MX is down, and then
"SMTP-ahead" will not work...

--Per Hedeland
per@hedeland.org

I guess what I'd really like to do is set up sendmail to relay only for
real addresses AND aliases that exist on inside mail server. I'd like
to script it to query LDAP, parse and strip(if necessary) the
extraneous info and update a file on the sendmail box a couple times a
day. Sendmail (/etc/mail/access?). I have done my homework and
searched archives. Maybe just haven't asked the right questions yet.

Much appreciate all the info.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 02 Oct 2006 22:06:53 +0000, Per Hedeland wrote:

> Hm? As has been pointed out before here, a backup MX server is the one
> place where "SMTP-ahead" (I assume this is what is being discussed) is
> less than ideal (understatement:-) - the point of having a backup MX (if
> any) is that it should accept mail when the primary MX is down, and then
> "SMTP-ahead" will not work...

There are good arguments for NOT having any backup MX machines, but if,
for whatever reason, you have a backup MX machine(s), then they should
have some mechanism of knowing the actual valid users. LDAP is one nice
mechanism, but if, for whatever reason, you don't or can't use LDAP, then
something like smtp-ahead is useful. It also has one advantage over LDAP,
in that if the primary machine will, for policy reasons, claim 'no such
user' for some senders but not for other senders, then smtp-ahead can
properly give that same answer on the backup MX, where with LDAP, the
backup MX only knows that the target user is valid.

Of course, when the primary MX is not reachable from the backup MX, then
my implementation of smtp-ahead simply accepts the mail on the backup
machine. This is similar to the problem of the LDAP server not being
reachable from the backup MX. In that case, presumably you want to either
accept the mail for later relay, or temp-fail it with a 4xx error code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFId0lL6j7milTFsERArLPAJ4huXelbC4Rys5YDXmckt vTGTvCnACdEphV
9OWKQ/45j5Snu979f1SDpZw=
=eicX
-----END PGP SIGNATURE-----

In article <pan.2006.10.03.03.46.59.168457@five-ten-sg.com> Carl
Byington <carl@five-ten-sg.com> writes:
>
>On Mon, 02 Oct 2006 22:06:53 +0000, Per Hedeland wrote:
>
>> Hm? As has been pointed out before here, a backup MX server is the one
>> place where "SMTP-ahead" (I assume this is what is being discussed) is
>> less than ideal (understatement:-) - the point of having a backup MX (if
>> any) is that it should accept mail when the primary MX is down, and then
>> "SMTP-ahead" will not work...

[snip]

>Of course, when the primary MX is not reachable from the backup MX, then
>my implementation of smtp-ahead simply accepts the mail on the backup
>machine.

I.e. like I said, the task that a backup MX is supposed to do is
fundamentally incompatible with SMTP-ahead, and you have to choose one
or the other when that task needs to be performed. You choose the
backup-MX job and effectively turn off SMTP-ahead at that point, which
is probably reasonable - but it begs the question of what the point of
adding SMTP-ahead functionality *specificially for use on a backup MX*
is.

> This is similar to the problem of the LDAP server not being
>reachable from the backup MX. In that case, presumably you want to either
>accept the mail for later relay, or temp-fail it with a 4xx error code.

The big difference is that the backup MX is called into service
*because* the primary MX is not providing SMTP service, i.e. it's
essentially guaranteed that SMTP-ahead won't work. Temp-failing the mail
when recipient validity can't be established, which is the right thing
to do for backscatter prevention, in this scenario means that the backup
MX simply isn't one - when the primary MX SMTP is down, mail will be
queued on the sending systems just like it would if no backup MX
existed.

LDAP on the other hand may or may not be available when the primary MX
isn't providing SMTP service, but it wouldn't be unreasonable for a
backup MX configured to use LDAP for recipient verification to temp-fail
mail when LDAP is unavailable - even if the SMTP and LDAP outages
coincide, the *cause* of the backup temp-failing the mail isn't the
*same* one that brought it into service in the first place.

--Per Hedeland
per@hedeland.org

Carl Byington wrote:

> It does not currently cache the results of the lookups,

and I don't think it should.

Caching positive results doesn't buy you much unless your back-end
server is very heavily loaded or the network between the front-end and
back-end server is slow or has high latency.

Caching negative lookups means your cache will balloon ridiculously at
the first dictionary attack.

Regards,

David.

David F. Skoll wrote:
> Dennis Peterson wrote:
>
>> It does not currently cache the results of the lookups,
>
> and I don't think it should.

One pragmatic benefit is it allows one to do critical maintenance on
interior systems without losing functionality. It also provides a bit of
immunity to AD congestion and network problems. I would estimate the
benefits go up as your enterprise grows larger. It becomes equivalent to
having a local copy of the active user list on the perimeter systems.
It's easy to implement, even in Perl. If it is user configurable you
please everyone.

dp

ugh. I think my thread's been hijacked. Does anyone have a
recommendation or a link to execute what I described above?

- k3ith

ugh. I think my thread's been hijacked. Does anyone have a
recommendation or a link to execute what I described above?

- k3ith

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 03 Oct 2006 20:10:09 +0000, Per Hedeland wrote:

>>Of course, when the primary MX is not reachable from the backup MX, then
>>my implementation of smtp-ahead simply accepts the mail on the backup
>>machine.

> I.e. like I said, the task that a backup MX is supposed to do is
> fundamentally incompatible with SMTP-ahead, and you have to choose one or
> the other when that task needs to be performed. You choose the backup-MX
> job and effectively turn off SMTP-ahead at that point, which is probably
> reasonable - but it begs the question of what the point of adding
> SMTP-ahead functionality *specificially for use on a backup MX* is.

The point is that for the other 99.x% of the time, when both the main and
backup mail server(s) are up and have connectivity, the backup mail server
will see an endless stream of almost pure spam, typically with forged
'envelope from' values. If the backup mail server accepts that mail, which
is then rejected by the primary for 'no such user', then the backup will
spew backscatter spam. ***That must be avoided***. Therefore, smtp-ahead
(or other better mechanisms including ldap) should be used as part of
avoiding spewing backscatter spam from your backup mx. Even with
smtp-ahead or ldap, you will spew such backscatter spam from the backup mx
machine when (smtp-ahead, the primary mx is down or not reachable) (ldap,
the ldap server is down or not reachable).

If we maintain a user-name cache on the backup mx, and have a positive TTL
on the cache on the order of days, then we could know most of the user
list and use that during times when the primary is down. However, I don't
think the error rate would be acceptable, since we would be rejecting mail
to names that we have not seen *at the backup mx* in the last few days.
There is no point in having a negative TTL on the cache larger than a few
minutes, since the common dictionary attacks against the backup mx will
cause excessive memory usage. I therefore think that there is no point in
having a user name cache on the backup mx.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFIy0yL6j7milTFsERAjgfAKCFt3dPJoJVB07xju7byA 2/bY9wlQCfWOpu
cpK4IgwXR5j2J7dZiKOzrg8=
=8MZt
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 03 Oct 2006 20:10:09 +0000, Per Hedeland wrote:

>>Of course, when the primary MX is not reachable from the backup MX, then
>>my implementation of smtp-ahead simply accepts the mail on the backup
>>machine.

> I.e. like I said, the task that a backup MX is supposed to do is
> fundamentally incompatible with SMTP-ahead, and you have to choose one or
> the other when that task needs to be performed. You choose the backup-MX
> job and effectively turn off SMTP-ahead at that point, which is probably
> reasonable - but it begs the question of what the point of adding
> SMTP-ahead functionality *specificially for use on a backup MX* is.

The point is that for the other 99.x% of the time, when both the main and
backup mail server(s) are up and have connectivity, the backup mail server
will see an endless stream of almost pure spam, typically with forged
'envelope from' values. If the backup mail server accepts that mail, which
is then rejected by the primary for 'no such user', then the backup will
spew backscatter spam. ***That must be avoided***. Therefore, smtp-ahead
(or other better mechanisms including ldap) should be used as part of
avoiding spewing backscatter spam from your backup mx. Even with
smtp-ahead or ldap, you will spew such backscatter spam from the backup mx
machine when (smtp-ahead, the primary mx is down or not reachable) (ldap,
the ldap server is down or not reachable).

If we maintain a user-name cache on the backup mx, and have a positive TTL
on the cache on the order of days, then we could know most of the user
list and use that during times when the primary is down. However, I don't
think the error rate would be acceptable, since we would be rejecting mail
to names that we have not seen *at the backup mx* in the last few days.
There is no point in having a negative TTL on the cache larger than a few
minutes, since the common dictionary attacks against the backup mx will
cause excessive memory usage. I therefore think that there is no point in
having a user name cache on the backup mx.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFIy0yL6j7milTFsERAjgfAKCFt3dPJoJVB07xju7byA 2/bY9wlQCfWOpu
cpK4IgwXR5j2J7dZiKOzrg8=
=8MZt
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 03 Oct 2006 19:49:55 -0700, k3ithtaylor wrote:

> ugh. I think my thread's been hijacked. Does anyone have a
> recommendation or a link to execute what I described above?

man ldapsearch

That can do arbitrary queries, so you just need to know your schema, and
the attribute names that contain the email user name. A bit of
'awk/sed/grep' should mash it into a format acceptable to write to
/etc/mail/access, followed by (cd /etc/mail; make) or the equivalent on
your system to rebuild the access hash map.

If you want to use smtp-ahead style, rather than ldap, then
<http://www.five-ten-sg.com/dnsbl/> can do that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFIy61L6j7milTFsERAv6uAJwMmXdIiJZq+W0CfgOoJD fLyLnG9gCcDU1G
UX45szX6a3GyjBI21/0YfYg=
=t4Jk
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 03 Oct 2006 19:49:55 -0700, k3ithtaylor wrote:

> ugh. I think my thread's been hijacked. Does anyone have a
> recommendation or a link to execute what I described above?

man ldapsearch

That can do arbitrary queries, so you just need to know your schema, and
the attribute names that contain the email user name. A bit of
'awk/sed/grep' should mash it into a format acceptable to write to
/etc/mail/access, followed by (cd /etc/mail; make) or the equivalent on
your system to rebuild the access hash map.

If you want to use smtp-ahead style, rather than ldap, then
<http://www.five-ten-sg.com/dnsbl/> can do that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFIy61L6j7milTFsERAv6uAJwMmXdIiJZq+W0CfgOoJD fLyLnG9gCcDU1G
UX45szX6a3GyjBI21/0YfYg=
=t4Jk
-----END PGP SIGNATURE-----

Dennis Peterson wrote:

>>> It does not currently cache the results of the lookups,

[David S.]
>> and I don't think it should.

[Dennis P.]
> One pragmatic benefit is it allows one to do critical maintenance on
> interior systems without losing functionality. It also provides a bit of
> immunity to AD congestion and network problems.

But that is better achieved by actually having a local copy of the
active user list on perimeter systems. With caching, you don't know
for sure whether or not a particular user will be known to the
perimeter system, so you can't flat-out reject mail to an unknown user
if the interior system is down.

Regards,

David.

In article <pan.2006.10.04.03.40.51.285555@five-ten-sg.com> Carl
Byington <carl@five-ten-sg.com> writes:
>
>On Tue, 03 Oct 2006 20:10:09 +0000, Per Hedeland wrote:
>
>>>Of course, when the primary MX is not reachable from the backup MX, then
>>>my implementation of smtp-ahead simply accepts the mail on the backup
>>>machine.
>
>> I.e. like I said, the task that a backup MX is supposed to do is
>> fundamentally incompatible with SMTP-ahead, and you have to choose one or
>> the other when that task needs to be performed. You choose the backup-MX
>> job and effectively turn off SMTP-ahead at that point, which is probably
>> reasonable - but it begs the question of what the point of adding
>> SMTP-ahead functionality *specificially for use on a backup MX* is.
>
>The point is that for the other 99.x% of the time, when both the main and
>backup mail server(s) are up and have connectivity, the backup mail server
>will see an endless stream of almost pure spam, typically with forged
>'envelope from' values. If the backup mail server accepts that mail, which
>is then rejected by the primary for 'no such user', then the backup will
>spew backscatter spam. ***That must be avoided***.

This is all well-known of course, it has been discussed at length here
and elsewhere many times - responsible running of a backup MX today
requires that it has the same policies as the primary for rejecting
mail.

My point, which I'm rather surprised at having such a hard time getting
through, is just that when it comes to implementing invalid-recipient
rejection on the backup, SMTP-ahead is the absolutely worst choice that
you can make - it is essentially useless *in that scenario*, since it
can't work when it is most needed. Which is why I was surprised to learn
that you had implemented it *specifically* for backup-MX usage (it's
perfectly fine for front-end-gateway usage of course).

If your backup MX does something harmful (accepting mail for invalid
recipients, which will be backscattered when the primary comes up
again), or isn't useful (temp-failing all mail for the primary), during
the 1-.x% of the time when it's supposed to do backup-MX work, it's
continued existence can't really be motivated by the fact that it
doesn't do anything harmful during the other 99.x% of the time.

I.e. you should either get rid of it or have a recipient-validation
mechanism that at least has a possibility of working when the primary is
down - in the latter case you can temp-fail mail if/when the mechanism
isn't available.

> Therefore, smtp-ahead
>(or other better mechanisms including ldap) should be used as part of
>avoiding spewing backscatter spam from your backup mx. Even with
>smtp-ahead or ldap, you will spew such backscatter spam from the backup mx
>machine when (smtp-ahead, the primary mx is down or not reachable) (ldap,
>the ldap server is down or not reachable).

Only if you don't temp-fail mail when the mechanism isn't available. You
*should* temp-fail it in that case, but it becomes silly to do so if
you're a backup MX and the mechanism is SMTP-ahead to the primary.

>If we maintain a user-name cache on the backup mx, and have a positive TTL
>on the cache on the order of days, then we could know most of the user
>list and use that during times when the primary is down.

I have not argued for caching, and I can't really see the motivation (at
least for SMTP-ahead) for it, even besides the arguments against it that
you and David bring up. If a network-based mechanism isn't feasible for
whatever reason, the way to go is to periodically and/or on demand push
the user list to the backup/gateway, to allow for local verification.

--Per Hedeland
per@hedeland.org

In article <pan.2006.10.04.03.40.51.285555@five-ten-sg.com> Carl
Byington <carl@five-ten-sg.com> writes:
>
>On Tue, 03 Oct 2006 20:10:09 +0000, Per Hedeland wrote:
>
>>>Of course, when the primary MX is not reachable from the backup MX, then
>>>my implementation of smtp-ahead simply accepts the mail on the backup
>>>machine.
>
>> I.e. like I said, the task that a backup MX is supposed to do is
>> fundamentally incompatible with SMTP-ahead, and you have to choose one or
>> the other when that task needs to be performed. You choose the backup-MX
>> job and effectively turn off SMTP-ahead at that point, which is probably
>> reasonable - but it begs the question of what the point of adding
>> SMTP-ahead functionality *specificially for use on a backup MX* is.
>
>The point is that for the other 99.x% of the time, when both the main and
>backup mail server(s) are up and have connectivity, the backup mail server
>will see an endless stream of almost pure spam, typically with forged
>'envelope from' values. If the backup mail server accepts that mail, which
>is then rejected by the primary for 'no such user', then the backup will
>spew backscatter spam. ***That must be avoided***.

This is all well-known of course, it has been discussed at length here
and elsewhere many times - responsible running of a backup MX today
requires that it has the same policies as the primary for rejecting
mail.

My point, which I'm rather surprised at having such a hard time getting
through, is just that when it comes to implementing invalid-recipient
rejection on the backup, SMTP-ahead is the absolutely worst choice that
you can make - it is essentially useless *in that scenario*, since it
can't work when it is most needed. Which is why I was surprised to learn
that you had implemented it *specifically* for backup-MX usage (it's
perfectly fine for front-end-gateway usage of course).

If your backup MX does something harmful (accepting mail for invalid
recipients, which will be backscattered when the primary comes up
again), or isn't useful (temp-failing all mail for the primary), during
the 1-.x% of the time when it's supposed to do backup-MX work, it's
continued existence can't really be motivated by the fact that it
doesn't do anything harmful during the other 99.x% of the time.

I.e. you should either get rid of it or have a recipient-validation
mechanism that at least has a possibility of working when the primary is
down - in the latter case you can temp-fail mail if/when the mechanism
isn't available.

> Therefore, smtp-ahead
>(or other better mechanisms including ldap) should be used as part of
>avoiding spewing backscatter spam from your backup mx. Even with
>smtp-ahead or ldap, you will spew such backscatter spam from the backup mx
>machine when (smtp-ahead, the primary mx is down or not reachable) (ldap,
>the ldap server is down or not reachable).

Only if you don't temp-fail mail when the mechanism isn't available. You
*should* temp-fail it in that case, but it becomes silly to do so if
you're a backup MX and the mechanism is SMTP-ahead to the primary.

>If we maintain a user-name cache on the backup mx, and have a positive TTL
>on the cache on the order of days, then we could know most of the user
>list and use that during times when the primary is down.

I have not argued for caching, and I can't really see the motivation (at
least for SMTP-ahead) for it, even besides the arguments against it that
you and David bring up. If a network-based mechanism isn't feasible for
whatever reason, the way to go is to periodically and/or on demand push
the user list to the backup/gateway, to allow for local verification.

--Per Hedeland
per@hedeland.org

David F. Skoll wrote:
> Dennis Peterson wrote:
>
>>>> It does not currently cache the results of the lookups,
>
> [David S.]
>>> and I don't think it should.
>
> [Dennis P.]
>> One pragmatic benefit is it allows one to do critical maintenance on
>> interior systems without losing functionality. It also provides a bit of
>> immunity to AD congestion and network problems.
>
> But that is better achieved by actually having a local copy of the
> active user list on perimeter systems. With caching, you don't know
> for sure whether or not a particular user will be known to the
> perimeter system, so you can't flat-out reject mail to an unknown user
> if the interior system is down.
>
> Regards,
>
> David.

The default is to accept messages when there is a failure but because
there are two Exchange bridgeheads on a BigIP queue this is an unlikely
problem. I actually got such a user list a few days ago - two years
after I asked for it. Chances are it's already outdated as mail lists
become. The theory is it is static but only in the sense it won't grow.
The dynamic lists are still not on the radar and there's little interest
in a manual or scripted process to keep such an exported list current. I
don't know jack about Windows so don't know what the challenges are.
Sometimes problems are political and not technical. They certainly make
look-ahead a worth while tool. Otherwise, I agree with you. My first
choice was to set up LDAP via a proxy but the cost and time to harden
and make it all redundant/reliable could not be justified.

dp