SMTP, and bounces. (was Re: [unisog] DNS over TCP should we block

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Fri Jan 7 22:18:06 GMT 2005


On Fri, 07 Jan 2005 14:09:10 EST, Jim Young said:

> There is a multiplier effect here that could be as high as 
> 1 to 20.  In most cases it appears that these events are
> usually triggered when a mail-server attempts to resolve 
> some host.   (Adding insult to injury this lookup is generally 
> for creating a "return-to-sender" message). 

Of course.  They can't even be bothered to get information about
their *own* domain right, you expect them to get things like
userids on *your* site correct? ;)

(Might not be their fault - it *could* be a joe-job spam.  This is
why bouncing undeliverables is becoming less and less useful.  If your
site can manage it, it is *FAR* better if you can give the source
site a '551 User Unknown' right at the inbound SMTP server, at RCPT TO:
time.  That way, (a) you don't get a bounce in your queue, and (b) it's
now the sending machine's problem, not yours. You do this enough, and
maybe the the sending site will notice *they* now have a clogged queue,
and they should do something about their spamming-zombie PC problem. ;)

Unfortunately, this *does* require that your inbound SMTP servers
have access to a list of current valid mailboxes, so they can do the
rejections in real time....

> Because the site below was apparently "black-holing" 
> our TCP53 requests, on December 2nd we reluctantly 
> put in place acls on our border routers to REJECT 
> outbound TCP53 request to the to two name servers 
> for the domain outstandinginternet.com:

How ironic. ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20050107/03c9f675/attachment-0002.bin


More information about the unisog mailing list