[Asrg] where the message originated

[Gordon Peterson]

 > > 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.

 > That's a hopeless setting. If you carry a laptop, SMTP+AUTH to the
company server is the way to go, as Franck said already.

That's precisely the point.  I am not using my habitual mail client, nor 
am I using my own familiar webmail service.  I am using a mail 
kiosk-type service which allows me to enter a subject, my return 
address, a to address, and the body of my mail.

 > If not, assuming you won't configure an email client, you should use 
company's webmail server.

That's not an option, and nor can I configure what e-mail server is 
being used.

 > You are not going to store your userid/password at an
unknown box, are you?

No, of course not.  And they don't ask for that.  The mail message 
doesn't go out through my normal e-mail channels, and that's just 
exactly the point.

 > Thus, you should connect to your outgoing server
in the same way that you connect to your incoming one.

Again, that's not one of the options available.

When you're travelling on a ship, understandably they want to have you 
send your mail through the ship's own outgoing mail server, since that 
minimizes the time they have to keep the (very expen$ive) satellite 
channel open.

 > > 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.

 > Same comments as above apply. However, for vanity addresses the
company's MX just forwards to each employee's actual address. In that
case, outgoing mail should also originate from each employee's ESP.
The company's SPF record, if any, should take that into account.

And again, that's okay, WHEN THEY ARE MAILING FROM IN-HOUSE.  When they 
are not, is when the problem turns up.

 > The historical ISP habit to allow relaying from their own IP addresses
since clients already authenticated on connecting, has had its day.

That's not really the issue.  The issue is that people occasionally have 
very legitimate need to send mail other than through their normal 
channels, PARTICULARLY when away from the office (at home, perhaps, 
although sending a mail that's work-related;  from a library or airpport 
public access terminal;  at a customer location;  and particularly when 
traveling out of the country.)

 > > 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.

 > Obviously there are the same problems when sharing cars, buildings,
and sex mates: whoever catches accidents or infections affects
everybody else...

In this case, however, the overly-broad-brush of poisoning ALL traffic 
transiting an IP address just because it has sent "some" unwanted or 
malicious mail can create a GREAT deal of serious collateral damage.

 > > 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!

 > Correct. The anti-virus filter should just swallow the message with no
complains nor notices. I don't know what RFC blesses that behavior,
though.

It is very frustrating to get (sometimes hundreds a day) bounce messages 
that come back to my domain (catch-all address mailbox) for e-mail 
messages which *I* NEVER SENT, just because the spammers' From: address 
used a counterfeit/bogus e-mail address forging one of my domains.


-- 

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