Matt Kettler wrote:
Philip Prindeville wrote:
Matt Kettler wrote:
Philip Prindeville wrote:
Matt Kettler wrote:
Philip Prindeville wrote:

Depends on whether you equate bare domains with URL's, I suppose.
If MUA's equate them with URLs, spammers will use this, and SpamAssassin will use it.

There is only so much braindeath in UA's that you can bend the rules for. Clearly, this involves breaking them.
Erm.. What rule does this actually break? Is there a rule in an RFC somewhere specifying you MUST not interpret bare domains as URIs in text emails?

There is an RFC that defines what a URL looks like. A bare domain doesn't cut it.
Yes, but there's nowhere that says you can't interpret any text you want as a URL.

RFCs in general are interpreted with "be strict about what you generate, and liberal with what you accept". URLizing text segments fits with that spirit, and it does not violate the letter of any RFC I'm aware of.

There are lots of caveats to this rule, and security is certainly one region where you'll find being "liberal what you accept" to be antithetical.


If you can prove otherwise, please do so.

You want to forbid bare domains in email? Go ahead. You can forbid anything you like.

But don't call it a test for URL's, since it's clearly not.
Well, they don't.. they call it a test for URIs, which is actually slightly different, but not really to the point here.

However, in general, it is intended to be a "test for anything most MUA's will interpret as a URI".

Ok, conceded. So the fix is to stop the UA's broken behavior, so we don't have to copy it.



Besides, when this "braindeath" is more the norm than the exception, it's a de facto standard. Particularly in the absence of any rules against it.

Yeah, I'll talk to the Outlook folks, and file a bug against Thunderbird... (I think the latter only does it to be compatible with the former...)
I'd venture to guess neither started it. Eudora predates both products by quite an extensive period of time. It could have originated there, or in Netscape mail.

Sorry, but I highly doubt you can blame this on microsoftism, nor do I think it's any kind of wild incorrectness as you so strongly postulate. This has been a very standard feature in email for a very long time. It's not a recent development.

Long standing hardly equates to "correct". If that were the case, day-one bugs would never get fixed. :-)



It's also a feature that is quite important to accuracy in spamassassin. Spammers regularly take advantage of MUA's urlizing text. Regularly.. Every day. Adding the ability to detect those domains increases SA's hit rate for spam, and that's a good thing. Yes, it causes SA to trigger on spam reports, but it generally will do that for other parts of spam messages anyway.

Let's face it, your problem isn't with SA detecting a spam domain, it's with some idiot filter/rejecting their abuse box.


Not at all.

A lot of spam uses constructs that aren't well-formed according to standards. Like broken "Date:" lines.

I'm happy to reject email that can't get something simple as a Date: line correct.

If Kintata (or whatever it's called) emails get bounced, I'm fine with that. Maybe it will light a fire beneath them to get it fixed. They're in the minority anyway.

Same applies to interpreting URI's.

I'd rather suffer a few broken applications, or in this case, a user having to cut a domain name out of an email and paste it into a web browser and not be able to simply "click through" the message body, if it helps maintain the clear distinction between well-formed messages and gray area ham/spam.

-Philip

Reply via email to