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

From: Franck Martin <[email-masked]>
Date: Sun, 11 Jan 2009 16:03:52 +1200 (FJT)

In my experience, people are not able to modify their software to change the default smtp server. It seems more efficient to have them connect back via SMTPS+AUTH to the company mailserver and send their email that way.

Now, some webmail providers allows you to haev multiple reply-to address, that you use depending on your location. This is nice but then we fall in the categories listed below, and I'm not sure that DKIM provide a meaningful authentication of the reply-to address. 

----- Original Message -----
From: "Gordon Peterson" <[email-masked]>
To: [email-masked]
Sent: Sunday, 11 January, 2009 3:18:34 PM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM)

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.

_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Franck Martin <[email-masked]>
Date: Tue, 20 Jan 2009 08:37:09 +1200 (FJT)

Banks use credit card which have been proven weak.

They compensate by insuring you against fraud and having a big legal department that follow the cases. That's if the bank is respectable, but they are becoming less and less..

Before you would go to a bank because they projected trust and reputation, now you have to go to the bank if you want to buy anything. Many online commerce appply filtering rules based on credit card location, IP location, and other hidden mechanism. But that's a discussion for another forum.

My point is that solving email authentication, may not solve real world problems.

----- Original Message -----
From: "der Mouse" <[email-masked]>
To: "Anti-Spam Research Group - IRTF" <[email-masked]>
Sent: Tuesday, 20 January, 2009 7:44:24 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM)

> Have you actually looked at the mail from your bank?

Thank you for explaining so clearly why I do not, ever, do anything
"online" with my bank.  (Makes it really easy to identify phishes. :)

Now, if they were to sign the mail with some content mechanism like PGP
or S/MIME, with the key available by going to the branch in person, I
might trust it.

More likely not, though, since I've seen enough over my bank's
personnel's shoulders to convince me they run Windows internally, so I
don't trust them to manage their private key data properly either.  (Of
course, if they got enough clue to start doing real signatures on
email, they might also grow a clue when it comes to managing their
internal systems.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg