alias forwarding: stop DSN backscatter?
Tony Nelson
8.11.6. (Only until I can move it to CentOS 4.4.) It's been a spam
relay for years, as it had RELAY_LOCAL_FROM enabled until recently. It
still gets lots of spam attempts.
All the mail sent TO it is forwarded via aliases to other places. AOL,
at least, notices most of the spam and DSN 5.0.0's it. Sendmail then
sends DSN backscatter to the victim's From: address. This will still be
an issue when the server is moved to CentOS.
I would like to stop this. One way might be to have mail be deemed
"received" regardless of whether it was then forwarded successfully.
Can I do this with sendmail? Or can I do this with procmail doing the
forwarding?
Another way might be with the SnertSoft milter-ahead, if I understood
milters (or if the sendmail provided them)? That is, could milter-ahead
do the forward during the initial smtp transaction so the DSN would go
to the actual message sender, or does milter-ahead only do MX lookups?
I tried to disable DSNs by: added noreceipts to PRIVACY_FLAGS, ran m4
("noreceipt" made it into /etc/sendmail.cf), and ran "service sendmail
restart", but I still see DSNs in the log. Does noreceipt only disable
DSN /during/ the initial SMTP transaction, but not after? Or is the
sendmail too old, or does noreceipts do something else?
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>
jma...@ttec.com
<*firstname*nlsnews@georgea*lastname*.com> wrote:
> I'm starting to maintain an old, horked server running RH 7.2, sendmail
> 8.11.6. (Only until I can move it to CentOS 4.4.) It's been a spam
> relay for years, as it had RELAY_LOCAL_FROM enabled until recently. It
> still gets lots of spam attempts.
>
> All the mail sent TO it is forwarded via aliases to other places. AOL,
> at least, notices most of the spam and DSN 5.0.0's it. Sendmail then
> sends DSN backscatter to the victim's From: address. This will still be
> an issue when the server is moved to CentOS.
>
> I would like to stop this. One way might be to have mail be deemed
> "received" regardless of whether it was then forwarded successfully.
> Can I do this with sendmail? Or can I do this with procmail doing the
> forwarding?
>
This is known as discarding, which is better then nothing
> Another way might be with the SnertSoft milter-ahead, if I understood
> milters
You probably dont. Milters are program sendmail communicates with as
it receives a message.
The snertsoft milter verifies that recipients are valid by contacting
the deduced destination server and pretending to try to email to the
recipient. Its called smtp call-ahead verification.
> (or if the sendmail provided them)? That is, could milter-ahead
> do the forward during the initial smtp transaction so the DSN would go
> to the actual message sender, or does milter-ahead only do MX lookups?
What this accomplishes is that invalid recipients are rejected right
away and no DSN's need to be sent at all.
>
> I tried to disable DSNs by: added noreceipts to PRIVACY_FLAGS, ran m4
> ("noreceipt" made it into /etc/sendmail.cf), and ran "service sendmail
> restart", but I still see DSNs in the log. Does noreceipt only disable
> DSN /during/ the initial SMTP transaction, but not after? Or is the
> sendmail too old, or does noreceipts do something else?
something else. It disables the sending of receipts in response to a
message's request to receive a receipt upon successfull delivery to
the server.
> ________________________________________________________________________
> TonyN.:' *firstname*nlsnews@georgea*lastname*.com
> ' <http://www.georgeanelson.com/>
There is many more than one way to skin this cat, in lieu of a
published FAQ entry , here is my oft posted list.
----------
"How do I let my mx gateway server recognize which recipients are
valid
on the final destionation/next hop server and which are not?"
Which has hit the newsgroup so frequently it really needs to be a faq
entry.
The short answers are:
*
Use ldap routing
see cf/README section titled LDAP ROUTING
http://www.sendmail.org/m4/ldap_routing.html
(LDAP routing doesnt actually require LDAP, it will work with
predumped and precompiled maps, perhaps created by cron job)
*
Use virtusertable with undocumented feature and an entry for each
valid user and a catchall entry that @domain.com error:nouser
_VIRTUSER_STOP_ONE_LEVEL_RECURSION_
*
Use virtusertable with a RHS of "!" for each valid user and a
catchall entry that @domain.com error:nouser
*
Use access db with undocumented feature (pre sendmail 8.14.0)
define(`_RELAY_FULL_ADDR_', `1')
And put all your users in there
To:u...@example.com RELAY
Ensure that all other relaying is denied for that domain.
*
Use access db with documented feature "relaytofulladdress" (post
sendmail 8.14.0)
FEATURE(`access_db', `hash -T<TMPF> /etc/mail/
access_map',`relaytofulladdress')
And put all your users in there
To:u...@example.com RELAY
Ensure that all other relaying is denied for that domain.
*
use a milter of which there are several.
milter-ahead
j-chkmail
mimedefang
dnsbl
callahead-milter
milter-sav
A list of milters is available at
http://www.jmaimon.com/sendmail/milters
Tony Nelson
"jma...@ttec.com" <jma...@ttec.com> wrote:
> On Mar 27, 1:53 pm, Tony Nelson
> <*firstname*nlsnews@georgea*lastname*.com> wrote:
> > I'm starting to maintain an old, horked server running RH 7.2, sendmail
> > 8.11.6. (Only until I can move it to CentOS 4.4.) It's been a spam
> > relay for years, as it had RELAY_LOCAL_FROM enabled until recently. It
> > still gets lots of spam attempts.
> >
> > All the mail sent TO it is forwarded via aliases to other places. AOL,
> > at least, notices most of the spam and DSN 5.0.0's it. Sendmail then
> > sends DSN backscatter to the victim's From: address. This will still be
> > an issue when the server is moved to CentOS.
> >
> > I would like to stop this. One way might be to have mail be deemed
> > "received" regardless of whether it was then forwarded successfully.
> > Can I do this with sendmail? Or can I do this with procmail doing the
> > forwarding?
> >
>
> This is known as discarding, which is better then nothing.
OK. What setting in sendmail will do that?
> > Another way might be with the SnertSoft milter-ahead, if I understood
> > milters
>
> You probably dont. Milters are program sendmail communicates with as
> it receives a message.
Yes, exactly.
> The snertsoft milter verifies that recipients are valid by contacting
> the deduced destination server and pretending to try to email to the
> recipient. Its called smtp call-ahead verification.
Is there a milter that doesn't just pretend to send the mail, but
actually sends it? Then it could return the delivery status in the
original smtp transaction, solving my problem.
> > (or if the sendmail provided them)? That is, could milter-ahead
> > do the forward during the initial smtp transaction so the DSN would go
> > to the actual message sender, or does milter-ahead only do MX lookups?
>
> What this accomplishes is that invalid recipients are rejected right
> away and no DSN's need to be sent at all.
Perhaps I'm not using the term properly. I thought DSN referred to
either a separate email or to the status returned in an SMTP transaction.
> > I tried to disable DSNs by: added noreceipts to PRIVACY_FLAGS, ran m4
> > ("noreceipt" made it into /etc/sendmail.cf), and ran "service sendmail
> > restart", but I still see DSNs in the log. Does noreceipt only disable
> > DSN /during/ the initial SMTP transaction, but not after? Or is the
> > sendmail too old, or does noreceipts do something else?
>
> something else. It disables the sending of receipts in response to a
> message's request to receive a receipt upon successfull delivery to
> the server.
OK. Is there a sendmail setting to disable DSNs?
> There is many more than one way to skin this cat, in lieu of a
> published FAQ entry , here is my oft posted list.
>
> ----------
> "How do I let my mx gateway server recognize which recipients are
> valid on the final destionation/next hop server and which are not?"
...
This is not relevent. All the recipients in question are valid, which
is why they have entries in /etc/aliases. I need to prevent sendmail
sending backscatter from mail forwarded for valid addresses.
Carl Byington
Hash: SHA1
On Tue, 27 Mar 2007 20:34:43 +0000, Tony Nelson wrote:
[snip]
> This is not relevent. All the recipients in question are valid, which is
> why they have entries in /etc/aliases. I need to prevent sendmail
> sending
> backscatter from mail forwarded for valid addresses.
If the spam filtering on the (backup mx / original mail target) is weaker
than the spam filtering on the final destination, then yes, you will have
a backscatter problem. You can use mailertable entries on your machine to
get normal forwarded messages to the right destination, with an extra .
entry to smarthost everything else (including the DSN backscatter) to
another mail server that exists only to reject all mail from <>, but will
deliver all other mail.
Then your machine 1 receives mail, tries to forward to (eg) aol, gets
rejected, makes a bounce message, tries to smarthost that out thru your
machine 2, which rejects it. Now machine 1 may try to double bounce to
the local postmaster, but you can kill that with sendmail config.
I think this is ugly, but I have no better solution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGCYsVL6j7milTFsERAq+pAJ9g7qZWEZ2XL7xogYsS2Mb2CJbDVgCeNEdO
VcEXuIG2tXr4HiGfkZzrfrc=
=CyuM
-----END PGP SIGNATURE-----
Tony Nelson
Carl Byington <ca...@five-ten-sg.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 27 Mar 2007 20:34:43 +0000, Tony Nelson wrote:
>
> [snip]
>
> > This is not relevent. All the recipients in question are valid, which is
> > why they have entries in /etc/aliases. I need to prevent sendmail
> > sending
> > backscatter from mail forwarded for valid addresses.
>
> If the spam filtering on the (backup mx / original mail target) is weaker
> than the spam filtering on the final destination, then yes, you will have
> a backscatter problem. You can use mailertable entries on your machine to
> get normal forwarded messages to the right destination, with an extra .
> entry to smarthost everything else (including the DSN backscatter) to
> another mail server that exists only to reject all mail from <>, but will
> deliver all other mail.
>
> Then your machine 1 receives mail, tries to forward to (eg) aol, gets
> rejected, makes a bounce message, tries to smarthost that out thru your
> machine 2, which rejects it. Now machine 1 may try to double bounce to
> the local postmaster, but you can kill that with sendmail config.
>
> I think this is ugly, but I have no better solution.
Ugly and convoluted.
I just want to get sendmail to stop making these things. How do I tell
sendmail not to make a DSN message?
Carl Byington
Hash: SHA1
On Tue, 27 Mar 2007 22:42:48 +0000, Tony Nelson wrote:
[snip]
>> I think this is ugly, but I have no better solution.
> Ugly and convoluted.
> I just want to get sendmail to stop making these things. How do I
> tell
> sendmail not to make a DSN message?
This patch might do something - it has not been tested.
diff --recursive sendmail-8.13.1/sendmail/savemail.c
sendmail-8.13.1.new/sendmail/savemail.c
79a80,81
> return panic; // we don't want to return any messages at all
>
The idea is to simply avoid generating *any* dsn message - but this may
have other side effects. Test at your own risk.
Very early in savemail(e, sendbody), we just return.
Of course, if that works the way that I think it might, then such a
sendmail won't ever report failed deliveries. So if that mail server is
used by normal customers, and they typo an address, they won't get a
bounce.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGCbHqL6j7milTFsERAnwzAJwJaLVpfUI8axT+UbfN7mB671+BhgCeICrw
mMYSlT7KhGCTOvLY7kudEYs=
=jo/i
-----END PGP SIGNATURE-----
jma...@ttec.com
Along that line here is a patch already developed in response to a
well prior thread
Tony Nelson
"jma...@ttec.com" <jma...@ttec.com> wrote:
Thanks.
Tony Nelson
Carl Byington <ca...@five-ten-sg.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Tue, 27 Mar 2007 22:42:48 +0000, Tony Nelson wrote:
>
> [snip]
> >> I think this is ugly, but I have no better solution.
>
> > Ugly and convoluted.
>
> > I just want to get sendmail to stop making these things. How do I
> > tell
> > sendmail not to make a DSN message?
>
> This patch might do something - it has not been tested.
>
> diff --recursive sendmail-8.13.1/sendmail/savemail.c
> sendmail-8.13.1.new/sendmail/savemail.c
> 79a80,81
> > return panic; // we don't want to return any messages at all
> >
>
> The idea is to simply avoid generating *any* dsn message - but this may
> have other side effects. Test at your own risk.
>
> Very early in savemail(e, sendbody), we just return.
>
> Of course, if that works the way that I think it might, then such a
> sendmail won't ever report failed deliveries. So if that mail server is
> used by normal customers, and they typo an address, they won't get a
> bounce.
AFAICT, savemail() is only used to generate fresh email messages, and
has nothing to do with reporting during the SMTP transaction, so your
sort of patch would fix sendmail's absurd pro-spammer behavior. Better
might be to figure out if the address is local, but I'm not quite there
yet.
It does appear that sendmail deliberately helps spammers, by overriding
any configuration that would prevent backscatter spam if alias
forwarding is used. Probably it's just the mindset of the developers,
that spam is icky and sendmail should not compromise its operations in
order to prevent spam.
Sadly, as the server that is doing the spamming is horked, I won't be
able to do any compiling on it. When it is replaced with a new server,
I'll just try to move away from sendmail, to some other less
spam-friendly MTA.
jma...@ttec.com
<*firstname*nlsnews@georgea*lastname*.com> wrote:
> In article <pan.2007.03.28.00.08.37.96...@five-ten-sg.com>,
> Carl Byington <c...@five-ten-sg.com> wrote:
>
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
>
> > On Tue, 27 Mar 2007 22:42:48 +0000, Tony Nelson wrote:
>
> > [snip]
> > >> I think this is ugly, but I have no better solution.
>
> > > Ugly and convoluted.
>
> > > I just want to get sendmail to stop making these things. How do I
> > > tell
> > > sendmail not to make a DSN message?
>
> > This patch might do something - it has not been tested.
>
> > diff --recursive sendmail-8.13.1/sendmail/savemail.c
> > sendmail-8.13.1.new/sendmail/savemail.c
> > 79a80,81
> > > return panic; // we don't want to return any messages at all
>
> > The idea is to simply avoid generating *any* dsn message - but this may
> > have other side effects. Test at your own risk.
>
> > Very early in savemail(e, sendbody), we just return.
>
> > Of course, if that works the way that I think it might, then such a
> > sendmail won't ever report failed deliveries. So if that mail server is
> > used by normal customers, and they typo an address, they won't get a
> > bounce.
The idea with the patch I posted would be that delivery would be made
to an external intelligent agent which would do something intelligent.
>
> AFAICT, savemail() is only used to generate fresh email messages, and
> has nothing to do with reporting during the SMTP transaction, so your
> sort of patch would fix sendmail's absurd pro-spammer behavior
I prefer that sendmail not cater to absurd setups by breaking
standards compliance (without it we would all be screwed) and silently
dropping mail, thank you very much.
You should work to increase the chances of successfull delivery as the
message travels further into your network, not vice versa. Your
strongest security checks should always start at the *perimeter*.