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