At 16:20 -0500 2003/01/04, James P. Roberts wrote:
>I doubt it would block any of my customers; but, it is best to make
>sure.
>
>>From the 4.x online manual:
> sender_domains = <domain list>
> This condition tests the domain of the sender of the message against
>the given domain list.
>
>What exactly defines the "domain of the sender of the message"? Is it a
>translated IP address (DNS lookup?), or is it simply taken "as is"
>(text) from a header? Which header is it taken from? Is it the "From:"
>or the sequentially first "Received: from" header? Or something else?
>(Sorry, I'm not much of a C-code reader.) My guess would be, it is
>simply taken from the "From:" header.
no, as it would not be available at the RCPT phase. It is the domain
of the argument of the MAIL command (MAIL FROM: user@domain)
>If it is, there should be no problem, because when my customers relay
>their email through my server, (authenticated, of course), I re-write
>the headers so that it is correctly indicated as coming from the
>customer's domain (which I am hosting). As far as I know, the
>"sender_domains" should then show up as their own domain, rather than
>the domain of whatever AOL-dialup PC they might have connected to the
>internet from. (Please see sample headers below).
if they are not setting their return address (the argument of the
MAIL FROM:) to an aol address, then they will not be catched by one
of these "AOL forgery" filters).
>If I understand it correctly (and I may not, please let me know), then
>your ACL should NOT block any of my customers. (Yay!) This is one of
>the reasons I do the headers re-write. (The main one being, my
>customers are paying for a domain name, and they want their emails to be
>seen as coming from that domain, not from mine.)
this is not clear. I can set the MAIL FROM: to anything, it has
nothing to do with headers rewrite: it depends on the client
software. In some cases it is necessary to do headers rewrite, if the
client software does not allow to set the Return address
independently of the username and host used for the authentication.
Also, even in this case, a silly X-Sender header will reveal the real
identity of the sender, I just nuke that header (and X-X-Sender, set
by pine).
>On the other hand, if "sender_domains" is somehow extracted from the
>"Received:" headers, (which I hope it is not), then your ACL might,
>indeed, block someone that it should not.
The Received header is the least reliable, it can be forged by a child.
[...]
>
>Return-path: <lransom@???>
>Envelope-to: punster@???
>Delivery-date: Wed, 18 Sep 2002 08:27:05 -0400
>Received: from [63.121.118.244] (helo=hppav)
> by puns01.punsterproductions.com with asmtp (TLSv1:RC4-MD5:128)
this is the crucial point, if I had received that email (and it had
not be authenticated) I would have rejected it.
This is a point that many administrators take lightly, the host must
identify itself with its hostname, not just a made up name.
I imagine your clients will look from outside as:
Received: from h-64-105-159-234.phlapafg.covad.net ([64.105.159.234]
helo=puns01.punsterproductions.com)
by exim-colo-01.whoc.theplanet.co.uk with esmtp (Exim 3.34 #5)
This is acceptable to me as nslookup puns01.punsterproductions.com
gives 64.105.159.234.
Anyway, my opinion is that all these DATA phase recipes leave a lot
to be desired (they do not save bandwidth for one), and, as you can
see from my email on DATA deny and hotmail of yesterday, can give
some dodgy delivery failure messages with some dodgy servers...
Giuliano
--
H U M P H
|| |||
software
Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/
