TCPIP V5.4 ECO 5 SMTP Symbiont-Checks-Deliverability is broken.

[Steven Schweda]

In case anyone has missed the discussion in
comp.os.vms:

"Symbiont-Checks-Deliverability: FALSE" was a
great idea (with a lousy name), but it doesn't
work properly.

rcpt to: twelve_chars@antinode.org
550 < twelve_chars@antinode.org> ... Addressee undeliverable

Fine, but:

rcpt to: thirteen_chrs@antinode.org
250 < thirteen_chrs@antinode.org>... Recipient OK

rcpt to: abc-def@antinode.org
250 < abc-def@antinode.org>... Recipient OK

and so on.

Thus, many invalid Recipient names are
considered "OK", and so lots of junk e-mail
bounce messages (which should be blocked) get
through.

This is a particularly troublesome problem
when a drug dealer with a Korean Web site uses
(forges) your domain name in promotional
e-mail, resulting in more than 1000 such
bounce messages per hour, of which a few
hundred per day are delivered because they
contain user names like gremilliohlenadit and
02060607211952.

[Ian Miller.]

has this been reported to hp and, if so, what did they say?

[Steven Schweda]

Hobbyist license. No support beyond whining in
forums like this. If I hear anything useful on
comp.os.vms, I'll pass it along (as needed).

[John Gillings]

Steven,

I'm not sure I understand your description. Are you saying that the test only works for 12 character user names? with underscores, or hyphens?

What/where is "antinode.org" relative to your system? Is it a real domain?

Could you please describe exactly what operations are being performed (sender, relay, target) the results you're getting, and the results you're expecting.

Any characterisation of false positives and/or false negatives?

[Steven Schweda]

All the test names are invalid, in the sense
that they are not actual users, so they
should all be rejected. Some are being
accepted.

What I know is that the test fails for names
longer than 12 characters, and for some set
of other names which would not be valid VMS
user names. I have seen no cases where a
valid name is wrongly rejected (but I might
easily miss that).

My problem is a large set of junk e-mail
bounces which are being wrongly accepted
because the name test appears to accept some
invalid names, instead of rejecting them.
Names longer than 12 characters are the
actual trouble now, but it appears that
other bad names will also be accepted.

Antinode.org is real, and its address is
where the mail goes. The tests were run
from a (Solaris) system at my ISP:

telnet antinode.org 25
helo fred
mail from: fred@antinode.org
rcpt to:
[...]
quit

For example:

rcpt to: fredfred
550 < fredfred> ... Addressee undeliverable

rcpt to: fredfredfredfred
250 < fredfredfredfred>... Recipient OK

and so on. There is no user fredfredfredfred
here, so it should be undeliverable, not
"OK".

I have no access to the source, so I may be
wrong when I assume that a quick look at it
will trigger a response like, "Jesus! What
a moron?!". It appears that VMS-valid names
are tested properly, but that VMS-invalid
names (such as long ones) are always
accepted.

If you need hundreds of examples, just send
e-mail to "sms" at the obvious domain.

One other class of bad names appears to be
the result of junk distributors gleaning
message ID values (from e-mail headers which
appear on the Internet in news-group
postings, or whatever) and thinking that
they're e-mail addresses. A typical one
looks like:

Message-Id: <99060822592298@antinode.org>

The gleaners see "something@domain", assume
that it's an e-mail address, and then try to
send it junk e-mail. Because the number is
longer than 12 characters, these are also
not properly rejected.

This stuff really should be tested on a
system like mine, which is exposed to the
real world. Whatever testing is done
internally appears to be insufficiently
hostile.

[John Gillings]

Steven,

In the initial implementation, it was decided to err on the side of *allowing* mail, rather than blocking it. So, unless the code could positively prove that a particular address was invalid, it would allow it. The assumption was that blocking a message that should be allowed is worse than not blocking a message that shouldn't.

Thus, all cases where the target username is a valid VMS username can be resolved, others cannot, so they're let through.

When you upgrade to TCPIP V5.5, you'll find the logic has been reversed. Only addresses than can be proved to be deliverable are permitted. The thinking now is that anything that isn't obviously deliverable is probably spam and should be blocked.

This risks bouncing mail that might be deliverable. The risk appears to be very low, but there might be some bizzare sequence of logical name translations that make a name valid, but fail the tests done by SMTP. If any users find this, the answer is to disable the deliverability test or wean themselves off weirdo mail routing.

So your solution is to upgrade to TCPIP V5.5. Put another way, this problem is fixed by a patch to V5.4 - it's called V5.5 ;-)

[Steven Schweda]

It's good to know that TCPIP V5.5 fixes this,
but a fix for V5.4 would be nice, for, as I
read it, V5.5 drags a bunch of other things
with it, like VMS V8.2, where (I hear)
AppleTalk is broken, for example.

This looks like a good place for a user choice
rather than a supplier choice. Perhaps some
users would prefer the old behavior (although
it seems unlikely to me). Better documentation
would also have helped.

I suppose that there's no chance of just
stealing one .EXE from the new kit to get the
desired repair?

[John Gillings]

>I suppose that there's no chance of just
stealing one .EXE from the new kit to get the desired repair?

Short answer - no.

Longer answer - Changes and new features are what new versions are for. Patches just fix bugs. The previous behaviour was valid, just not what you wanted.

On the other hand, you're free to extract whatever images you like from whatever kits you want and see if they play together. Just don't complain if it doesn't work!