[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 email reflector



Well, I would agree, but there are issues. The receiver often cannot make that determination without having first received the email, in order to check its DKIM signature or apply content heuristics. It is possible to null route identified bots at the network layer, to reject their sending attempt by RST'ing the TCP connection that it opens, or to do the equivalent with their SMTP connection, but only before the email has been transferred. The only information that can be done on is the unverified email address of the sender (in SMTP) or the IP address of the device sending it. That's not a lot of information.

What Ironport and other spam management devices do is filter out spam in a trusted intermediary. That fails to leave the problem at the bot, but it does prevent the user from having to do it. The issue there is false positives and false negatives. Cisco tells me that upwards of 95% of email directed toward me is dropped by Ironport, meaning that I only deal with a daily average of about 60/day, the majority of which is dealt with by my Beysian filter. I can check for false positives or negatives there, but cannot in traffic dropped by Ironport.

What is it about this conversation that seems two layers higher than IPv6? :-)

On Jul 14, 2010, at 3:54 AM, Jeroen Massar wrote:

> On 2010-07-14 09:48, Mikael Abrahamsson wrote:
>> On Wed, 14 Jul 2010, Jeroen Massar wrote:
>> 
>>> Congratulations, you have just set up an automatic spammer for the
>>> millions of spammers out there, they spam you, and you spam back the
>>> spoofed email address.
>> 
>> Well, actually as far as I could see the email one gets back doesn't
>> really contain any subject/body from the original email, so the use for
>> spammers is limited (?).
> 
> It is another mail in your mailbox that should not be there in the first
> place.
> 
> Same issue as with DSNs, mails should be rejected at DATA time so that
> the sending SMTP server has the handle the issue, not by the receiving
> SMTP server which then accepts it and then decided it doesn't want it.
> 
> Greets,
> Jeroen
> 
> 
> 
> 

http://www.ipinc.net/IPv4.GIF