Hotmail JMRP messages
Hi. Has anyone got any Hotmail JMRP messages I could have a copy of to experiment on? -- Michael Stevens Dianomi Ltd 18 Buckingham Gate London SW1E 6LB Tel: 020 7802 5530 Fax: 020 7630 7356 www.dianomi.com The information in this message and any attachment is intended for the addressee and is confidential and may be subject to legal privilege. Dianomi Ltd, Registered Office: One America Square, Crosswall, London. EC3N 2SG. Registered in England and Wales with Company Registration Number 4513809. VAT registration number: 809754988
Re: Hotmail JMRP messages
I've started hacking on a module to parse them and fake them up as Email::ARF::Report objects: http://github.com/mstevens/Email--ARF--Hotmail Works with my test case, but it'd be good to get some messages from other people, especially ones that haven't gone through a google apps mailing list as an intermediate stage. 2010/1/8 Michael Stevens michael.stev...@dianomi.com Hi. Has anyone got any Hotmail JMRP messages I could have a copy of to experiment on? -- Michael Stevens Dianomi Ltd 18 Buckingham Gate London SW1E 6LB Tel: 020 7802 5530 Fax: 020 7630 7356 www.dianomi.com The information in this message and any attachment is intended for the addressee and is confidential and may be subject to legal privilege. Dianomi Ltd, Registered Office: One America Square, Crosswall, London. EC3N 2SG. Registered in England and Wales with Company Registration Number 4513809. VAT registration number: 809754988 -- Michael Stevens Dianomi Ltd 18 Buckingham Gate London SW1E 6LB Tel: 020 7802 5530 Fax: 020 7630 7356 www.dianomi.com The information in this message and any attachment is intended for the addressee and is confidential and may be subject to legal privilege. Dianomi Ltd, Registered Office: One America Square, Crosswall, London. EC3N 2SG. Registered in England and Wales with Company Registration Number 4513809. VAT registration number: 809754988
Email::ARF problems
Hi. I'm trying to use Email::ARF on incoming abuse reports. In particular the ones I'm processing come from AOL. I can parse them and create an Email::ARF::Report object, but when trying to get the body of the original message, I get something that looks quoted-printable encoded - lines end in =, and it's generally not as I'd expect. This makes it difficult to parse out my ids identifying the specific message being complained about. Should I be able to see the decoded body? -- Michael Stevens Dianomi Ltd 18 Buckingham Gate London SW1E 6LB Tel: 020 7802 5530 Fax: 020 7630 7356 www.dianomi.com The information in this message and any attachment is intended for the addressee and is confidential and may be subject to legal privilege. Dianomi Ltd, Registered Office: One America Square, Crosswall, London. EC3N 2SG. Registered in England and Wales with Company Registration Number 4513809. VAT registration number: 809754988
Re: spam category for Mail::DeliveryStatus::BounceParser
2009/11/24 William Yardley p...@veggiechinese.net On Fri, Nov 13, 2009 at 11:03:10AM -0500, Ricardo Signes wrote: * Michael Stevens michael.stev...@dianomi.com [2009-11-13T10:20:58] I'm pondering adding a spam category to std_reason in Mail::DeliveryStatus::BounceParser. This would record when a message was bounced because the recipient considered it spam. Does this sound reasonable? Yes. I think there had been some talk about this a long while back, when I was using MBP for a project working on this a little more actively. The only issue to me is that calling it spam doesn't make it super obvious whether the message itself is spam (i.e., not a bounce at all, but spam), or whether the bounce parser thinks that the message was rejected because the intended recipient considered it spam (I think it might actually be useful to have a spam classification for messages tagged as spam by an external filter, but passed along to the bounce-parser). It's a potential problem, with the name spam, although if they read the documentation they'll see it explains what's considered spam (see my tree on github). On a more technical level, I think it may be difficult to do this reliably. Presumably, dnsbl based rejections (e.g., 554 10.0.0.1 blocked by dnsbl.example.com), anything containing the word spam (554 message appears to be spam), and other low hanging fruit would be easy enough to match, but I think any such logic should definitely err on the side of caution. Plenty of policy based rejections aren't due to spam. At the moment the classifications I've done are only on fairly obvious you have been blackllisted / are considered spam examples, so hopefully we're okay here. I don't have as much time to spend looking at bounces as I have had in the past few weeks, but I still hope to keep tweaking things on and off. -- Michael Stevens Dianomi Ltd 18 Buckingham Gate London SW1E 6LB Tel: 020 7802 5530 Fax: 020 7630 7356 www.dianomi.com The information in this message and any attachment is intended for the addressee and is confidential and may be subject to legal privilege. Dianomi Ltd, Registered Office: One America Square, Crosswall, London. EC3N 2SG. Registered in England and Wales with Company Registration Number 4513809. VAT registration number: 809754988
spam category for Mail::DeliveryStatus::BounceParser
Hi. I'm pondering adding a spam category to std_reason in Mail::DeliveryStatus::BounceParser. This would record when a message was bounced because the recipient considered it spam. Does this sound reasonable? -- Michael Stevens Dianomi Ltd 18 Buckingham Gate London SW1E 6LB Tel: 020 7802 5530 Fax: 020 7630 7356 www.dianomi.com The information in this message and any attachment is intended for the addressee and is confidential and may be subject to legal privilege. Dianomi Ltd, Registered Office: One America Square, Crosswall, London. EC3N 2SG. Registered in England and Wales with Company Registration Number 4513809. VAT registration number: 809754988
