[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SPF and senderokwithdns

Are you really that worried about what your clients are sending?  I get a little nervous about changes to this side of things since its what stands between ending up on someone's RBL vs. lots of unhappy clients because their outgoing mail won't work!

Perhaps we need a configuration option to indicate how much trust we give AUTH/WHOSON clients.  E.g. add something like trust-whoson-withdns to force an early address verification.  In this way, trust-whoson continues to work as it does today, but trust-whoson-withdns works as Eugene suggests.

-----Original Message-----
From: Mariano Absatz [mailto:zmailer@lists.com.ar]
Sent: Tuesday, July 13, 2004 7:50 AM
To: ZMailer Mailing List
Subject: Re: SPF and senderokwithdns

El 13 Jul 2004 a las 8:55, Eugene Crosser escribió:

> On Tue, 2004-07-13 at 14:36 +0300, Matti Aarnio wrote:
>>> with your today's change, senderokwithdns check in pt_mailfrom is the
>>> very last, and it is not done if the sender is "authorized".  Is it what
>>> was your intention?  I think that if one wants to disallow unroutable
>>> "mail from", he wants to do that for all, authorized and non-authorized
>>> senders.  And therefore the check should be done very early, maybe even
>>> before "if (state->full_trust) return 0;" around the line 1704.
>> It is a wee bit complicated thing indeed..
>> When the matter is about remote SPF publisher, who want to be
>> protected, then things are as you say,  but when it is about
>> _local_ SPF set, then e.g. users must be able to send out
>> from where-ever they are, as long as they have authenticated..
> Wait, wait!  I am not talking about SPF.  SPF is at the right place now.
> My note was about senderokwithdns, i.e. validity of "mail from" provided
> by the client.  I think that this check should be done regardless of all
> others, should it?
I agree with Eugene on this one... I don't want non-routable return paths 
whether the user authenticated or not...

Mariano Absatz
El Baby
Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
        -- Damian Conway, Perl Guru

To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi