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" <gep2(_at_)terabites(_dot_)com>
To: asrg(_at_)irtf(_dot_)org
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
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg