On Mon, Jul 08, 2002 at 08:49:47AM -0400, Andrew Kohlsmith wrote:
| > | OT: is it possible to add a configuration option which lists the domain
| > | mailservers and their IPs?  And add a test which scores rather highly for
| > | mail claiming to come from domain.dom but which isn't actually from one
| > | of the mailservers for domain.dom?
| >
| > This belongs at the MTA level, if it belongs at all.  How about this:
| >
| >     You legitimately find a copy of my old/other email address (for
| >     example you read exim-users and reply to one of my posts).  You
| >     send me a message at that address, which is From: your domain.  My
| >     MTA sees it coming from the server pony-express.cs.rit.edu
| >     because that's where the .forward is that redirects that address
| >     to my real/current address.
| 
| I'm not sure I understand how that trips this test.

Then add in a forwarding (in my .forward file) of the message to
some user at your domain.  That would complete the cycle.

(the forwarding could even be conditional; for example if I use an
exim filter in place of a traditional .forward)
 
| Now I can see how you might have a dialup roadwarrior using an AOL account or 
| something and have his email client set up to have his From: come from 
| @newdomain.dom, but that is an incorrectly set up MUA, IMO.  It should be 
| saying from [EMAIL PROTECTED] with a Replies-to: header, should it not?

That is a choice for the roadwarrior and his employer and his
provider.  IMO replacing the From: with another legitimate address of
yours is quite acceptable, even if the message isn't sent out from a
machine in that domain.  If it is yours, can't you do what you want
with it?  It would be like mailing a letter to someone while you're on
vacation and putting your home address in the "from" field.

It is possible for the company to configure SMTP AUTH to allow the
off-site employeed to send mail out through their server, in which
case the From: domain, the envelope sender, and the server would all
match.  It isn't essential, though, if they don't mind having AOL (or
whatever) in the Received: headers.

However, ISTR that AOL doesn't allow their dial-up users to make
connections to port 25 on any machine other than their own server.  It
is an additional complication for both the roadwarrior and his
employer to work around, and it may be that some systems don't allow
the user to specify an alternate port for the SMTP connection.
 
| > Not to mention one of your users could have his mail forwarded
| > off-site, and then forwarded back in.
| 
| The From: in that case should not be the original address.  Forwards
| should alter the From, redirects should not.

If it was forwarded using a .forward file, neither the From: header
nor the envelope sender would change.  If a person later "bounces"
(mutt term) the message, then the envelope would be that person while
the From: header would be the original one.

| > That's the problem with whitelists.  It is easy enough to forge the
| > "From:" sender.
| 
| Which is why I'm trying to help.  :-)

It's easy enough to forge everything except for the RCPT and the IP
address that the remote MTA is connected (to yours) from.

Keep trying to help, though :-).

-D

-- 
 
A perverse man stirs up dissension,
and a gossip separates close friends.
        Proverbs 16:28
 
http://dman.ddts.net/~dman/

Attachment: msg07130/pgp00000.pgp
Description: PGP signature

Reply via email to