9 Apr
2004
9 Apr
'04
2:18 p.m.
begin Friday 09 April 2004 15:48, Eric Dondelinger quote:
(especially get rid of IP
addresses so as not to reveal topology information of the
internal network).
The best way to avoid giving away internal network topology in a
bounce message is to avoid sending a bounce message in the first
place ;-)
Instead, reject mails at the gate, and leave the responsibility of
generating a bounce to the system that submitted to you (... which
can't reveal any internal topology, because it doesn't know about it).
Additional advantage: you avoid unwittingly "bounce-spamming" people
if some virus forges a From and sends to a non-existant users on your
system.
Here is what we do on lll.lgl.lu to solve a similar issue. We put the
following into access:
To:User1.Name@linux.lu RELAY
To:User2.Name@linux.lu RELAY
...
To:linux.lu ERROR:"430 Mail to linux.lu delayed due to heavy joe-jobbing.
Pl
ease try again later"
Result: the server does only accept the explicitly listed (existing)
users and gives an error message for all the others... and this even
though it is not the server that has the user db.
In our case, we use a 430 (because we want the submitting system to
try the primary MX in case of problems, just in case the list gets out
of sync); but in your case you could use a 550 (submitting system
generates bounce).
On the spf list (spf-discuss(a)v2.listbox.com) there are people who
achieve the same goal by having the gateway system "forward-probe" the
final destination to verify the existance of the user before accepting
the message.
Alain