|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: J.P. Trosclair (jptrosclair
judelawfirm.com)
Date: Tue Dec 02 2008 - 13:57:54 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Roman Medina-Heigl Hernandez wrote:
> DJ Lucas escribió:
>>> Return-Path: <bounces
canonical.com>
>>> X-Original-To: roman
rs-labs.com
>>> Delivered-To: roman
rs-labs.com
>>> ...
>>> Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
>>> by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
>>> for <roman
rs-labs.com>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
>>> From: RoMaNSoFt <roman
rs-labs.com>
>>>
>> Maybe I'm incorrect, but I believe there was a subtle misunderstanding
>> in the above conversation. The From: header is not the same as MAIL
>> FROM: command in smtp transaction. MAIL FROM for this message was
>> bounces
canonical.com. Feel fee to find that message in your logs and
>
> Thank you for the correction, you are right: my example is wrong but that
> doesn't change the fact we were discussing since Noel and I were always
> referring to the "mail from" (i.e. the sender). If some silly ticket system
> spoofs the "From" header, there is a good chance that it spoofs the "mail
> from" too...
>
>> verify. Anyway, the Postfix directive you are looking for is
>> "reject_unauthenticated_sender_login_mismatch".
>> http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
>
> Yes, I think that's the directive I was looking for.
>
>> That said, cheap web scripts often do use the recipient's address in the
>> transaction. Latest complaint I had was from some star rewards thing
>> for frequent visits to a restaurant (for which I promptly replied:
>> "choose a different restaurant" ;-) ).
>>
I have been working on a similar if not the exact same problem from what
I've seen in this thread. The problem being from = to address and how to
stop spam that does this. My idea for a solution to this problem was to
require any mail claiming to be from a local account to authenticate
first when arriving from outside of the network and heading to a local
mailbox. As it has already been pointed out, there are cases where you
have false positives, in fact I found one yesterday with a user's
blackberry setup shortly after I set it up. I'm thinking that utilizing
check_client_access before check_sender_access under
smtpd_recipient_restrictions and adding exceptions for these few cases
is a sound solution. It's obviously not perfect because of the
administration overhead of having to watch for these special
circumstances. I have yet to test this. Any thoughts on this approach?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]