[discuss] SPAM originating from linux.ca

[Mike]

Besides all the SPAM from ***@linux.ca I've been seeing a lot from
***@linux.ca and ***@linux.ca.

X-Message-Delivery: Vj0xLjE7dXM9MDtsPTA7YT0wO0Q9MjtTQ0w9Ng==
X-Message-Status: n:0
X-SID-PRA: ***@linux.ca
X-Message-Info:
6sSXyD95QpU1XSm7Yg7eCUDr4fsoxrdC3bEHFKMEn61tPsVgGkhT2px8sKrDuVtrs2zDsb4nzEqxO5EaD1bhzab1ByfvYqxD
Received: from tomts23-srv.bellnexxia.net ([209.226.175.185]) by BAY0-PAMC1-
F6.Bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
???????? Fri, 15 Jan 2010 06:07:08 -0800
Received: from toip28.srvr.bell.ca ([67.69.240.30])
? ? ? ? ? by tomts23-srv.bellnexxia.net
? ? ? ? ? (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP
? ? ? ? ? id <20100115140707.BXYA26340.tomts23-
***@toip28.srvr.bell.ca>
? ? ? ? ? for <***@sympatico.ca>; Fri, 15 Jan 2010 09:07:07 -0500
Received: from toip15.srvr.bell.ca ([67.69.240.17])
? by toip28.srvr.bell.ca with ESMTP; 15 Jan 2010 09:07:00 -0500
Received: from harwood.rhpcs.mcmaster.ca (HELO mail.linux.ca)
([130.113.54.214])
? by toip15.srvr.bell.ca with ESMTP; 15 Jan 2010 09:07:00 -0500
Received: by mail.linux.ca (Postfix)
????????id 53697C43A; Fri, 15 Jan 2010 08:58:18 -0500 (EST)
Delivered-To: ***@linux.ca
Received: from ZURGOLN (unknown [221.147.221.120])
????????by mail.linux.ca (Postfix) with ESMTP id D7E75C441;
????????Fri, 15 Jan 2010 08:58:17 -0500 (EST)
Received: from 221.147.221.120 by 72.4.117.22; Fri, 15 Jan 2010 23:06:16
+0900
Message-ID: <000d01ca95eb$e71ab1e0$***@turmoilbw7800>
From: ***@linux.ca
To: <***@linux.ca>


Is linux.ca still actively maintained?

[Russell McOrmond]

A little bit of information, and then hopefully into a discussion.

These messages are not likely 'from' @linux.ca addresses. One of the
things that spammers like to do is send a message as being from 'kbs'
without any domain name. The message then passes through a relay like
@linux.ca which presumes this is a local user and automatically adds the
@linux.ca.

Other servers may do something different and check the originating IP
address of a message and instead of adding the domain name may drop or
bounce the message (presuming it is SPAM if a message with an invalid
from address comes from an IP address that is not in the local LAN).

The spammer may also just be forging other known-good @linux.ca email
addresses as yet another way to get pass any filters that may exist.
The @linux.ca mail relay could be checking local tables for valid local
email addresses before forwarding it onward.

So, the point here is to note that just because it has @linux.ca in
the envelope-from or From: headers does not mean that it was originating
from an @linux.ca address, but that it may have been destined to an
@linux.ca address.


Now the discussion: Is having an @linux.ca relay a useful thing?

More and more anti-SPAM measures are being deployed on various sites.
One that is slowly (too slowly in my mind) growing is Sender Policy
Framework http://www.openspf.org/

What this does is check the envelope-from of a message and verify
whether the message came from a mail relay that is valid to have
messages from that domain name. This makes spoofing the envelope-from
much harder, and allows at least this aspect of the address to be
verifiable.

One of the side-effect is that this breaks simply mail redirection
services such as @linux.ca

Say I send a message from my @flora.ca email address to someone
@linux.ca who has their email forwarded to gmail.

My @flora.ca domain name has SPF records which specify which IP
addresses are valid.

http://old.openspf.org/wizard.html?mydomain=flora.ca


If @linux.ca checked the SPF record, all would be good and it would
accept the message.

The message is then forwarded to gmail.com which is known to check
the SPF record. The envelope-from is still me with my @flora.ca email
address. Gmail looks up the IP address of where the message came from
(now mail.linux.ca which has address 130.113.54.214 ) , and rejects the
message as it considers the message likely to be spam or otherwise
forged headers.


While there are a variety of techniques for forwarding messages that
include munging the envelope-from information, I've not seen one that
handles forwarding such that bounce messages manage to get back to the
right person as well. This is a non-trivial problem where each
solution has its own problems.


In essence the best thing to do is to consider the concept of email
forwarding systems like @linux.ca to be dead. Domains should be
attached to mailboxes, and if you want an @linux.ca email address you
should be expected to have an @linux.ca mailbox and not be attempting to
forward that message elsewhere. It should also presume that outbound
messages with an @linux.ca address would be sent to mail.linux.ca
directly and not attempted to be relayed through your local ISP.


There are ways for techies like those who would want an @linux.ca
address to get around these issues. Having something like Fetchmail
automatically pick up your @linux.ca email and deliver to some other
mailbox would avoid you having to pick up your @linux.ca email
separately. This would still mean, however, that @linux.ca would no
longer be a mail forwarding service but an actual mail service with
mailboxes.


Thoughts? Even though I am part of the executive for CLUE I dropped
my ***@linux.ca email address long ago. I've set things up such
that it bounces and sends back a message indicating my real/primary
email address.

[Bob Jonkman]

This strikes close to home. I'm using e-mail completely conformant to
the IETF specifications of RFC5321 &c. to run a number of relaying
services for clients, mostly for branding or vanity accounts. In my own
case, for example, I have only one mailbox, ***@sobac.com but a
number of e-mail addresses. Some are aliases for the same mailbox (ie.
the domain's MX points to the same mail server); others are relays (ie.
***@jonkman.ca goes to the jonkman.ca server, which relays
***@jonkman.ca to ***@sobac.com

Admins who reject relayed mail are free to do so, but at the risk of
greatly increasing the number of false positives for properly relayed
mail. Delivery failures are the result of policies set by the
recipient, not through any fault of the sender.

SPF, DKIM, blacklists and PKIs are useful things, but are only one
element of reputation management. These tools should be used as a
weighting for ranking the reputation of the sender, or the spamminess of
mail. It is a mistake to reject mail simply because someone else says so.

Anyone relying solely on external, third-party automated tools are
essentially granting those third parties the ability to censor their
incoming mail.

Yes, doing mail relaying properly is tough, but that's why we get paid
the big bucks. (if only...)

--Bob.

Bob Jonkman <***@sobac.com> http://sobac.com/sobac/
SOBAC Microcomputer Services Voice: [phone]
6 James Street, Elmira ON Canada N3B 1L5 Cel: [phone]
Software --- Office & Business Automation --- Consulting

Post by Russell McOrmond
A little bit of information, and then hopefully into a discussion.
the things that spammers like to do is send a message as being from
'kbs' without any domain name. The message then passes through a
Other servers may do something different and check the originating
IP address of a message and instead of adding the domain name may drop
or bounce the message (presuming it is SPAM if a message with an
invalid from address comes from an IP address that is not in the local
LAN).
email addresses as yet another way to get pass any filters that may
valid local email addresses before forwarding it onward.
the envelope-from or From: headers does not mean that it was
More and more anti-SPAM measures are being deployed on various
sites. One that is slowly (too slowly in my mind) growing is Sender
Policy Framework http://www.openspf.org/
What this does is check the envelope-from of a message and verify
whether the message came from a mail relay that is valid to have
messages from that domain name. This makes spoofing the envelope-from
much harder, and allows at least this aspect of the address to be
verifiable.
One of the side-effect is that this breaks simply mail redirection
@linux.ca who has their email forwarded to gmail.
addresses are valid.
http://old.openspf.org/wizard.html?mydomain=flora.ca
accept the message.
The message is then forwarded to gmail.com which is known to check
address. Gmail looks up the IP address of where the message came
from (now mail.linux.ca which has address 130.113.54.214 ) , and
rejects the message as it considers the message likely to be spam or
otherwise forged headers.
While there are a variety of techniques for forwarding messages that
include munging the envelope-from information, I've not seen one that
handles forwarding such that bounce messages manage to get back to the
right person as well. This is a non-trivial problem where each
solution has its own problems.
In essence the best thing to do is to consider the concept of email
to forward that message elsewhere. It should also presume that
mail.linux.ca directly and not attempted to be relayed through your
local ISP.
address to get around these issues. Having something like Fetchmail
longer be a mail forwarding service but an actual mail service with
mailboxes.
Thoughts? Even though I am part of the executive for CLUE I
up such that it bounces and sends back a message indicating my
real/primary email address.

[Russell McOrmond]

Post by Bob Jonkman
Admins who reject relayed mail are free to do so, but at the risk of
greatly increasing the number of false positives for properly relayed
mail.

This is a key part of the discussion. Some admins believe that the
simple forwarding method (just rewrite the envelope-to) should only be
used within a LAN network, and never relayed back into the external
Internet. They don't consider this rewriting to be "properly relayed mail".

Then there is the question of how many forged messages are blocked
compared to valid. I don't know if there is really a large number of
sites doing simple envelope-to rewriting delivered to foreign mailboxes
compared to the number of messages with forged envelope and other headers.


There are other reasons this forwarding system fail. Here in Ottawa
there was at one time many people using domain names I hosted (I even
did email forwarding and website hosting commercially at one point) that
had mailboxes on Magma.ca. Magma was using an anti-spam system that
would delay messages being relayed from a specific IP address based on
SPAM messages originating from that IP. I found my mail*.flora.ca
servers often on a very large delay, and unable to send emails to
customers that could be relayed within a 24 hour period, because of
messages that Magma's filters considered SPAM. My first action was to
disallow Magma mail servers to be a destination for these forwarded
domains -- and this was long before SPF started to become popular.


I think in the longer term that simple envelope-to rewriting will be
dead, whether some admins like it or not. The question is whether we
should keep @linux.ca the way it is currently configured and let people
slowly leave as it increasingly fails, or start conversations towards
some future (mailboxes, double-envelope-rewriting, don't offer email
address to other than executive/volunteers, etc).

Post by Bob Jonkman
Delivery failures are the result of policies set by the
recipient, not through any fault of the sender.

While true, most recipients are as unaware of the issues as the
senders, and unaware that they misconfigured their email. I've seen
threads on many sites where a recipient insisted the problem was with
the sender because "messages from other people seem to get here without
a problem"...

While @linux.ca may be different as we expect people to be more
technical, the majority of people using Email these days can't decipher
a bounce message to save their life.

Post by Bob Jonkman
Anyone relying solely on external, third-party automated tools are
essentially granting those third parties the ability to censor their
incoming mail.

I don't see how this applies here. Google deleting @flora.ca emails
that don't come from the IP addresses I have specified are doing so
because I, the owner of @flora.ca, have asked them to. There is no
censorship here as it is simply adhering to a request from the author.

Post by Bob Jonkman
Yes, doing mail relaying properly is tough, but that's why we get paid
the big bucks. (if only...)

I want to ensure we are focused on talking about mail forwarding, not
mail relaying. If this message were just being relayed by a legitimate
MX host for the destination domain, then there would be no issues.
mail.linux.ca is not a legitimate MX for mail destined to @gmail.com.