9 Apr
2004
9 Apr
'04
1:48 p.m.
Hi,
I'd like to customize the error message sent back to the sender
when a "unknown user" is encountered.
By default sendmail generates something like this:
From: Mail Delivery Subsystem
<MAILER-DAEMON(a)some.domain.lu>
To: <sender(a)some.other.domain>
Subject: Returned mail: see transcript for details
Date: whatever
The original message was received at <date>
from [a.b.c.d]
----- The following addresses had permanent fatal errors -----
<recipient(a)domain.lu>
(reason: 550 recipient(a)domain.lu... No such user)
----- Transcript of session follows -----
... while talking to [b.c.d.e]:
Final-Recipient: RFC822; recipient(a)domain.lu
Action: failed
Status: 5.1.1
Remote-MTA: DNS; [a.b.c.d]
Diagnostic-Code: SMTP; 550 recipient(a)domain.lu ... No such user
Last-Attempt-Date: sometime
So I'd like to customize the message (especially get rid of IP
addresses so as not to reveal topology information of the
internal network).
Does anyone have an idea on how to go about this? Is there some
config file to edit (vi /etc/mail/sendmail.cf anyone? :-)) or
something?
My googling hasn't been very successful so far...
TIA, Eric
>> DATA
<<< 550
recipient(a)domain.lu... No such user
550 5.1.1 <recipient(a)domain.lu>... User unknown
<<< 503 Issue RCPT TO: command before DATA command 
9 Apr
9 Apr
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
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
3:32 p.m.
begin Friday 09 April 2004 16:56, Eric Dondelinger quote:
On sendmail, you could use a milter to do this. But I'm sure that on
postfix it must be possible to do this as well, after all the SPF guys
must be addressing a similar problem.
[...]
Indeed, this takes some cooperation by the different "institutions"
that are handled by the gate.
[...]
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.
Ooops :-(
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),
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. Again, not doable here - the box where I want to
change this bounce
message is already the second step *after* the external MX:
I see... Is there no possibility of implementing sth at the _real_
border machine?
Of course it all depends on how computer savvy and co-operating the
"institutions" are. If you can convince them to give you a list of
users (with updates, if they add/remove users) a semi-manual solution
might be possible.
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
Alain
7524
days inactive
7524
days old
3 comments
2 participants
participants (2)
-
Alain Knaff -
Eric Dondelinger