[Asrg] where the message originated (was: DKIM role?) (SM)

[Gordon Peterson]

It is important to remember that many individuals and many small 
companies use personal or "vanity" domain names.

These domain names appear in their "From:" and "Reply-to:" addresses on 
their outgoing e-mail messages, but SHOULD NOT be presumed to indicate 
where the e-mail in question is arriving from.

For example, I might be travelling somewhere and sending e-mail messages 
from an inhabitual location:  a cruise ship Internet cafe, an Internet 
access kiosk above a post office location in Beijing, a coffee bar, or 
other such public-access location.  In such a situation, I will 
typically have NO control over what outgoing mail server is sending my 
e-mail message, and since my being there is temporary I obviously don't 
want to put a return address on my mail that would be connected with the 
location where I physically am at the time.

Another example is where a small company also uses a company domain 
name, although they might use very different mail handling for their 
outgoing staff e-mail messages (for example, which might go through a 
nearby ISP, often for historical reasons) as compared to their 
automatically generated e-mails (example: invoices, price quotations, 
EFT transfer notices, and the like) generated by their back-office 
accounting systems... which might be sent directly by outgoing mail 
servers inside their NAT router.

We've several times been hurt by stupid antispam approaches which refuse 
perfectly legitimate e-mails because they don't like the IP address they 
are coming from.

Another problem we have had is when we were sending company E-mails 
through the outgoing mail server provided by our domain hosting company, 
and one of the (tens of thousands) of companies they were hosting 
domains for apparently became infected and began sending messages 
containing a virus or something.  The result was that ALL the companies 
forwarding through that outgoing mail server became blocked, even though 
our company (and, I'm sure, most of the companies using that same shared 
outgoing mail server) was never infected or compromised.


While we're talking about the issue of antispam nuisances, another is 
the situation where a spam blocker inadvertently serves as an "IP 
address laundering agent" when they bounce back a message detected as 
containing spam, or a virus.  It is particularly stupid to bounce back a 
message because it is detected to contain a virus WHICH IS KNOWN TO 
FALSIFY OR COUNTERFEIT THE RETURN ADDRESS!  In that case, the spam 
blocker sending the 'bounce'/refused message does not know where the 
original message was ACTUALLY sent from;  commonly they will send the 
bounce message to the COUNTERFEIT "from" address (n.b. the address the 
original spammer ACTUALLY wanted to send the message to!) only now, it 
arrives from a "clean" IP address (i.e. the IP address of the antispam 
blocker which "bounced" it) rather than from the IP address actually 
originating the message (which the actually intended recipient might 
have refused, based on the sender IP address).  So now the unwanted 
message arrives at its intended destination, having "reflected" off a 
spam reflector and thus now with a "reputable" IP address.  (True, it is 
now shown as an "undeliverable/spam/virus" bounce, but a lot of people 
DO open such messages).  ...ANYHOW, PARTICULARLY when a message is sent 
by a virus KNOWN to falsify origin addresses, it is NOT helpful to send 
a bounce message back to the "bogus" "origin" address indicated in the 
message.

I have a folder here with probably something approaching a hundred 
thousand such bounces, caused by spam messages which were sent using 
bogus/falsified addresses but counterfeiting one of my domains, and 
where these messages did not originate from any of my systems.  The 
point is that there is NO value in sending back a bounceback/refused 
message unless you are SURE you know where it should be sent back to 
(i.e. who actually sent it).  It's NOT enough to just believe the 
"From:" address.


> Subject: Re: [Asrg] where the message originated (was: DKIM role?)
> To: Anti-Spam Research Group - IRTF <asrg at irtf.org>
> Message-ID: <6.2.5.6.2.20090109113345.030d80d0 at resistor.net>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> At 13:05 08-01-2009, Franck Martin wrote:
>> on 4) for information there is this blocking list:
>> http://www.uceprotect.net/en/rblcheck.php?ipr=202.170.42.206
>>
>> but it tends to block by AS number and in the above case, AS9241 is 
>> the whole country of Fiji.
> 
> That shouldn't be a problem if you don't communicate with people from Fiji. :-)
> 
>> Also as a note, I think dealing with high volume mail sender is not 
>> the issue, they are known, we know their technics, etc... it is more 
>> to deal with the long tail of little companies, organisations, small 
>> ISPs, etc..
> 
> Some receivers may view these small organizations as statistically 
> insignificant.  These small organizations generally adopt antispam 
> policies without analyzing whether such policies can have a negative 
> impact on them in future.
> 
> At 09:44 09-01-2009, Douglas Otis wrote:
>> White-listing based upon a domain would be dangerous without also
>> including the IP address of the SMTP client and message tracking.
>> There are companies currently providing this service, particularly
>> needed where spam remains largely unmanaged.
> 
> The question was whether it is important to note where the message 
> came from.  I take it that your answer is yes.
> 
>> The algorithm can remain oblivious to who owns the SMTP client.  It
>> determines whether a conversation was observed, while also allowing
>> also users to submit corrections.
> 
> That only works as long as the two end-points for the conversation 
> are static.  Such a constraint is only acceptable to users until they 
> move around and experience a communication failure.
> 
> Regards,
> -sm 

-- 

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking