Hi,

Does anyone know if / how you can make Sendmail redirect DSN messages
to either:

a) Use a seperate queue group all of their own.
b) To a nominated address, and not be returned back to the user.

Or is there some way / mechanism we can either modify, or replace the
'error' mailer that sendmail uses?

Thanks,

Jon

JonB wrote:
> Hi,
>
> Does anyone know if / how you can make Sendmail redirect DSN messages
> to either:
>
> a) Use a seperate queue group all of their own.
> b) To a nominated address, and not be returned back to the user.
>
> Or is there some way / mechanism we can either modify, or replace the
> 'error' mailer that sendmail uses?
>
> Thanks,
>
> Jon

You need to be more forthcoming about what the problem is. Are you
accepting messages for non-existant mailboxes, and then sending DSNs to
the (usually) forged from addresses? If so, the answer is to stop
accepting those messages, and reject them during SMTP command phase.
Milter-ahead might you do that, or you might find a way to get a
valid user list to the exposed MTA, or you could accept mail directly
on the MTA that has access to the valid user list.

If the actual situation is different from that, I apologize for jumping
to conclusions.

Daniel Feenberg
feenberg isat nber dotte org

drfremove@nber.org wrote:
> JonB wrote:
> > Hi,
> >
> > Does anyone know if / how you can make Sendmail redirect DSN messages
> > to either:
> >
> > a) Use a seperate queue group all of their own.
> > b) To a nominated address, and not be returned back to the user.
> >
> > Or is there some way / mechanism we can either modify, or replace the
> > 'error' mailer that sendmail uses?
> >
> > Thanks,
> >
> > Jon
>
> You need to be more forthcoming about what the problem is. Are you
> accepting messages for non-existant mailboxes, and then sending DSNs to
> the (usually) forged from addresses?

Hi, no, we're not doing that

The system in question is a mail hub / 'smart host' for a number of
other systems. We know all the people using it - but we get a steady
stream of DSN's on it. More annoyingly, some of the smaller departments
using it as a mail hub, don't appear then accept DSN's back [yeah,
whole can of worms time ]

So we'd be interested in not sending any DSN's out - and instead having
our own software process them. That way we'll get a better handle on
whats goign on, and by whom - and make appropriate action / education
trips

We already have a quick 'pass through' milter on the system that
provides stats and bandwidth usage / management reports, we'd like to
do similar for the DSN's - but obviously, a milter won't do it [at
least so far as I'm aware].

Having the 'error' mailer just pipe to a unix socket, or program would
be ideal - or just getting sendmail to dump them in a queue that's
never delivered, so we can pick them up out of it would work (infact,
that'd almost be better as we could always 'release' them then if we
know the other side do support DSN).

Jon

JonB wrote:
> drfremove@nber.org wrote:
> > JonB wrote:
> > > Hi,
> > >
> > > Does anyone know if / how you can make Sendmail redirect DSN messages
> > > to either:
> > >
> > > a) Use a seperate queue group all of their own.
> > > b) To a nominated address, and not be returned back to the user.
> > >
> > > Or is there some way / mechanism we can either modify, or replace the
> > > 'error' mailer that sendmail uses?
> > >
> > > Thanks,
> > >
> > > Jon
> >
> > You need to be more forthcoming about what the problem is. Are you
> > accepting messages for non-existant mailboxes, and then sending DSNs to
> > the (usually) forged from addresses?
>
> Hi, no, we're not doing that
>
> The system in question is a mail hub / 'smart host' for a number of
> other systems. We know all the people using it - but we get a steady
> stream of DSN's on it. More annoyingly, some of the smaller departments
> using it as a mail hub, don't appear then accept DSN's back [yeah,
> whole can of worms time ]
>
> So we'd be interested in not sending any DSN's out - and instead having
> our own software process them. That way we'll get a better handle on
> whats goign on, and by whom - and make appropriate action / education
> trips
>
> We already have a quick 'pass through' milter on the system that
> provides stats and bandwidth usage / management reports, we'd like to
> do similar for the DSN's - but obviously, a milter won't do it [at
> least so far as I'm aware].
>
> Having the 'error' mailer just pipe to a unix socket, or program would
> be ideal - or just getting sendmail to dump them in a queue that's
> never delivered, so we can pick them up out of it would work (infact,
> that'd almost be better as we could always 'release' them then if we
> know the other side do support DSN).
>
> Jon

Sorry for jumping to conclusions. Some of what you want would come from
using the double_bounce_address configuration option described at

http://www.sendmail.org/m4/tweaking_config.html .

I don't know enough to catch all bounces.


Daniel Feenberg
feenberg isat nber dotte org

drfremove@nber.org wrote:
> JonB wrote:
> > drfremove@nber.org wrote:
> > > JonB wrote:
> > > >
> Sorry for jumping to conclusions. Some of what you want would come from
> using the double_bounce_address configuration option described at
>
> http://www.sendmail.org/m4/tweaking_config.html .
>
> I don't know enough to catch all bounces.
>

Well until the right answer presents itself, you might want to try
this.

http://www.jmaimon.com/sendmail/#SingleBounceAddr

The bounce address goes through ruleset rewriting, the only trick is to
know when the address being rewritten is a bounce address. Gotta be a
macro somewhere.

>
> Daniel Feenberg
> feenberg isat nber dotte org

jmaimon@ttec.com wrote:

> Well until the right answer presents itself, you might want to try
> this.
>
> http://www.jmaimon.com/sendmail/#SingleBounceAddr
>
> The bounce address goes through ruleset rewriting, the only trick is to
> know when the address being rewritten is a bounce address. Gotta be a
> macro somewhere.

Thanks, that looks like it might be workable... I just have to ensure
now that the thing processing the bounces gets enough info 'in the
bounce' to be able to work out the original offender, and to totall up
their stats

Too early to tell if that's going to be the easy bit yet or not <g>

Thanks for the replies,

-Jon

JonB wrote:
> jmaimon@ttec.com wrote:
>
> > Well until the right answer presents itself, you might want to try
> > this.
> >
> > http://www.jmaimon.com/sendmail/#SingleBounceAddr
> >
> > The bounce address goes through ruleset rewriting, the only trick is to
> > know when the address being rewritten is a bounce address. Gotta be a
> > macro somewhere.
>
> Thanks, that looks like it might be workable... I just have to ensure
> now that the thing processing the bounces gets enough info 'in the
> bounce' to be able to work out the original offender, and to totall up
> their stats
>

Return-Path: header should do the trick.

> Too early to tell if that's going to be the easy bit yet or not <g>
>
> Thanks for the replies,
>
> -Jon

jmaimon@ttec.com wrote:
> drfremove@nber.org wrote:
> > JonB wrote:
> > > drfremove@nber.org wrote:
> > > > JonB wrote:
> > > > >
> > Sorry for jumping to conclusions. Some of what you want would come from
> > using the double_bounce_address configuration option described at
> >
> > http://www.sendmail.org/m4/tweaking_config.html .
> >
> > I don't know enough to catch all bounces.
> >
>
> Well until the right answer presents itself, you might want to try
> this.
>
> http://www.jmaimon.com/sendmail/#SingleBounceAddr
>
> The bounce address goes through ruleset rewriting, the only trick is to
> know when the address being rewritten is a bounce address. Gotta be a
> macro somewhere.
>

This may possible work as an alternative, from the sendmail doc/op

UseErrorsTo
[l] If there is an "Errors-To:" header, send
error messages to the addresses listed
there. They normally go to the envelope
sender. Use of this option causes sendmail
to violate RFC 1123. This option is
disrecommended and deprecated.