9 Apr
2004
9 Apr
'04
2:56 p.m.
Hi Alain,
On Fri, 9 Apr 2004, Alain Knaff wrote:
begin Friday 09 April 2004 15:48, Eric Dondelinger
quote:
Well, that would be fine for spams, but unfortunate for
"normal" misspelled recipients.
(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).
For this, the gate would have to know all users on the internal
network - this is totally impractical in this case, as the gate
here handles mail for a number of different institutions, each
with their own mailservers maintained by themselves with their
own mailboxes. The gate here is relay, and relay only.
Additional advantage: you avoid unwittingly
"bounce-spamming" people
if some virus forges a From and sends to a non-existant users on your
system.
That is an advantage for sure. We might think about adding AV
checks on the external MX (if mail obviously viral, then generate a
5xx message, for which the AV scan would have to be done while the
connection is still going - this on postfix), but that'd take a hell
of a lot of time to get the know-how and put things in place properly,
along with proper respect for the legal situation and privacy etc. etc.
(an ISP may only filter with explicit authorization of the end-users
AFAIK - P&T solves this by having the clients pay for such services).
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"
Looks interesting, but doable only if you know every single user
behind the gate.
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.
erm... is this "access" file here not some kind of user db, too?
Sure, it's not your /etc/passwd or LDAP database, but still...
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.
Again, not doable here - the box where I want to change this bounce
message is already the second step *after* the external MX:
external machine / sender -> MX in DMZ -> firewall w/ mail proxy
-> internal relay -> recipient mail server
Only the external MX in the DMZ could directly talk to the sender,
but it has no way of checking the existance of the end recipient.
So, it's still the bounce message I'd have to change AFAICS...
Greets & thanks for your input,
Eric