Any help for Yahoo! Mail arrogance?

Mailman List Mirror (Read Only)
1

Background:

  We MX for a domain, and turn it right around
to Yahoo! Mail. I know others have run into this
before. Because a fair amount of it is spam,
Yahoo stops accepting the mail, yadda yadda yadda.

Problem:

  I jumped through all the hoops, and they
tell me I'm denied. When I ask what part I fail
on, I get :

  "Unfortunately, we cannot provide you with
specific information other than to suggest a review
of the questionnaire we supplied and try to determine
where your mailing practices may be improved upon."

  WTF is that all about?!

  How can I improve on getting an email,
spam filtering the best I can, and turning it
around to it intended recipient. Anyone have
any clues?

    Thanks, Tuc

2

In other words, fix your forwarding a lot better (and possibly
segregate it from your main mail stream, clearly label the forwarding
IP as a forwarder, etc)

Yahoo arent really in the business of teaching people how to do a
better job. If that sounds like arrogance ..

srs

3

> "Unfortunately, we cannot provide you with
> specific information other than to suggest a review
> of the questionnaire we supplied and try to determine
> where your mailing practices may be improved upon."

In other words, fix your forwarding a lot better (and possibly
segregate it from your main mail stream, clearly label the forwarding
IP as a forwarder, etc)

Yahoo arent really in the business of teaching people how to do a
better job. If that sounds like arrogance ..

srs

  "Fix your forwarding a lot better". Not sure what this
means. My machines are MX's for the clients domain. They
accept it, and either forward it around locally to one of the
processing MX's or ARE one one of the processing MX's. Its
then run through SpamAssassin hoping to do the best we can to
filter out REALLY bad spam, and the box either directly tries
to send to a Yahoo! MX mailer, or forwards to another outbound
box to attempt to send it out. I'm not sure where in that whole
equation we are doing anything that isn't the best we can
except if we assign a person to sit down, read each and every
email, and then forward it along to the destination user. As
it is now, I'm sure we drop some legit mail... And I know
some legit mail isn't getting through since Yahoo! relays aren't
accepting ANYTHING. (And, as a result, even my emails to them
were lagged by days while they stopped accepting anything from
us for a while).

  Segregate from our main mail stream? We have this 1
customer (Yes, currently, one) who has this type of setup. They
are on a shared server. I should set up a single box just to
handle their MX? We are a hosting company, the only time
we send mail to Yahoo! otherwise is if one of their customers
fills a webform out that maybe copies them, they are on a
mailing exploder, or we reply to a customer who uses Yahoo!.

  Label forwarding IP as a forwarder... We told them,
they told us that our IP was RFC1918 (Which it wasn't)
and that they wouldn't accept that. Once I could convince
them that we weren't using RFC1918 to route, and that our
IP range was Legacy Internic IP's which were perfectly
valid to be routed, they then turned around and found
another excuse.

  No, they aren't in the business to teach someone
who's been in the industry all his life, and run
Managed Server Companies for over 11 years... But to
play the "We aren't going to tell you why we aren't
accepting your mail, you'll just have to guess and
submit back in *6* months.... (AND, tell their user
to set up a filter to receive the email {WHEN ITS
IMPOSSIBLE SINCE THE MAIL NEVER MAKES IT}) is just
unbelievable and arrogant to me.

    Tuc/TBOH

4

Define "run"... you have piqued my curiosity on this issue.

Please only reply to the list, not to From:/Reply-To: AND the list

-Jim P.

5

You could at least have set a Reply-To: so that those people who mindlessly hit
'reply' would have your desired reply destination already filled in.
Requesting that people reply a particular way without bothering to specify the
RFC-approved way of setting said replies is, at best, impolite.

(I'd have nagged in private, but you *did* say "reply to the list" after all)

6

> Please only reply to the list, not to From:/Reply-To: AND the list

You could at least have set a Reply-To: so that those people who mindlessly hit
'reply' would have your desired reply destination already filled in.
Requesting that people reply a particular way without bothering to specify the
RFC-approved way of setting said replies is, at best, impolite.

(I'd have nagged in private, but you *did* say "reply to the list" after all)

LOL.

I just totally dislike getting list traffic in both my Inbox AND <list>
folder.

-Jim P.

7

Yes, that's just how forwarding and .forwards work.

And if you mix inbound email (much dirtier than outbound email even if
you run a secure shop) into a mail stream that includes email sent out
by your clients, you potentially have random botnet spam, spam from
sbl listed spammers etc (in other words, a lot of "block on sight"
stuff) leaking through your IP, the same IP that a bunch of your other
customers use to mail out to their aunt mary on yahoo.

The numbers from that one .forward are enough to screw up the rest of
your numbers, a 5% or less complaint rate on email from your IP (and
believe me, if your user is jackass enough to click report spam on
email that comes through his .forward the complaints can go up real
high) .. is enough to get your IP blocked.

Dealing with tier 1 support anywhere (not the least of where is yahoo)
is always a pain. Which is why what I am suggesting is avoidance and
prevention rather than going around alternatively begging yahoo to fix
something or accusing them on nanog of being arrogant.

--srs

8

What are the addresses of the machines?

-M<

9

>
> >
> >
> >
> > > "Unfortunately, we cannot provide you with
> > > specific information other than to suggest a review
> > > of the questionnaire we supplied and try to determine
> > > where your mailing practices may be improved upon."
> >
> > In other words, fix your forwarding a lot better (and possibly
> > segregate it from your main mail stream, clearly label the forwarding
> > IP as a forwarder, etc)
> >
> > Yahoo arent really in the business of teaching people how to do a
> > better job. If that sounds like arrogance ..
> >
> > srs
> >
> "Fix your forwarding a lot better". Not sure what this
> means. My machines are MX's for the clients domain.

What are the addresses of the machines?

-M<

  192.136.64.0/24, with the 3 main machines being at 108, 116, 156
and lesser machines at 204, 212, etc.

      Tuc/TBOH

10

> "Fix your forwarding a lot better". Not sure what this
> means. My machines are MX's for the clients domain. They
> accept it, and either forward it around locally to one of the
> processing MX's or ARE one one of the processing MX's. Its

Yes, that's just how forwarding and .forwards work.

And if you mix inbound email (much dirtier than outbound email even if
you run a secure shop) into a mail stream that includes email sent out
by your clients, you potentially have random botnet spam, spam from
sbl listed spammers etc (in other words, a lot of "block on sight"
stuff) leaking through your IP, the same IP that a bunch of your other
customers use to mail out to their aunt mary on yahoo.

  AH, I see the confusion. We are a managed server hosting
company, not a Cable/DSL/T#/Dialup provider. The only way mail gets
sent out of here is Webmail, FormMail and Mail exploder. I'm pretty sure
none of our systems have been comprimised and forwards mail that we
don't know about.

The numbers from that one .forward are enough to screw up the rest of
your numbers, a 5% or less complaint rate on email from your IP (and
believe me, if your user is jackass enough to click report spam on
email that comes through his .forward the complaints can go up real
high) .. is enough to get your IP blocked.

  Except for maybe unfortunately backscatter from people CLAIMING
to originate email from our clients, our outbound should be fairly low
volume and reasonably clean.

Dealing with tier 1 support anywhere (not the least of where is yahoo)
is always a pain. Which is why what I am suggesting is avoidance and
prevention rather than going around alternatively begging yahoo to fix
something or accusing them on nanog of being arrogant.

  I'm not begging Yahoo to fix something, just to accept our mail.
I'm doing the best I can, and I'm sure to the DETRIMENT of the user, to
cut down on the spam, but short of having someone physically inspect
all email for spam and backscatter I really can't do much else (Except
get the user to have a local Webmail which I know they don't want).

    Tuc/TBOH

11

>
> > "Fix your forwarding a lot better". Not sure what this
> > means. My machines are MX's for the clients domain. They
> > accept it, and either forward it around locally to one of the
> > processing MX's or ARE one one of the processing MX's. Its
>
> Yes, that's just how forwarding and .forwards work.
>
> And if you mix inbound email (much dirtier than outbound email even if
> you run a secure shop) into a mail stream that includes email sent out
> by your clients, you potentially have random botnet spam, spam from
> sbl listed spammers etc (in other words, a lot of "block on sight"
> stuff) leaking through your IP, the same IP that a bunch of your other
> customers use to mail out to their aunt mary on yahoo.
>
        AH, I see the confusion. We are a managed server hosting
company, not a Cable/DSL/T#/Dialup provider. The only way mail gets
sent out of here is Webmail, FormMail and Mail exploder.

So no mail would ever be coming inbound and then being forwarded on?
That seems...unlikely.

I'm pretty sure
none of our systems have been compromised and forwards mail that we
don't know about.

Yet your sending IP reputation is poor....

Regards,
Al Iverson

12

believe me, if your user is jackass enough to click report spam on
email that comes through his .forward the complaints can go up real
high) .. is enough to get your IP blocked.

While there really should be some sort of particularly painful and embarrassing punishment for this sort of jackass** we just kill their .forward and try to clue-by-four them when they call. Sigh.

On a more relevant and operational sort of note, it sure would be nice if there were a NAMOG (North American Mail Operators Group) or the like to resolve these sorts of issues. Feel free to clue-by-four me if I've missed it.

--chuck goolsbee

**who seem to have all been drawn like moths to a flame into the companies my company has acquired over the years... as if to punish ME for some past transgression!

13

MAAWG come pretty close: http://www.maawg.org/home

Regards,
Al Iverson

14

Smaller/regional ISPs need not apply. Minimum cost of entry is $3,000/year, no voting rights ($12.5K if you actually care about voting). So if you're not Verizon or Comcast or similarly sized, it appears you're not really welcome.

Though it might make sense to discuss some other things NANOG could do in addition to worrying about routing table size and churn in the core, those are all discussions for the Futures list.

15

I have a sinking fear it'll be overrun with loud people who aren't
actually responsible for anything more than a single IP at most, like
SPAM-L, but I suppose it's worth a shot.

Al Iverson

16

Hi Chuck,

Mail problems that are operational in nature are more than welcome
here. The politics and kookery of spam policy and fighting should be
directed elsewhere.

Best Regards,

Martin Hannigan
NANOG MLC Member

17

Martin Hannigan said:

Mail problems that are operational in nature are more than welcome
here.

Thanks Martin.

So... If there are any bellsouth.net mail ops people here, please contact me privately. We had an out of control .forward user who we have larted/fixed permanently (well over two weeks ago), but bellsouth.net is still refusing mail from some of our outbound mail servers. All we see in the waiting/rejected queues is legit mail. We're a webhost/colo provider, in no way pushing tinned meat products.

Should be easy to fix, but I'm not getting traction from your end.

Regards,
--chuck goolsbee

answering at:

noc@forest.net

206-838-1630, ext 2001

18

Well, the current nanog MLC is mostly because Susan Harris was
cracking down equally on discussions of anything mail / spam filtering
related (operational not kooky) .. in fact, on anything that didnt
involve pushing packets from A to B.

And we have Marty Hannigan from the MLC telling us that operational
mail / spam filtering issues are perfectly on topic. New list not
particularly necessary I think .. but sure, a spam or mailops bof at
nanog would be a good idea. I (or well, APCAUCE) have been running a
spam conference track at APRICOT for the past few years now ..

srs

19

This has veered from operational discussion into the realm of
meta-discussion about the list, so let's move it to nanog-futures.
Reply-to has been set accordingly in this email, please respect it.

MLC's position is that anything that is acceptable for the conference is
acceptable on the list. Mail operations are on-topic, although
tangentially. Spam filtering is definitely off-topic.

-alex [mlc chair]

20

[ snip ]

MLC's position is that anything that is acceptable for the conference is
acceptable on the list. Mail operations are on-topic, although
tangentially. Spam filtering is definitely off-topic.

Perhaps personal filtering is not, but spam appliances or home grown
filtering, methods, code, or techniques for the purpose of despamming
customer in/out mail is mail operations are, for all intents and
purposes, on topic. I've demonstrated this myself in a few topics
related to spam ddos and surrounding tools and techniques.

The only thing I'd ask is that people don't branch off threads. It
messes up our killfiles. :slight_smile:

Martin Hannigan
NANOG MLC Member

From MAILER-DAEMON Thu Nov 1 03:34:20 2007
Return-Path: <>
X-Original-To: hyper_nanog@trapdoor.merit.edu
Delivered-To: hyper_nanog@trapdoor.merit.edu
Received: from localhost (localhost [127.0.0.1])
  by trapdoor.merit.edu (Postfix) with ESMTP id 0036F4DF4B
  for <hyper_nanog@trapdoor.merit.edu>; Thu, 1 Nov 2007 03:33:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at merit.edu
Received: from trapdoor.merit.edu ([127.0.0.1])
  by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024)
  with ESMTP id 5U5eF9WXGG1b for <hyper_nanog@trapdoor.merit.edu>;
  Thu, 1 Nov 2007 03:33:28 -0400 (EDT)
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
  by trapdoor.merit.edu (Postfix) with ESMTP id A81CA4DF2B
  for <hyper_nanog@trapdoor.merit.edu>; Thu, 1 Nov 2007 03:33:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
  id 3DF0C58281; Thu, 1 Nov 2007 03:33:24 -0400 (EDT)
Delivered-To: hyper_nanog@segue.merit.edu
Received: from mozart.merit.edu (mozart.merit.edu [198.108.95.9])
  by segue.merit.edu (Postfix) with ESMTP id EE1B858280
  for <hyper_nanog@segue.merit.edu>; Thu, 1 Nov 2007 03:33:23 -0400 (EDT)
Received: from bach.merit.edu (bach.merit.edu [198.108.95.7])
  by mozart.merit.edu (MOS 3.8.2-GA)
  with ESMTP id ATG53312;
  Thu, 1 Nov 2007 03:33:23 -0400 (EDT)
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
  by bach.merit.edu (MOS 3.8.2-GA)
  with ESMTP id AFK11176;
  Thu, 1 Nov 2007 03:33:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
  id E9D334DF38; Thu, 1 Nov 2007 03:28:35 -0400 (EDT)
Delivered-To: nanog-outgoing@trapdoor.merit.edu
X-Virus-Scanned: amavisd-new at merit.edu
Received: from trapdoor.merit.edu ([127.0.0.1])
  by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024)
  with ESMTP id J3W2QEsaqC+5 for <nanog-outgoing@trapdoor.merit.edu>;
  Thu, 1 Nov 2007 03:28:33 -0400 (EDT)
Received: from mozart.merit.edu (mozart.merit.edu [198.108.95.9])
  by trapdoor.merit.edu (Postfix) with ESMTP id 2E1C04DF28
  for <nanog-outgoing@trapdoor.merit.edu>; Thu, 1 Nov 2007 03:28:33 -0400 (EDT)
Message-Id: <200711010728.ATG51994@mozart.merit.edu>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
  boundary="ATG51994.1193902112/mozart.merit.edu"
Auto-Submitted: auto-generated (failure)
X-Junkmail-Status: score=10/50, host=bach.merit.edu
X-Junkmail-SD-Raw: score=unknown,
  refid=str=0001.0A090208.47298064.00FC:SCFONLINE515760,ss=1,fgs=0,
  ip=198.108.1.26,
  so=2006-09-22 03:48:54,
  dmn=5.4.3/2007-09-06

This is a MIME-encapsulated message

--ATG51994.1193902112/mozart.merit.edu

On this date, there were delivery failures where the associated
deliver status notification messages were suppressed.

--- The following addresses had suppressed delivery status notifications ---
nanog@trapdoor.merit.edu

   ----- Transcript of session is unavailable -----

--ATG51994.1193902112/mozart.merit.edu
Content-Type: message/delivery-status

Reporting-MTA: dns; mozart.merit.edu
Arrival-Date: Wed, 31 Oct 2007 01:00:00 -0400 (EDT)

Final-Recipient: RFC822; nanog@trapdoor.merit.edu
Action: failed
Status: 5.2.0
Diagnostic-Code: SMTP; 550 5.7.1 message content rejected
Last-Attempt-Date: Wed, 31 Oct 2007 23:59:59 -0400 (EDT)
X-Suppressed-Delivery-Status-Count: 4

--ATG51994.1193902112/mozart.merit.edu
Content-Type: text/plain

No information is available on specific messages.

--ATG51994.1193902112/mozart.merit.edu--