However I'm thinking it will mean that ISPs mail queues will get much 
larger as mail delivery failures etc will now queue for retry rather than 
being failed as a permanent error.. if you're an ISP with lots of 
customers who get infected with the latest spamming worm that means you!

Steve

On Wed, 17 Sep 2003, Stewart, William C (Bill), RTSLS wrote:

> Avleen Vig suggests that it's very wrong for Verisign's bad-domain catcher to
> begin to accept SMTP messages and just reject all recipients with 550s
> rather than rejecting the whole transaction with a 554.
> I'm glad I'm not the only one who thinks that -
> is there some conceivable case for which this system _would_ accept a message,
> e.g. [EMAIL PROTECTED] ?
>  
> On the other hand, it has very interesting implications for spam handling.
> While there are bad side effects that can be caused by Verisign's claim that
> any non-existent domain name now exists (since it's harder to reject that mail),
> the Internet now has one obvious happy destination for spam from harvested addresses.
> If your spider bait starts leaving around [EMAIL PROTECTED] ... [EMAIL PROTECTED]
> and thousands of similar addresses, the harvesters are going to start catching them
> and sending them spam, and the less intelligent harvesters aren't going to validate 
> the domains
> against Verisign's IP address, and any badly administered machines with open smtp 
> relays
> are certainly not going to be checking for it, so they'll be creating SMTP sessions 
> with Verisign.
>  
> It's even more fun with dictionary attacks, where the spammer targets [EMAIL 
> PROTECTED]
> through [EMAIL PROTECTED] - A DNS rejection would cause a direct attacker
> or (more likely) a relay attacker to give up quickly, and a 554 might do that also,
> while rejecting all 26**8 recipients one at a time is probably just the kind of 
> behaviour 
> that spamware is happy to talk to all day.   Now all Verisign needs to add is a 
> teergrube function
> to generate its responses very slowly after the first couple of them and they'll 
> stay tied up for months,
> especially since many of them won't notice that bogusdomain1.com through 
> bogusdomain32767.com
> are all going to the same IP address, since that's not uncommon virtual hosting 
> behaviour.
>  
>                            bill.stewart at pobox.com 
>  
>  
>  
>  
>  
> 

Reply via email to