Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j6L0IWNJ000439 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 20 Jul 2005 17:18:32 -0700 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j6L0Hhvx023705 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 20 Jul 2005 17:17:44 -0700 In-Reply-To: <42DEDE7F.2010909@solidmatrix.com> References: <42DED3FB.3070000@yahoo-inc.com> <42DEDE7F.2010909@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <358CDD97-381C-4205-A1C0-AA91A6BAB94B@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [feedback-report] So... Date: Wed, 20 Jul 2005 17:17:44 -0700 To: Yakov Shafranovich X-Mailer: Apple Mail (2.733) X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-SpamCheck: X-Songbird-From: dotis@mail-abuse.org Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 00:18:33 -0000 On Jul 20, 2005, at 4:30 PM, Yakov Shafranovich wrote: > J.D. Falk wrote: > >> ...either the list is entirely broken except for me, or nobody >> cares about the additional use cases that have been proposed. Right? >> > > I am aware of the email traffic, just haven't had a chance to reply as > of yet. Give me a few days or so to finish up stuff from my wedding. > > >> How's the testing going? >> > > I am wondering the same. I was hoping to find out more about the Thunderbird plug-in for creating the reports. -Doug Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j6KNVRZn029527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2005 16:31:28 -0700 Received: from pool-70-22-39-43.balt.east.verizon.net ([70.22.39.43] helo=[192.168.1.46]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DvO1R-0001yX-17; Wed, 20 Jul 2005 19:30:41 -0400 Message-ID: <42DEDE7F.2010909@solidmatrix.com> Date: Wed, 20 Jul 2005 19:30:07 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J.D. Falk" , abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] So... References: <42DED3FB.3070000@yahoo-inc.com> In-Reply-To: <42DED3FB.3070000@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-MailScanner-From: yakovs@solidmatrix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - mipassoc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-SpamCheck: X-Songbird-From: yakovs@solidmatrix.com Cc: X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 23:31:45 -0000 J.D. Falk wrote: > ...either the list is entirely broken except for me, or nobody cares > about the additional use cases that have been proposed. Right? > I am aware of the email traffic, just haven't had a chance to reply as of yet. Give me a few days or so to finish up stuff from my wedding. > How's the testing going? > I am wondering the same. Yakov Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j6KMjtKR024878 for ; Wed, 20 Jul 2005 15:45:55 -0700 Received: (qmail 32815 invoked from network); 20 Jul 2005 22:45:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:X-Accept-Language:MIME-Version:To:Subject:Content-Type; b=fnMzOd3oxkFrQPQQhkkfK00Uwg3YDKL+U11b0AK5V24hxbQHh4Xtkwyl1/S14fpH ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp017.mail.yahoo.com with SMTP; 20 Jul 2005 22:45:06 -0000 Message-ID: <42DED3FB.3070000@yahoo-inc.com> Date: Wed, 20 Jul 2005 15:45:15 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: multipart/alternative; boundary="------------040701080406040103070500" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-SpamCheck: X-Songbird-From: jdfalk@yahoo-inc.com Subject: [feedback-report] So... X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 22:46:04 -0000 This is a multi-part message in MIME format. --------------040701080406040103070500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ...either the list is entirely broken except for me, or nobody cares about the additional use cases that have been proposed. Right? How's the testing going? -- J.D. Falk, Anti-spam Product Manager, Yahoo! Mail jdfalk@yahoo-inc.com --------------040701080406040103070500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ...either the list is entirely broken except for me, or nobody cares about the additional use cases that have been proposed.  Right?

How's the testing going?
 
-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
jdfalk@yahoo-inc.com
--------------040701080406040103070500-- Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j6FIg4c7011045 for ; Fri, 15 Jul 2005 11:42:04 -0700 Received: (qmail 7164 invoked from network); 15 Jul 2005 18:40:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:X-Accept-Language:MIME-Version:To:Subject:Content-Type; b=k3ELG1rEvV8Nm7spNAETNdU+9rQiF/KF/4K5tyX6zUozkE0aitN2h/NBCbpubYOP ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp018.mail.yahoo.com with SMTP; 15 Jul 2005 18:40:55 -0000 Message-ID: <42D8033E.1070801@yahoo-inc.com> Date: Fri, 15 Jul 2005 11:41:02 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: multipart/alternative; boundary="------------030005080102070501070803" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: jdfalk@yahoo-inc.com Subject: [feedback-report] [Fwd: FW: Evidence Use Case] X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 18:42:20 -0000 This is a multi-part message in MIME format. --------------030005080102070501070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Can someone please figure out why the list isn't accepting posts from new subscribers? -------- Original Message -------- Subject: FW: Evidence Use Case Date: Fri, 15 Jul 2005 16:25:06 +1000 From: David Jones To: JD, I am in a similar situation to Vipul in that I could not submit to the abuse-feedback-report. I initially sent the note below on Jun 23 - retried a few times without joy. For a previous submission I sent to Yakov but I think he is currently away in newly-wed bliss. Could you please do the delivery. Thanks and regards David > > ----- Forwarded message from "djones@spammatters.com" > ----- > Date: Thu, 23 Jun 2005 23:56:38 +1000 > From: "djones@spammatters.com" > Reply-To: "djones@spammatters.com" > Subject: Evidence Use Case > To: "abuse-feedback-report@mipassoc.org" > > > > At the risk of triggering grumpiness, I'd like to confirm my > comments/questions at MAAWG :) > > 1. A use case exists for using reports in > evidentiary/enforcement processes. > > 2. To support this, no material change is required but the > following is requested: > a) I'd actively support the open issue of adding an optional > 'munged' indicator. > Its understood that header and body munging is common for > privacy. From my experience, enforcement processes will > accept both munged and unmunged data as long as they: (i) get > enough unmunged evidence (ii) know which submission are > unmunged and of appropriate evidentiary grade. > b) An optional indicator for human entered content (either > structured or free-text). > Arrgh you say! We know that any free-form text is usually of > zero value in feedback but anecdotal additions may add value > later in investigative stages of enforcement. > > 3. Implementers should accept signed feedback reports. > (probably outside the scope but just mentioning for implementors). > > I think/hope this Use Case does not undermine the "Simplicity > Encourages Adoption" but could add some real value outside > normal ISP feedback processes. > > thanks > David > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > ----- End forwarded message ----- > > > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > > > -- J.D. Falk, Anti-spam Product Manager, Yahoo! Mail jdfalk@yahoo-inc.com --------------030005080102070501070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Can someone please figure out why the list isn't accepting posts from new subscribers?

-------- Original Message --------
Subject: FW: Evidence Use Case
Date: Fri, 15 Jul 2005 16:25:06 +1000
From: David Jones <DJones@spammatters.com>
To: <jdfalk@yahoo-inc.com> 


JD,

I am in a similar situation to Vipul in that I could not submit to the
abuse-feedback-report. I initially sent the note below on Jun 23 -
retried a few times without joy.

For a previous submission I sent to Yakov but I think he is currently
away in newly-wed bliss. Could you please do the delivery.

Thanks and regards
David

> 
> ----- Forwarded message from "djones@spammatters.com" 
> <djones@spammatters.com> -----
>     Date: Thu, 23 Jun 2005 23:56:38 +1000
>     From: "djones@spammatters.com" <djones@spammatters.com>
> Reply-To: "djones@spammatters.com" <djones@spammatters.com>
>  Subject: Evidence Use Case
>       To: "abuse-feedback-report@mipassoc.org" 
> <abuse-feedback-report@mipassoc.org>
> 
> 
> At the risk of triggering grumpiness, I'd like to confirm my 
> comments/questions at MAAWG :)
> 
> 1. A use case exists for using reports in 
> evidentiary/enforcement processes.
> 
> 2. To support this, no material change is required but the 
> following is requested:
> a) I'd actively support the open issue of adding an optional 
> 'munged' indicator.
> Its understood that header and body munging is common for 
> privacy. From my experience, enforcement processes will 
> accept both munged and unmunged data as long as they: (i) get 
> enough unmunged evidence (ii) know which submission are 
> unmunged and of appropriate evidentiary grade.
> b) An optional indicator for human entered content (either 
> structured or free-text). 
> Arrgh you say! We know that any free-form text is usually of 
> zero value in feedback but anecdotal additions may add value 
> later in investigative stages of enforcement.
> 
> 3. Implementers should accept signed feedback reports. 
> (probably outside the scope but just mentioning for implementors).
> 
> I think/hope this Use Case does not undermine the "Simplicity 
> Encourages Adoption" but could add some real value outside 
> normal ISP feedback processes.
> 
> thanks
> David
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> ----- End forwarded message -----
> 
> 
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> 
> 
> 





-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
jdfalk@yahoo-inc.com
--------------030005080102070501070803-- Received: from a.mad.olsns.net (a.mad.olsns.net [213.195.75.88]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j6EIFmxY018097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Jul 2005 11:15:50 -0700 Received: from [80.59.152.232] (helo=[192.168.0.7]) by b.mx.ols.es with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Dt8EM-0001VG-8E for abuse-feedback-report@mipassoc.org; Thu, 14 Jul 2005 20:14:42 +0200 Message-ID: <42D6ACA9.3040907@ols.es> Date: Thu, 14 Jul 2005 20:19:21 +0200 From: David Organization: On-Line Services 2000, S.L. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: ca MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: david@ols.es at b.mx.ols.es X-OLS-Security: OK - Virus scanned by ClamAV 0.86.1/978/Thu Jul 14 13:37:27 2005 X-Complaints-To: abuse@ols.es X-Complaints-To: abuse@ols.es X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: david@ols.es Subject: [feedback-report] expanding the specification X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 18:16:10 -0000 Hi !! I just read this draft, it looks great but it's too focused on email. It will be very nice to also use this format for other abuse types (port scans, virus attacks, email dictionary attacs, DoS attacks, etc ...). Altough the proposal talks about other kinds of abuse it's too binded to email abuse, i.e. section 3 'Requirements' requires a copy of the original email but there are other kind of abuse (i.e. port scans) that have no email to send. There are many other sections that make this draft incompatible to be used on other kind of abuses, and it will be really nice that it could accomodate other kind of incident reports from the begining. I know it's difficult to make very general standards, they often do not produce anything useful, but it's also bad to restrict standars from the begining. Rfc's take a long time to publish and having a RFC that extends/obsoletes this one will take many years. The difference between "obsoletes" and "extends" is important. "Extends" can be done with incremental changes, using additional specifications. Therefore the base specification does not need to be changed, but that specification would need to be changed to accomodate other no email related incidents. Minor changes like replacing 'A copy of the original email message (body and headers) or the message headers must be enclosed' by 'A copy of the original email message (body and headers) or the message headers MUST be enclosed if the incident to report was originated by the recepction on an email message' would allow easy extension in the future. It would also be useful to add an optional field for the datetime (in a normalized format) when the message/incident was received so used in conjuntion with Source-IP could allow ISP's to identify dinamic ip user's without having to examine the message headers or when no message has been attached. -- Thanx & best regards ... ---------------------------------------------------------------- David Saez Padros http://www.ols.es On-Line Services 2000 S.L. e-mail david@ols.es Pintor Vayreda 1 telf +34 902 50 29 75 08184 Palau-Solita i Plegamans movil +34 670 35 27 53 ---------------------------------------------------------------- Received: from smtp110.mail.sc5.yahoo.com (smtp110.mail.sc5.yahoo.com [66.163.170.8]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j65JOvdj019670 for ; Tue, 5 Jul 2005 12:24:57 -0700 Received: (qmail 37991 invoked from network); 5 Jul 2005 19:24:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:X-Accept-Language:MIME-Version:To:Subject:Content-Type; b=TxMH6R9VyC+d+geSGSwhfta1CmynwWEbLyBjiRwfPYcwk8sEpvhEcqWG7GCODlLr ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp110.mail.sc5.yahoo.com with SMTP; 5 Jul 2005 19:24:09 -0000 Message-ID: <42CADE5B.6040100@yahoo-inc.com> Date: Tue, 05 Jul 2005 12:24:11 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: multipart/alternative; boundary="------------070107010107050303080309" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: jdfalk@yahoo-inc.com Subject: [feedback-report] [Fwd: ARF feedback.] X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2005 19:25:01 -0000 This is a multi-part message in MIME format. --------------070107010107050303080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarding by request. -------- Original Message -------- Subject: ARF feedback. Date: Sat, 2 Jul 2005 14:41:08 -0700 From: Vipul Ved Prakash To: JD, Somehow still can't get to ARF list, so I am sending feedback directly to you. These points are based my experience with Razor/SpamNet that supports submission of messages to us: "Message-Truncated" header There will be instance when the message to be reported is too big and the client is not willing to report the entire message. It could be argued that the recipient does not want to get multiple 5Mb reports for large spam/worm emails. A new header could be used to indicate that the message was truncated at a particular length. For instance, a reporting agent could be programmed with a max limit, say 64Kb and for messages that exceed 64Kb, it would add a header: Message-Truncated: 65535 and truncate the message at 65535 bytes. This could be an optional header. Formats other than RFC822 I pointed this out in the BOF at INBOX, and I don't want to belabor this point, but I think it is important to support formats other than RFC822. Outlook, for instance, provides the message through MAPI in form of multiple "buckets". In many cases, a single MIME part is presented as multiple buckets (HTML version, text version, etc), and re-creation of original RFC822 is mostly impossible. I understand that Outlook support is not the primary focus at this stage, but there should be a provision in the spec to include outliers like Outlook. For Outlook this could be done through a MIME header like message/outlook, that comprises of multiple message/outlookbuckets. Other clients like Eudora and mail.app also modify the original message, but they retain the RFC822 format. For these the UserAgent hint is sufficient to indicate that the reported message is different from the original one. Supressing Headers Razor and Cloudmark clients support an option to supress headers and only report the message. I think this is an important privacy option, since headers can contain internal routing information that might be considered private by some organizations. Header suppression could also be support by a MIME header like message/rfc822-noheaders. Cheers, Vipul -- J.D. Falk, Anti-spam Product Manager, Yahoo! Mail jdfalk@yahoo-inc.com --------------070107010107050303080309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Forwarding by request.

-------- Original Message --------
Subject: ARF feedback.
Date: Sat, 2 Jul 2005 14:41:08 -0700
From: Vipul Ved Prakash <vipul@cloudmark.com>
To: <jdfalk@yahoo-inc.com> 


JD,

Somehow still can't get to ARF list, so I am sending feedback directly
to you. These points are based my experience with Razor/SpamNet that
supports submission of messages to us: 

"Message-Truncated" header

    There will be instance when the message to be reported is
    too big and the client is not willing to report the entire
    message. It could be argued that the recipient does not want
    to get multiple 5Mb reports for large spam/worm emails. A
    new header could be used to indicate that the message was
    truncated at a particular length. For instance, a reporting
    agent could be programmed with a max limit, say 64Kb and for
    messages that exceed 64Kb, it would add a header:

            Message-Truncated: 65535

    and truncate the message at 65535 bytes. This could be an
    optional header.

Formats other than RFC822

    I pointed this out in the BOF at INBOX, and I don't want to
    belabor this point, but I think it is important to support
    formats other than RFC822. Outlook, for instance, provides
    the message through MAPI in form of multiple "buckets". In
    many cases, a single MIME part is presented as multiple
    buckets (HTML version, text version, etc), and re-creation
    of original RFC822 is mostly impossible. I understand that
    Outlook support is not the primary focus at this stage, but
    there should be a provision in the spec to include outliers
    like Outlook. For Outlook this could be done through a MIME
    header like message/outlook, that comprises of multiple
    message/outlookbuckets.

    Other clients like Eudora and mail.app also modify the
    original message, but they retain the RFC822 format. For
    these the UserAgent hint is sufficient to indicate that the
    reported message is different from the original one.

Supressing Headers

    Razor and Cloudmark clients support an option to supress
    headers and only report the message. I think this is an
    important privacy option, since headers can contain internal
    routing information that might be considered private by some
    organizations. Header suppression could also be support by a
    MIME header like message/rfc822-noheaders.

Cheers,
Vipul





-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
jdfalk@yahoo-inc.com
--------------070107010107050303080309--