Confirmed across a variety of Mailman lists I administer.

Mailman can be patched to reject/discard posts from members with p=reject. https://code.launchpad.net/~jimpop/mailman/dmarc-reject I'm sort of glad that Yahoo did what they did, people are now seeing the dark side of DMARC. WooHoo!! Vindication! -Jim P.

In article <5345831B.4030705@dcrocker.net> you write:

On 4/9/2014 10:13 AM, Royce Williams wrote:

...

Am I interpreting this correctly -- that Yahoo's implementation of DMARC is broken, such that anyone using a Yahoo address to participate in a mailing list is dead in the water?

Their implementation is not 'broken'.

I'd say it's pretty badly broken if Yahoo intends for their web mail to continue to be a general purpose mail system for consumers. If they want to make it something else, that's certainly their right, but it would have been nice if they'd given us some advance warning so we could take the yahoo.com addresses off our lists. R's, John

On Wed, 09 Apr 2014 17:15:59 -0400, William Herrin said:

Meh. This just means list software will have to rewrite the From header to "From: John Levine <nanog@nanog.org>" and rely on the Reply-To header for anybody who wants to send a message back to the originator.

Maybe this is a good thing - we can stop getting all the "sorry I'm out of the office" emails when posting to a list.

The sort of programmer that writes out-of-mind software that doesn't employ the long well-known heuristics for detecting mailing lists (starting with checking Return-Path: for "owner-" and similar) will also likely disregard the Reply-To: header. This Is Not A Good Thing.

2: introduce an "Original Authentication Results" header to indicate you have performed the authentication and you are validating it

This was someone's hack that doesn't work. The idea is that you make an RFC5451 Authentication-Results header for the incoming message, change the name to original-authentication-results to circumvent some MTAs that strip incoming A-R headers, and send it as part of the signed outgoing message. The reason it doesn't work is that spammers can add fake o-a-r headers as easily as lists can add real ones, so you need to make a whitelist of well behaved senders who don't send faked mail so you know whether to believe them. But once you have the whitelist of well behaved senders, you can skip the o-a-r stuff and just deliver the mail. I gather somewhere there is a private non-standard bilateral implementation of this, but it still seems like an awfully complicated way to do your spam filtering. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly

The most "sane" out-of-mind response should only be sent *if* the out-of-mind person is named explicitly as a recipient in the RFC822 header. Anything To: somelist@somehost does not qualify :)

Funny story: When I was at IBM I filed that as a bug with Lotus Notes. The Notes team rejected the bug. -Jim P.

On 4/9/2014 6:11 PM, bmanning@vacation.karoshi.com wrote:

On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote:

...

The most "sane" out-of-mind response should only be sent *if* the out-of-mind person is named explicitly as a recipient in the RFC822 header. Anything To: somelist@somehost does not qualify :)

Jeff and just how is an algorithm supposed to detect that <jeff-kell@utc.edu> is a single human and not a list?

Because *I* set the out-of-office notification for my email address[es]. If I'm not in the recipient list, do not respond. This is a "per user" knob we are talking about here, so it knows darn well what address[es] are me. Jeff

On Wed, Apr 9, 2014 at 6:27 PM, John R. Levine <johnl@iecc.com> wrote:

...

...

The most "sane" out-of-mind response should only be sent *if* the out-of-mind person is named explicitly as a recipient in the RFC822 To: header. Anything To: somelist@somehost does not qualify :)

This highly effective trick was in the procmail example vacation script in 1991, and doubtless goes back much farther than that. It's a little dismaying to hear that there are still people writing autoresponders who don't know about it.

what is procmail?

On 4/9/2014 5:45 PM, George Michaelson wrote:

procmail is a rewrite of MMDF mailfilter. badly.

Thanks, but I believe it slightly preceded MMDF's equivalent facility. On the average, Allman put comparable features into sendmail sooner than I did. Of course, my design's were sooo much better than his, but that seems to have hurt it's adoption... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Aside from a horrid config notation. the main problem for me has always been getting sysadmins to include the changes which expose envelope-sender and envelope-recipient to procmail. Thats not procmail, its the way procmail is typically called. Without it, some stuff simply cannot be done because you don't know the values passed by protocol, only the values exposed in header. (this may have changed. I don't use it any more) On Thu, Apr 10, 2014 at 11:58 AM, John R. Levine <johnl@iecc.com> wrote:

On 4/9/2014 5:45 PM, George Michaelson wrote:

...

...

procmail is a rewrite of MMDF mailfilter. badly.

Thanks, but I believe it slightly preceded MMDF's equivalent facility. On

...

the average, Allman put comparable features into sendmail sooner than I did.

Procmail's user interface, if you can call it that, is beyond awful and looks like line noise. But the code is great.

Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly

All this talk about procmail leads me to ask: - has anybody come up with a procmail recipe, or other mechanism to validate DKIM-signed mail and apply an Original-Authentication-Results header, at the MTA level? - if so, does it work with Yahoo mail directed to mailing lists? - if yes, can you share?! (So far, all the folks I know who are trying to react, have been doing so via hacks to their list management software. I'm hoping to attack the problem at a more accessible step in mail processing). -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra

On Wed, Apr 9, 2014 at 6:11 PM, <bmanning@vacation.karoshi.com> wrote:

and just how is an algorithm supposed to detect that <jeff-kell@utc.edu> is a single human and not a list?

If the autoresponder is sane, it looks for: List-Id: North American Network Operators Group <nanog.nanog.org> List-Unsubscribe: <http://mailman.nanog.org/mailman/options/nanog>, <mailto:nanog-request@nanog.org?subject=unsubscribe> List-Archive: <http://mailman.nanog.org/pipermail/nanog/> List-Post: <mailto:nanog@nanog.org> List-Help: <mailto:nanog-request@nanog.org?subject=help> List-Subscribe: <http://mailman.nanog.org/mailman/listinfo/nanog>, <mailto:nanog-request@nanog.org?subject=subscribe> Precedence: list If the mailing list doesn't set those headers, that's the mailing list's fault. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Wed, Apr 9, 2014 at 6:11 PM, <bmanning@vacation.karoshi.com> wrote:

...

and just how is an algorithm supposed to detect that <jeff-kell@utc.edu> is a single human and not a list?

If the autoresponder is sane, it looks for:

List-Id: North American Network Operators Group <nanog.nanog.org>

Yes, there are a lot of headers that give you a hint that a message is from a list. But the heuristic to look for the recipient's address on the To: line works so well, along with a little rate limiting, that you don't really need anything else. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly

An aside: On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote:

Maybe this is a good thing - we can stop getting all the "sorry I'm out of the office" emails when posting to a list.

I entirely support that goal, but my preferred solution is the complete eradication of the software (a lot of which makes mistakes that have been well-known as mistakes for decades) and thus the entire practice of setting up "out of office" messages. Out-of-office notices might have had some relevance 20 or 30 years ago when much of the population was new to email and had not yet grasped in *any* sense how it works. And when there was a large overlap between "people who use email" and "people who read/send email from their offices and only from their offices". But I think by now everyone who is capable of being educated has been educated and realizes that the one of the reasons for the absence of a response is that the recipient hasn't seen the relevant message yet. There's really no need to spin the roulette wheel and hope that the combination of MUAs and MTAs on both ends is functional enough to enable the out-of-office software (optimistically presuming it's halfway sane) to figure out what it should do. And that's before we even get to the security and privacy issues that are in play, which are substantial. So while there are numerous approaches to solving the problem of errant out-of-office messages, and some of those approaches work pretty well in the field, I would prefer to kill the problem by attacking the source: the *existence* of out-of-office autoresponders. ---rsk

So I believe, if this list was not stripping the HTML part of the emails, as it does not add a subject tag nor a footer, then DKIM would survive the list and all would be fine… why does this list break DKIM when forwarding?

On 4/20/2014 18:08, Barney Wolff wrote:

On Sun, Apr 20, 2014 at 10:01:38PM +0000, Franck Martin wrote:

...

So I believe, if this list was not stripping the HTML part of the emails, as it does not add a subject tag nor a footer, then DKIM would survive the list and all would be fine?

why does this list break DKIM when forwarding?

My system says your message passed DKIM and DMARC. Perhaps that's because linkedin.com does not publish an SPF record.

They actually do: linkedin.com. 86400 IN SPF "v=spf1 ip4:8.18.31.21 ip4:8.18.31.22 ip4:69.28.149.0/24 ip4:199.101.160.0/25 ip4:199.101.162.0/25 ip4:108.174.3.0/24 ip6:2620:109:c006:104::/64 ip4:216.136.162.65 mx mx:docusign.net ~all" -- staticsafe https://asininetech.com

On Sun, Apr 20, 2014 at 3:01 PM, Franck Martin <fmartin@linkedin.com> wrote:

why does this list break DKIM when forwarding?

From the Gmail headers your email :

Authentication-Results: mx.google.com; spf=neutral (google.com: nanog-bounces+scott=example.com@nanog.orgdoes not designate permitted sender hosts) smtp.mail=nanog-bounces+scott= example.com@nanog.org; dkim=pass header.i=@linkedin.com; *dmarc=pass* (p=REJECT dis=NONE) header.from=linkedin.com Scott

On Apr 20, 2014, at 4:07 PM, Scott Howard <scott@doc.net.au> wrote:

On Sun, Apr 20, 2014 at 3:01 PM, Franck Martin <fmartin@linkedin.com> wrote: why does this list break DKIM when forwarding?

From the Gmail headers your email :

Authentication-Results: mx.google.com; spf=neutral (google.com: nanog-bounces+scott=example.com@nanog.org does not designate permitted sender hosts) smtp.mail=nanog-bounces+scott=example.com@nanog.org; dkim=pass header.i=@linkedin.com; dmarc=pass (p=REJECT dis=NONE) header.from=linkedin.com

Scott

Sure as long as I make sure my post is plain text only which you know is not anymore a standard on many email clients (and not configureable on many mobile mail clients). So if this list stops to strip the HTML mime part it will pass DMARC in all cases.

Dave Crocker wrote:

On 4/9/2014 3:05 PM, John Levine wrote:

...

In article <5345831B.4030705@dcrocker.net> you write:

...

Their implementation is not 'broken'.

I'd say it's pretty badly broken if Yahoo intends for their web mail to continue to be a general purpose mail system for consumers. If they want to make it something else, that's certainly their right, but it would have been nice if they'd given us some advance warning so we could take the yahoo.com addresses off our lists.

If I point a gun at you, and pull the trigger, but maybe shouldn't have done that, the gun is not broken.

Management decisions that are subject to criticism does not represent erroneous performance by the folks tasked with doing the task mandated.

Everything they are doing is "legal".

Your (possibly entirely valid) assessment that their action is ill-advised or unpleasant does not equal broken.

Well, sort of - given that DMARC is still an Internet draft, not even an experimental standard. Maybe it's doing what the draft says it is - but it's an alpha-level protocol, that breaks a lot of things it touches. If not "broken" it's certainly "not ready for prime time" - and large scale deployment is akin to a DDoS attack - i.e., not "ill-advised" but verging on criminal. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra

Dave Crocker wrote:

On 4/9/2014 7:25 PM, Miles Fidelman wrote:

...

Dave Crocker wrote:

...

Everything they are doing is "legal".

Your (possibly entirely valid) assessment that their action is ill-advised or unpleasant does not equal broken.

Well, sort of - given that DMARC is still an Internet draft, not even an experimental standard. Maybe it's doing what the draft says it is - but it's an alpha-level protocol, that breaks a lot of things it touches. If not "broken" it's certainly "not ready for prime time" - and large scale deployment is akin to a DDoS attack - i.e., not "ill-advised" but verging on criminal.

While IETF "full" standards status does indicate real deployment and serious technical maturity, IETF Proposed Standard does not mean mature or immature, given the varied history of work leading to Proposed.

SSL was quite mature, before the IETF did enhancements to produce TLS.

The IETF's version of DKIM was essentially v4 for the technology.

DMARC is estimated to currently cover roughly 60% of the world's email traffic. As "not ready for prime time" goes, that's quite a lot of prime time.

Yahoo! is choosing to apply the technology for usage scenarios that have long been known to be problematic. Again, they've made an informed choice. Whether it's justified and whether it was the right choice is more of a political or management discussion than a technical one.

In technical terms, DMARC is reasonably simple and reasonably well understood and extensively deployed.

For most discussions, that qualifies as 'mature'...

Speaking as someone who runs a few dozen mailing lists, and based on discussions on mailops and admin lists for various listserver packages, I humbly suggest that, as John Levine put it: "Yahoo breaks every mailing list in the world including the IETF's" suggests something something other than "reasonably simple and reasonably well understood and extensively deployed" and "mature." Especially after reading some of the discussions on the DMARC mailing list where it's clear that issues of breaking mailing lists were explicitly ignored and dismissed. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra

Your post advocates a (*) technical ( ) legislative ( ) market-based ( ) vigilante approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.) ( ) Spammers can easily use it to harvest email addresses (*) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks (*) It will stop spam for two weeks and then we'll be stuck with it (*) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it ( ) Requires too much cooperation from spammers (*) Requires immediate total cooperation from everybody at once (*) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business Specifically, your plan fails to account for ( ) Laws expressly prohibiting it (*) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email ( ) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves ( ) Bandwidth costs that are unaffected by client filtering ( ) Outlook and the following philosophical objections may also apply: ( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck (*) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud (*) Countermeasures should not involve sabotage of public networks (*) Countermeasures must work if phased in gradually ( ) Sending email should be free (*) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses (*) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough Furthermore, this is what I think about you: (*) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!

On 4/10/2014 5:05 AM, Tei wrote:

Your post advocates a

(*) technical ( ) legislative ( ) market-based ( ) vigilante

Since the nanog list isn't devoted to anti-spam work, folk might not know that you were calling upon the stellar web page developed by Cory Doctorow: http://craphound.com/spamsolutions.txt As far as I know, he meant it strictly for humor. However he did such a good job, it is common to point folk to it (or, as we've seen here, even fill it out) when the they declare that they have the FUSSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

On 04/09/2014 09:54 PM, Jimmy Hess wrote:

Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is "Too specific" a solution and cannot apply to e-mail in general.

DMARC is nothing more than warmed over ADSP which itself didn't have a pat answer for mailing list traversal. For transactional mail ADSP was just fine, but for regular mail the signing policy was meant to be a guide for other heuristics. It says nothing more than "i sign my mail outgoing", so what do you do if the signature is broken? If you want to take a hard line, then you are going to get all kinds of false positives... this has been known for 10 years at least. I'd be surprised to hear that Y! of all people was doing that, but it's their pissed off users' problem. Vote with your feet.

If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:.

An example of a solution would be the use of a DKIM alternative with not a single signature for the entire message, but only partial signing of parts of the message: specifically identified headers and/or specific body elements, to validate that the message was really sent and certain elements are genuine ---- and certain elements were modified by the mailing list.

You can more or less do this with DKIM already, and get about 90% of mailing list traffic to pass verification. The question is whether that's enough. I have no idea whether Y! is doing the things I did to get that pass rate.

The technical issue, is that the immaturity of the related specs. limits the decisions are available for a particular domain ---- so, essentially, if you have certain kind of user traffic: you have to incur technical issues with mailing lists, or forego using DMARC.

In other words: much as you would like to dismiss as purely a managerial decision ---- the decisions available to be made are entangled with the limitations of the technical options that are available for mitigating spoofing,

AND the public's understanding thereof.

Crocker may have some further insight that we're not privy to, but using signing policy on the general population as a raw instrument is well known to be a bad idea for DKIM and SPF's policy mechanisms as well. SPF in particular had a huge amount of blowback by punitive mail operators who didn't understand the implications, at least in the early days. It may indeed be management idiocy, but I can't see what the point is in defending the idiocy as being some sort of sacred right. Mike

On 04/09/2014 06:04 PM, Miles Fidelman wrote:

Especially after reading some of the discussions on the DMARC mailing list where it's clear that issues of breaking mailing lists were explicitly ignored and dismissed.

There's been 10 years of ostrichism about policy and mailing lists, especially from the crowd who were against ADSP until they were for it. Mike

I agree to a large extent with your comments/observations, but I'd like to focus on one point in particular: On Wed, Apr 09, 2014 at 11:00:57PM -0400, Andrew Sullivan wrote:

So, I'm trying to imagine the presentation slide on which appears the advice to implement the controversial adopted policy. I imagine in big, giant print "Will reduce yahoo.com abuse effects" and in one of those secondary bullets "May have consequences" and even lower "for our users on mailing lists" and "for mailing list managers/non-company".

This decision by Yahoo will have no effect whatsoever on the largest abuse problem, which is outbound spam/phishing/malware/etc. *sourced* by Yahoo. Those messages are (and have been for a long time) dutifully marked as authentic and in one sense they are: they really do originate from Yahoo's operation. But of course in a much more important operational sense they're not: they're forgeries created by the new owners of hijacked Yahoo user accounts. And those accounts are being hijacked at will by the millions, as they have been for many years. Yahoo is not alone in permitting an enormous volume of such messages to leave their operation and attack the rest of the Internet: Hotmail, Gmail, and the rest do the same. (Of course the rates vary, as do the targets. My spamtraps see large rate fluctuations across networks, domains, ASNs, etc. as well as through time. I strongly suspect that individual measurements at any one are essentially meaningless and that aggregation over a sufficiently diverse set over a sufficiently long time is necessary to construct a coherent, useful statistical model of what's really happening.) In other words, this deployment might reduce abuse OF Yahoo, but it will do nothing about the far more important problem of abuse BY Yahoo. Which pretty much lives up to my expectations. ---rsk

On 4/9/2014 8:00 PM, Andrew Sullivan wrote:

On Wed, Apr 09, 2014 at 12:27:55PM -0500, Dave Crocker wrote:

...

...

But it's the result of an informed corporate choice rather than software or operations error. Why do you think (it seems to me you've said it more than once) that this was "informed" choice?

Sorry for not responding when you posted this; I missed it. The answer is that Yahoo was an active participant in the creation of DMARC and the applicability and limitations of the design were well and fully discussed. Many times. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

On Mon, Apr 21, 2014 at 2:55 PM, Elizabeth Zwicky <zwicky@yahoo-inc.com> wrote:

I believe that our public statements make it clear that we realize that significant use cases are broken:

http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-p rotect-our-users

http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what -should-senders-do

Elizabeth Zwicky

While this issue has been beaten into the ground quite far, it's important to point out that Mailinglist sofware is adapting to address the headaches thrust upon us by your own internal spam problems. ;-) Fairly soon NANOG and other Mailman based lists will be able to flip a switch and wrap+attach emails from domains with strict policies. It may clutter up the archives a bit, but eventually users will tire of it and move on to a not-so-anal email service. :-) -Jim P.

Just a heads up to interested parties... Google seems to now be bouncing where From: is another gmail account. But it seems to be inconsistent. If you are reading this on a gmail account please let me know. -Jim P. On Mon, Apr 21, 2014 at 8:04 PM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:

Elizabeth Zwicky wrote:

...

I believe that our public statements make it clear that we realize that significant use cases are broken:

http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-p rotect-our-users

http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what -should-senders-do

Elizabeth Zwicky

What I do notice as interesting is that yahoo-inc.com and yahoogroups.com both publish dmarc records with "p=none"

Miles Fidelman

-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra

On Fri, Apr 25, 2014 at 12:12 PM, Jim Popovitch <jimpop@gmail.com> wrote:

On Fri, Apr 25, 2014 at 12:00 PM, Jim Popovitch <jimpop@gmail.com> wrote:

...

Just a heads up to interested parties... Google seems to now be bouncing where From: is another gmail account. But it seems to be inconsistent. If you are reading this on a gmail account please let me know.

-Jim P.

A few people have indicated to me that they are NOT seeing issues with GMail. Just to be clear, what I am seeing a pattern of gmail users sending email to mailinglists and every outbound email to other gmail users logs this:

Apr 24 18:19:20 svr5 postfix/smtp[32546]: BB2F73F2E3: to=<xxxxxxx@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.201.109]:25, delay=27, delays=0/27/0.44/0.06, dsn=5.5.1, status=bounced (host gmail-smtp-in.l.google.com[74.125.201.109] said: 530-5.5.1 Authentication Required. Learn more at 530 5.5.1 http://support.google.com/mail/bin/answer.py?answer=14257 hi8sm834730igb.8 - gsmtp (in reply to MAIL FROM command))

It's as though Gmail wants a mailinglist to authenticate to send email to gmail recipients. :-)

It's not persistent, it's just happened a few times in past 2 days, generally in the AM.

And it just happened again. Can someone from Google please tell me what to do when your inbound MX (port 25!) tells me to authenticate mailinglist traffic to your clients. Who's credentials should Mailman use? lol. Apr 25 22:22:23 svr5 postfix/smtp[1544]: 9CFA73F5BF: to=<*********@icaro.com.br>, relay=aspmx.l.google.com[74.125.201.109]:25, delay=167, delays=0/167/0.51/0.06, dsn=5.5.1, status=bounced (host aspmx.l.google.com[74.125.201.109] said: 530-5.5.1 Authentication Required. Learn more at 530 5.5.1 http://support.google.com/mail/bin/answer.py?answer=14257 m1sm33010igx.13 - gsmtp (in reply to MAIL FROM command)) -Jim P.