[Asrg] where the message originated

[Alessandro Vesely]

Gordon Peterson wrote:
> 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. If not, 
assuming you won't configure an email client, you should use company's 
webmail server. You are not going to store your userid/password at an 
unknown box, are you? Thus, you should connect to your outgoing server 
in the same way that you connect to your incoming one.

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

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

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

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