Neezam Haniff writes on 12/1/2003 1:46 PM:

On Mon, 1 Dec 2003, Suresh Ramasubramanian wrote:

...

So this would connect to the MX of gerbangmail.com and try to verify that whatever@gerbangmail.com exists.

Out of curiosity, would you know offhand how they do the validation?

It is my job to know, I guess ... as other people's jobs here are to know which routes are flapping where. Mail filtering policies at an ISP can have quite unintended consequences on mail delivery from other ISPs. Especially ISPs that have a huge number of users with .forwards set to Verizon mailboxes. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

In message <10021859.1070281409@d216-220-25-60.dynip.modwest.com>, Michael Loft is writes:

I personally haven't seen ANY validation, just an arbitrary block that's been in place for over a month without cause, reason, or even any ability to contact them.

Right. Assuming that the described validation scheme is, in fact, what's being used, you'd expect Verizon's mailer to retain and cache the validation. That way, a single 450 can be turned into a 200 series or a 550. As Randy said, 450 means "there's a problem here that should be fixed soon; come back later". If it doesn't change, it's not a 450. --Steve Bellovin, http://www.research.att.com/~smb

...

is the following a general problem, or just one i am seeing?

Verizon does SMTP callbacks, connecting back to the MX of the envelope sender and trying to verify that the user exists

...

2003-12-01 10:09:05 1APbBa-000Ork-DY == foo.user@verizon.net <foo@psg.com> R=lookuphost T=remote_smtp defer (0): SMTP error from remote mailer after MAIL FROM:<nikkiadamczyk@gerbangmail.com> SIZE=5365: host relay.verizon.net [206.46.170.12]: 450 Requested mail action not taken-Try later:sc004pub.verizon.net

So this would connect to the MX of gerbangmail.com and try to verify that whatever@gerbangmail.com exists.

gerbangmail.com. 5h55m6s IN MX 0 sitemail.everyone.net.

If the MX (sitemail.everyone.net) doesn't respond fast enough for verizon, their tester times out, and the message gets 4xx'd.

interesting but utterly irrelevant. the question was not how verison decided it was spam. the point was that their server returned a 450 as opposed to a 5xx (550 looks good), and this causes net damage. randy

On Mon, Dec 01, 2003 at 10:50:51AM -0800, Randy Bush wrote:

...

...

is the following a general problem, or just one i am seeing?

Verizon does SMTP callbacks, connecting back to the MX of the envelope sender and trying to verify that the user exists

...

2003-12-01 10:09:05 1APbBa-000Ork-DY == foo.user@verizon.net <foo@psg.com> R=lookuphost T=remote_smtp defer (0): SMTP error from remote mailer after MAIL FROM:<nikkiadamczyk@gerbangmail.com> SIZE=5365: host relay.verizon.net [206.46.170.12]: 450 Requested mail action not taken-Try later:sc004pub.verizon.net

So this would connect to the MX of gerbangmail.com and try to verify that whatever@gerbangmail.com exists.

gerbangmail.com. 5h55m6s IN MX 0 sitemail.everyone.net.

If the MX (sitemail.everyone.net) doesn't respond fast enough for verizon, their tester times out, and the message gets 4xx'd.

interesting but utterly irrelevant. the question was not how verison decided it was spam. the point was that their server returned a 450 as opposed to a 5xx (550 looks good), and this causes net damage.

I think he's saying that they were unable to perform the validation hence the 450. If the validation was successful, they'd return a 200 series code, if it was unsuccessful, they would return a 500 series code. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Mon, Dec 01, 2003 at 11:10:16AM -0800, Randy Bush wrote:

...

I think he's saying that they were unable to perform the validation hence the 450. If the validation was successful, they'd return a 200 series code, if it was unsuccessful, they would return a 500 series code.

nice words, but crap. due to needs to spool mail for sites in countries with very poor connectivity, mail spool time here is quite long. if verizon and others seem unable to decide in weeks, why should i pay the penalty?

you should likely queue those other countries on a seperate machine dedicated to that purpose. this way one user/host site doesn't unduly cause significant impact to other sites/users. it's interesting you view the interpertation (which at least one other person views as correct) as "crap". this behaviour does seem to fit strict interpretation of the rfc in question.

but, i guess the problem is easily solved with exim config. i have set it so that if it can not deliver to verizon in say one hour, it dumps the mail.

verizon.net * F,1h,5m

life is simple, except for verizon users i guess.

this is the ability of a single host operator to make their own local policy decisions. you've both done what you feel is appropriate. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On 1 Dec 2003, at 14:29, Randy Bush wrote:

...

this is the ability of a single host operator to make their own local policy decisions.

which leads to the heat death of the net

or allows the net to prosper, since policy is distributed rather than centralised.

On Mon, 01 Dec 2003 14:51:01 EST, Joe Abley said:

or allows the net to prosper, since policy is distributed rather than centralised.

Tell anybody who suffered through 69/8 how that was an example of the net prospering.

(susan, this is in a spam related thread but i'm adding offtopic remarks which i think are actually in-charter for nanog. --pv)

Verizon does SMTP callbacks, connecting back to the MX of the envelope sender and trying to verify that the user exists

while something like RMX or MAILFROM would probably be a more robust alternative, verizon's actions are not irrational on a purely cost:benefit basis when the costs and benefits being measured are only their own. however, cost and benefit are not isolatable in that way, and folks who try to isolate them end up causing others to pile workaround on top of workaround until the whole system is just gum and mud. if verizon wanted to jointly sponsor a clearinghouse of email senders who had passed the callback test, with appropriate caching and error analysis and robust global mirroring, i'm sure that there would be other isp's and large e-mail carriers who would want to help, and i'm sure that authors of mail software, both opensource and not, would want to offer the feature of checking such a "ephemeral sender whitelist" (ESW?) but as long as verizon acts alone, they're just hurting themselves, and the overall system. consider what would happen if everybody did callbacks; first, what would happen to the load on the world's nonabusing mail servers, and then, what would the spammers do in response if this was effective? -- Paul Vixie

telling spammers 4xx or 5xx doesn't matter, they don't listen. On Mon, Dec 01, 2003 at 09:18:21PM +0100, Daniel Roesen wrote:

On Mon, Dec 01, 2003 at 12:52:28PM -0700, Michael Lewinski wrote:

...

The idea is to "punish" spammers by filling up their queues, although honestly I don't know of any spammers who actually *have* queues. They just borrow other people's of course.

Correct. More and more, anti-spammers are annoying me more than the spammers. Anti-spammers tend to "make my problem YOUR problem" thinking. Be it mangled sender addresses (this "NOSPAM" nonsense), be it 450 to suspected spam.

Antispanners seem to be very easy in accepting collateral damage to the net.

Regards, Daniel

Exactly this is the flawed point about returning 4xx. They produce only collateral damage, but don't hit their target at all.

but they can feel self-righteous, which is probably the major goal