set envelope sender = sasl authenticated user ?
Jan-Frode Myklebust
but still needs to let our users send from addresses not under
our control, so I was thinking of maybe of forcing all users
that wants to send email from not-our-addresses to sasl-authenticate
and hopefully postfix can then set envelope sender = sasl-authenticated
user.
Or maybe set envelope sender = sasl-authenticated user *if* the
sender isn't found in the smtpd_sender_login_maps.
Is this feasible ?
-jf
Noel Jones
> We want to get our smarthosts off the backscatterer.org lists,
> but still needs to let our users send from addresses not under
> our control, so I was thinking of maybe of forcing all users
> that wants to send email from not-our-addresses to sasl-authenticate
> and hopefully postfix can then set envelope sender = sasl-authenticated
> user.
I fail to see how controlling your users From: addresses will
affect a backscatterer.org listing.
>
> Or maybe set envelope sender = sasl-authenticated user *if* the
> sender isn't found in the smtpd_sender_login_maps.
>
Postfix's controls are described in
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch
and friends.
> Is this feasible ?
>
Probably not. It would require a milter or content_filter of
some type.
Looks to me as if you're working on the wrong problem.
-- Noel Jones
Jan-Frode Myklebust
>
> I fail to see how controlling your users From: addresses will affect
> a backscatterer.org listing.
I'm thinking we can accept sending some backscatter to our own
customers, at least as long as it's authenticated backscatter and we can
stop the abuser. We just want to avoid sending backscatter out of our
networks.
>
> Probably not. It would require a milter or content_filter of some
> type.
>
> Looks to me as if you're working on the wrong problem.
Do you have any other suggestions/pointers to what the real problem is?
As an ISP I can't see that we can deny our users to send from arbitrary
addresses.
-jf
Noel Jones
> On Mon, Sep 06, 2010 at 06:29:28PM -0500, Noel Jones wrote:
>>
>> I fail to see how controlling your users From: addresses will affect
>> a backscatterer.org listing.
>
> I'm thinking we can accept sending some backscatter to our own
> customers, at least as long as it's authenticated backscatter and we can
> stop the abuser. We just want to avoid sending backscatter out of our
> networks.
That's crazy talk.
> Do you have any other suggestions/pointers to what the real problem is?
Don't accept mail you don't intend to deliver, and don't annoy
other sysadmins or remote users. Specifically:
- reject unknown recipients for your local/virtual/relay
domains during the SMTP transaction. Do not accept everything
and later bounce the undeliverables.
- If you do spam and/or virus filtering, either do the
filtering pre-queue so you can reject unwanted mail during
SMTP, or accept+tag or quarantine unwanted mail. Never bounce
unwanted mail back to the reported (forged) sender address.
- Do not use the postfix "reject_unverified_sender" setting
unless you are a very low volume site or you make arrangements
to severely limit the scope of addresses that are verified.
Many sysadmins view verification probes as abusive -- it can
appear to be a dictionary attack.
-- Noel Jones
mouss
OP is an ISP providing outbound relay to residential users. his problem
is not easy to solve.
Jeroen Geilman
Limiting these to sending with their true ISP address is fairly common.
(And just about the only sane way to implement this kind of relay)
J.
Jan-Frode Myklebust
> On 09/07/2010 06:57 PM, mouss wrote:
> >
> >OP is an ISP providing outbound relay to residential users. his
> >problem is not easy to solve.
> >
Thanks for understanding. I´ve gotten information off list that gmail
are setting the sender to the gmail authenticated user when sending from
non-gmail addresses. So I´m at least not alone in thinking this should
be a good solution.
Also I believe you have to pre-register any address you want to send
from trough gmail, which sounds like we could use postfix´
smtpd_sender_login_maps to implement a similar solution.
> >
> Residential users don't often have their own mail servers/domains.
> Limiting these to sending with their true ISP address is fairly common.
> (And just about the only sane way to implement this kind of relay)
In Norway all/most ISPs are forcing their residential users trough the
ISP`s smarthosts. Outgoing port 25/tcp is blocked. So users are not
allowed to run their own mailservers. I can´t justify also requiring
all users to use the ISP´s mail addresses.
-jf
Noel Jones
> On Tue, Sep 07, 2010 at 08:20:36PM +0200, Jeroen Geilman wrote:
>> On 09/07/2010 06:57 PM, mouss wrote:
>>>
>>> OP is an ISP providing outbound relay to residential users. his
>>> problem is not easy to solve.
>>>
>
> Thanks for understanding. I´ve gotten information off list that gmail
> are setting the sender to the gmail authenticated user when sending from
> non-gmail addresses. So I´m at least not alone in thinking this should
> be a good solution.
Postfix has no mechanism to selectively rewrite the envelope
sender, nor does postfix have a mechanism to set "envelope
sender = auth user". You'll need a milter to do that.
> Also I believe you have to pre-register any address you want to send
> from trough gmail, which sounds like we could use postfix´
> smtpd_sender_login_maps to implement a similar solution.
You could use the sender login maps to reject mail with
"unregistered" auth/sender combinations.
If you have customers sending large amounts of abusive mail,
seems as if there would be better ways to deal with that eg.
sender quotas, monitoring of undeliverable mail, inbound
spam/virus scanning, etc. But I'm not an ISP; I can fire
anyone who abuses the mail system.
and I still fail to understand how controlling your customers
envelope sender will help with backscatterer.org.
-- Noel Jones
Jan-Frode Myklebust
> If you have customers sending large amounts of abusive mail, seems
> as if there would be better ways to deal with that eg. sender
> quotas, monitoring of undeliverable mail, inbound spam/virus
> scanning, etc. But I'm not an ISP; I can fire anyone who abuses the
> mail system.
We do sender quotas, some monitoring of undeliverable mail, in and
outbound spam/virus scanning and more, but this doesn't catch all.
Users that are clearly abusing the system (read: "has malware
installed") gets blocked automatically or manually, but there's a time
window where they will be able to send out junk, and when you have
enough customers -- someone will always have the latest and greatest
malware installed and we woun't catch it immediately.
> and I still fail to understand how controlling your customers
> envelope sender will help with backscatterer.org.
It will make sure that when viruses/malware on the customers computer is
sending out spam from fake addresses, the bounces goes back to the
customer with the infected computer -- instead of to whomever the
malware was pretending to send from.
-jf
Mikael Bak
>
>> and I still fail to understand how controlling your customers
>> envelope sender will help with backscatterer.org.
>
> It will make sure that when viruses/malware on the customers computer is
> sending out spam from fake addresses, the bounces goes back to the
> customer with the infected computer -- instead of to whomever the
> malware was pretending to send from.
>
I have never seen malware use SMTP AUTH via the smarthost SMTP. Most
malware shoot directly on 25/tcp.
Maybe you'll be better off blocking 25/tcp and force users to use the
submission port (587/tcp) with SMTP AUTH and possibly STARTTLS. I think
your spam problems will go away if you do that.
HTH,
Mikael
Frank Doege
> On Tue, Sep 07, 2010 at 08:20:36PM +0200, Jeroen Geilman wrote:
>> On 09/07/2010 06:57 PM, mouss wrote:
>>>
>>> OP is an ISP providing outbound relay to residential users. his
>>> problem is not easy to solve.
>>>
>
> Thanks for understanding. I´ve gotten information off list that gmail
> are setting the sender to the gmail authenticated user when sending from
> non-gmail addresses. So I´m at least not alone in thinking this should
> be a good solution.
>
> from trough gmail, which sounds like we could use postfix´
> smtpd_sender_login_maps to implement a similar solution.
>
>
>>>
>> Limiting these to sending with their true ISP address is fairly common.
>> (And just about the only sane way to implement this kind of relay)
>
> In Norway all/most ISPs are forcing their residential users trough the
> ISP`s smarthosts. Outgoing port 25/tcp is blocked. So users are not
> allowed to run their own mailservers. I can´t justify also requiring
> all users to use the ISP´s mail addresses.
>
>
> -jf
Hi,
iam running a small ISP here in egypt and we are using
smtpd_sender_login maps to prevent anyone unauthenticated to send from
email addresses they don't own, it works very well and postifix responds
with an error "address not owned by user".
one challenge we faced was that the database query has to include all
aliases which are registered for the authenticated username (in our case
the email) but this is no problem with some smart views on your database
table.
so set smtpd_sender_login_maps = proxy:pgsql:/path.cf
and then in smtpd_sender_restrictions = reject_sender_login_mismatch
and you are done.
PS: you should of course separate the incoming client mail and the
domain domain mail transfers, so for example mailserver to mailserver
uses port 25 where this policy is not applied and clients use port 587
submission where this policy is applied.
Frank
mouss
> On Tue, Sep 07, 2010 at 08:20:36PM +0200, Jeroen Geilman wrote:
>> On 09/07/2010 06:57 PM, mouss wrote:
>>> OP is an ISP providing outbound relay to residential users. his
>>> problem is not easy to solve.
>>>
> Thanks for understanding. I´ve gotten information off list that gmail
> are setting the sender to the gmail authenticated user when sending from
> non-gmail addresses. So I´m at least not alone in thinking this should
> be a good solution.
forget about gmail. you have a serious problem, and the solution isnt'
gmail. gmail is a public provider, you are not. you have a different
problem, and a serious one. most of us want you to block outound spam
(by blocking port 25 and filtering outbound mail). not easy...
do not try to rewrite mail headers. this is the wrong approach. headers
are specified by that who writes the message. instead, detect abuse/spam
by counting the number of messages sent from a given IP and block the IP
if it exceeds its quota. (block all its communication, not just smtp).
mouss
> On Tue, Sep 07, 2010 at 06:38:15PM -0500, Noel Jones wrote:
>> If you have customers sending large amounts of abusive mail, seems
>> as if there would be better ways to deal with that eg. sender
>> quotas, monitoring of undeliverable mail, inbound spam/virus
>> scanning, etc. But I'm not an ISP; I can fire anyone who abuses the
>> mail system.
> We do sender quotas, some monitoring of undeliverable mail, in and
> outbound spam/virus scanning and more, but this doesn't catch all.
>
> Users that are clearly abusing the system (read: "has malware
> installed") gets blocked automatically or manually, but there's a time
> window where they will be able to send out junk, and when you have
> enough customers -- someone will always have the latest and greatest
> malware installed and we woun't catch it immediately.
>
There are at least two different kind of users:
- victims whose PCs are owned. here, network quotas, errors detection,
... will help you know. now what can you do?
- spammers. you ought to detect them. but they can get back with
different names, ...
>> and I still fail to understand how controlling your customers
>> envelope sender will help with backscatterer.org.
> It will make sure that when viruses/malware on the customers computer is
> sending out spam from fake addresses, the bounces goes back to the
> customer with the infected computer -- instead of to whomever the
> malware was pretending to send from.
>
nah. this is useless. spam and viruses should get discarded. they have
no reason getting on the wire.
> -jf