> > 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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg