Re: mx fails due to typo on remote dns

[Wietse Venema]

Postfix versions 2.3 and later skip a DNS record with a bad name.

Unsupported Postfix versions pretend that the lookup failed when
the result is invalid.

Wietse

Re: Backscatter being generated from mail aliased to other servers.

[Hannes Erven]

Folks,


it seems to me that there has been some misunderstanding of Jim's setup
and situation.


> Clearly, you are *NOT* doing recipient verification, or
> myotherserver.com would not be rejecting it. Never accept mail which
> cannot be delivered.

What he describes is that the final destination - after forward
expansion - rejects the forwarded message NOT because of the recipient
addresse, but because of its contents or whatever else.


The most effective way to conquer that sort of backscatter would be, as
Victor pointed out, to avoid forwarding spam.

For specific scenarios it might also be possible to set up some sort of
"before-queue-forwarding" and make the MTA an SMTP proxy?


-hannes

Re: Backscatter being generated from mail aliased to other servers.

[Wietse Venema]

Miles Fidelman:
> Wietse Venema wrote:
> > Recipient verification does not expand a local alias (imagine what
> > would have to be done to verify with addresses in .forward files,
> > or in a mail distribution list).
> >
> >   
> Maybe I'm dense, but what would be the problem with verifying addresses 
> in .forward files?

Basically, the problem is the same as with other mechanisms,
namely that the expansion may produce multiple results.

Address verification would be a lot more complicated if it
had do deal with forks and recursion.

> For list managers, it's a different story - the list manager needs NDNs 
> in order to identify and remove bad addresses.

Not all local aliases do or must replace the envelope sender.

Wietse

Re: mx fails due to typo on remote dns

[Victor Duchovni]

On Mon, Nov 16, 2009 at 01:55:46PM +, Laurence Moughan wrote:

> eurocommerce.ie.  3151 IN MX 10 cluster8.eu.messagelabs.com.
> eurocommerce.ie.  3151 IN MX 20 cluster8a.eu.messagelabs.com\032.
>
> See the (\032) trailing commas on the line containing the mx also
> seem to fail me.

The MX records is malformed. The safe thing to do is to not accept garbage.

> (Host or domain name not found. Name service error for
> name=EUROCOMMERCE.IE type=MX: Host not found, try again)

Errors should not be ignored, the malformed "cluster8a" MX host must
not be used.

> My postfix is 2.2 - do later postfix release cater for remote dns typos
> of this kind ?

Postfix 2.5.7 will likely be able to connect to the "cluster8" MX host.

smtp-finger: warning: valid_hostname: invalid character 92(decimal): 
cluster8a.eu.messagelabs.com\032
smtp-finger: warning: malformed domain name in resource data of MX record 
for eurocommerce.ie: cluster8a.eu.messagelabs.com\032
smtp-finger: Connected to cluster8.eu.messagelabs.com[85.158.139.19]:25
smtp-finger: < 220 server-14.tower-178.messagelabs.com ESMTP
smtp-finger: > EHLO hqmtaext01.ms.com
smtp-finger: < 250-server-14.tower-178.messagelabs.com
smtp-finger: < 250-STARTTLS
smtp-finger: < 250-PIPELINING
smtp-finger: < 250 8BITMIME

The unreleased "smtp-finger" code is essentially identical to the code
in the SMTP delivery agent, both call smtp_domain_addr() to resolve
the MX host list. So if smtp-finger can connect, I'd expect the same
from smtp(8).

Feel free to try 2.5.7. If you want more help, you really should report
full log entries from a failed delivery (all loging from the smtp(8)
delivery agent with the same process id that reports the final delivery
error, preceding that error, but not associated with a previous transaction).

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Backscatter being generated from mail aliased to other servers.

[Miles Fidelman]

Wietse Venema wrote:

Recipient verification does not expand a local alias (imagine what
would have to be done to verify with addresses in .forward files,
or in a mail distribution list).

  
Maybe I'm dense, but what would be the problem with verifying addresses 
in .forward files?


For list managers, it's a different story - the list manager needs NDNs 
in order to identify and remove bad addresses.


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: ERROR in tcp protocol

[Victor Duchovni]

On Tue, Nov 17, 2009 at 10:05:04AM +1100, Barney Desmond wrote:

> I get the impression everyone's barking up the wrong tree. Not
> surprising, given that the tcp table type is documented thusly: "This
> protocol is not available in the stable Postfix release".

Your feeling is probably in error. The OP almost certainly just wants
to send email to an SMTP server on localhost:2525, which has nothing
to do with the experimental "tcp" table type.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: ERROR in tcp protocol

[Barney Desmond]

I get the impression everyone's barking up the wrong tree. Not
surprising, given that the tcp table type is documented thusly: "This
protocol is not available in the stable Postfix release".

2009/11/17 Dhiraj Chatpar :
> I using Centos now.. and this is the output
>
> [r...@lsdinkindia ~]# postconf -m
> btree
> cidr
> environ
> hash
> nis
> proxy
> regexp
> static
> unix
>
> It does not show tcp. How do i get the tcp activated on this centos machine
> as it alwayz used to be there on my ubuntu machine by default?

Dhiraj, when asking for help it's best to show us the output of
`postconf -n` so we can understand the configuration of your machine,
and also describe what you're trying to do. If it's not working as
you'd expect, tell us what you expect, and what you're seeing. You've
posted log entries, which is great.

The stock Centos/RHEL packages are hopelessly sparse; as far as I know
there's no simple way to get tcp table support. There's a package in
the CentosPlus repo that will give you DB lookup tables
(http://mirror.centos.org/centos/5/centosplus/x86_64/RPMS/postfix-2.3.3-2.1.centos.mysql_pgsql.x86_64.rpm)
but that's as far as you can go without 3rd-party packages.

I believe Simon Mudd builds RPMs that contain more up-to-date versions
of Postfix, but I've never used them - they *may* have tcp table
support, you'll have to check for yourself:
http://postfix.wl0.org/en/available-packages/

The reason it's on your ubuntu machine is because it was compiled with
that option enabled. Eg.:
r...@shimako:~# postconf -m
btree
cidr
environ
hash
nis
proxy
regexp
sdbm
static
tcp
unix

sdbm and tcp aren't listed in the Centos output. There are also
additional ubuntu packages for cdb, ldap, mysql, pcre and pgsql
support. If you have the choice, you may be better off moving to
ubuntu/debian for your mailserver.

Re: Backscatter being generated from mail aliased to other servers.

[Wietse Venema]

Jim Lang:
>  But if mycli...@otherserver.com  can for whatever reason not be 
>  delivered, otherserver.com does what it is supposed to do and
>  rejects the mail during the smtp connection, which causes postfix
>  to send out a non-delivery  report to vic...@randomdomain.com  --
>  backscatter.
> 
>  Is there a way to stop this? 
>  
>  
> >>> Yes. Don't forward SPAM.
> >>>
> >>>   Wietse
> >>>   
> >>>   
> >> And how do I do that in this scenario?
> >> 
> >
> > You use recipient verification.
> >
> >   
> I must have been really inarticulate when I wrote out the scenario.  I 
> do use recipient verification on my server.  How is it that that is not 
> clear? Do I need to rewrite this post?

Recipient verification does not expand a local alias (imagine what
would have to be done to verify with addresses in .forward files,
or in a mail distribution list).

So the best option is to avoid forwarding SPAM, including Victor's
suggestion to not forward mail indefinitely for legacy user accounts.

Other options get ugly quickly (such as replacing the return address).

Wietse

Re: Backscatter being generated from mail aliased to other servers.

[Jaroslaw Grzabel]

This page (http://www.postfix.org/ADDRESS_VERIFICATION_README.html)
looks like it describes part of your problem. Could be the solution

Regards

tobi
  


I had had a lot of troubles with verification database. For example... 
new customer is added to SMTP relay, changed MX record to point my 
server, but end user misconfigured something on the server for 
example... user john wasn't configured and after a couple of days it 
turned out "john" is missing. So John was added to the remote server, 
run some tests and what ? My server still says "No such user" why ? 
Because it remembers that in the database. After that I have had to 
remove the database and restart daemon, finally I completely got rid of 
verify.db and did verification without db.


Regards,
Jarek

Re: Backscatter being generated from mail aliased to other servers.

[tobi]

Jaroslaw Grzabel schrieb:
> Jim Lang pisze:
>> John Peach wrote:
>>> On Mon, 16 Nov 2009 13:07:05 -0700
>>> Jim Lang  wrote:
>>>
>>>  
 John Peach wrote:
   
> On Mon, 16 Nov 2009 13:00:26 -0700
> Jim Lang  wrote:
>
>   
>> Wietse Venema wrote:
>>   
>>> Jim Lang:
>>> 
 OK here is the scenario.  Spammer sends mail to:
 u...@myclientsdomain.com from forged
 address vic...@randomdomain.com

 If u...@myclientsdomain.com is delivered locally, not a problem,
 if the address is invalid, postix rejects the mail during the
 smtp connection.

 But if u...@myclientsdomain.com is an alias to
 mycli...@otherserver.com, postfix accepts the mail as deliverable
 and forwards it to hotmail.com. But if
 mycli...@otherserver.com  can for whatever reason not be
 delivered, otherserver.com does what it is supposed to do and
 rejects the mail during the smtp connection, which causes postfix
 to send out a non-delivery  report to vic...@randomdomain.com  --
 backscatter.

 Is there a way to stop this? 
>>> Yes. Don't forward SPAM.
>>>
>>> Wietse
>>>   
>> And how do I do that in this scenario?
>> 
> You use recipient verification.
>
> 
 I must have been really inarticulate when I wrote out the scenario.
 I do use recipient verification on my server.  How is it that that is
 not clear? Do I need to rewrite this post?

 
>>> Clearly, you are *NOT* doing recipient verification, or
>>> myotherserver.com would not be rejecting it. Never accept mail which
>>> cannot be delivered.
>>>   
>>
>>
>> Except no 'myotherserver.com' appeared in my scenario,  nimrod.
>>
>> otherserver.com in the scenario is a server not under my control.
>>
>> unsubcribing to this useless list
> But server which is out of your control should not accept messages for
> example to non-existant user. So if you're doing verification even
> when spammer connects to your server should recieve an ansewer from
> REMOTE SERVER "user not known" or something similar. I've got similar
> situation as I had to smart host for a lot of domains and connection,
> but let's say I know people on that remote site, or even if not I've
> got any contact details like email addres so simply... I'm trying to
> explain people that if they will not protect the end server I will
> block them in the smart host as I can't take a risk of block. So
> generally you should use  reject_unverified_recipient and additionally
> you can build a database... you can limit connections, check RBLs,
> CBLs, there is really a lot of things but first of all you would need
> to check which hosts on the other end couses a problem and find out
> what you can do more to prevent spam coming through.
> I know that it's impossible to block all SPAM without being too harsh,
> but there is always something what you can do to prevent it.
>
> Regards,
> Jarek
This page (http://www.postfix.org/ADDRESS_VERIFICATION_README.html)
looks like it describes part of your problem. Could be the solution

Regards

tobi

Re: Backscatter being generated from mail aliased to other servers.

[Jaroslaw Grzabel]

Jim Lang pisze:

John Peach wrote:

On Mon, 16 Nov 2009 13:07:05 -0700
Jim Lang  wrote:

 

John Peach wrote:
   

On Mon, 16 Nov 2009 13:00:26 -0700
Jim Lang  wrote:

   

Wietse Venema wrote:
   

Jim Lang:
 
OK here is the scenario.  
Spammer sends mail to: u...@myclientsdomain.com from forged

address vic...@randomdomain.com

If u...@myclientsdomain.com is delivered locally, not a problem,
if the address is invalid, postix rejects the mail during the
smtp connection.

But if u...@myclientsdomain.com is an alias to
mycli...@otherserver.com, postfix accepts the mail as deliverable
and forwards it to hotmail.com. 
But if mycli...@otherserver.com  can for whatever reason not be 
delivered, otherserver.com does what it is supposed to do and

rejects the mail during the smtp connection, which causes postfix
to send out a non-delivery  report to vic...@randomdomain.com  --
backscatter.

Is there a way to stop this? 

Yes. Don't forward SPAM.

Wietse
  

And how do I do that in this scenario?


You use recipient verification.



I must have been really inarticulate when I wrote out the scenario.
I do use recipient verification on my server.  How is it that that is
not clear? Do I need to rewrite this post?



Clearly, you are *NOT* doing recipient verification, or
myotherserver.com would not be rejecting it. Never accept mail which
cannot be delivered.
  



Except no 'myotherserver.com' appeared in my scenario,  nimrod.

otherserver.com in the scenario is a server not under my control.

unsubcribing to this useless list
But server which is out of your control should not accept messages for 
example to non-existant user. So if you're doing verification even when 
spammer connects to your server should recieve an ansewer from REMOTE 
SERVER "user not known" or something similar. I've got similar situation 
as I had to smart host for a lot of domains and connection, but let's 
say I know people on that remote site, or even if not I've got any 
contact details like email addres so simply... I'm trying to explain 
people that if they will not protect the end server I will block them in 
the smart host as I can't take a risk of block. So generally you should 
use  reject_unverified_recipient and additionally you can build a 
database... you can limit connections, check RBLs, CBLs, there is really 
a lot of things but first of all you would need to check which hosts on 
the other end couses a problem and find out what you can do more to 
prevent spam coming through.
I know that it's impossible to block all SPAM without being too harsh, 
but there is always something what you can do to prevent it.


Regards,
Jarek

Re: Backscatter being generated from mail aliased to other servers.

[Jim Lang]

John Peach wrote:

On Mon, 16 Nov 2009 13:07:05 -0700
Jim Lang  wrote:

  

John Peach wrote:


On Mon, 16 Nov 2009 13:00:26 -0700
Jim Lang  wrote:

  
  

Wietse Venema wrote:



Jim Lang:
  
  
  
OK here is the scenario.   


Spammer sends mail to: u...@myclientsdomain.com from forged
address vic...@randomdomain.com

If u...@myclientsdomain.com is delivered locally, not a problem,
if the address is invalid, postix rejects the mail during the
smtp connection.

But if u...@myclientsdomain.com is an alias to
mycli...@otherserver.com, postfix accepts the mail as deliverable
and forwards it to hotmail.com.  

But if mycli...@otherserver.com  can for whatever reason not be 
delivered, otherserver.com does what it is supposed to do and

rejects the mail during the smtp connection, which causes postfix
to send out a non-delivery  report to vic...@randomdomain.com  --
backscatter.

Is there a way to stop this? 




Yes. Don't forward SPAM.

Wietse
  
  
  

And how do I do that in this scenario?



You use recipient verification.

  
  

I must have been really inarticulate when I wrote out the scenario.
I do use recipient verification on my server.  How is it that that is
not clear? Do I need to rewrite this post?



Clearly, you are *NOT* doing recipient verification, or
myotherserver.com would not be rejecting it. Never accept mail which
cannot be delivered.
  



Except no 'myotherserver.com' appeared in my scenario,  nimrod.

otherserver.com in the scenario is a server not under my control.

unsubcribing to this useless list

Re: Backscatter being generated from mail aliased to other servers.

[Jim Lang]

Stan Hoeppner wrote:

Jim Lang put forth on 11/16/2009 2:00 PM:
  

Wietse Venema wrote:


Jim Lang:
 
  
OK here is the scenario.  
Spammer sends mail to: u...@myclientsdomain.com from forged address

vic...@randomdomain.com

If u...@myclientsdomain.com is delivered locally, not a problem, if
the address is invalid, postix rejects the mail during the smtp
connection.

But if u...@myclientsdomain.com is an alias to
mycli...@otherserver.com, postfix accepts the mail as deliverable and
forwards it to hotmail.com. 
But if mycli...@otherserver.com  can for whatever reason not be

delivered, otherserver.com does what it is supposed to do and rejects
the mail during the smtp connection, which causes postfix to send out
a non-delivery  report to vic...@randomdomain.com  -- backscatter.

Is there a way to stop this? 


Yes. Don't forward SPAM.

Wietse
  
  

And how do I do that in this scenario?



You don't do it "in this scenario".  You set up comprehensive spam
rejection techniques, one of which is identifying forged email, and
reject spam when it hits your MX.

Dozens of books have been written, and dozens of email lists are
maintained, specifically for fighting spam.  The answer to your scenario
isn't a simple one paragraph response on postfix-users.

What are you doing up to this point to reject spam at your border MX(s)?

  
I'm doing many, many things.  And I certainly don't have the time to 
enumerate them all simply to prove my bona fides.


No one responding to this post seems to have actually bothered to read it.

Generic, rtfm responses such as "don't forward spam" may be emotionally 
satisfying but they are really a waste of everyone's time.

As was asking for advice at this list.

I'll figure it out for myself.  

Re: Backscatter being generated from mail aliased to other servers.

[John Peach]

On Mon, 16 Nov 2009 13:07:05 -0700
Jim Lang  wrote:

> John Peach wrote:
> > On Mon, 16 Nov 2009 13:00:26 -0700
> > Jim Lang  wrote:
> >
> >   
> >> Wietse Venema wrote:
> >> 
> >>> Jim Lang:
> >>>   
> >>>   
>  OK here is the scenario.   
> 
>  Spammer sends mail to: u...@myclientsdomain.com from forged
>  address vic...@randomdomain.com
> 
>  If u...@myclientsdomain.com is delivered locally, not a problem,
>  if the address is invalid, postix rejects the mail during the
>  smtp connection.
> 
>  But if u...@myclientsdomain.com is an alias to
>  mycli...@otherserver.com, postfix accepts the mail as deliverable
>  and forwards it to hotmail.com.  
> 
>  But if mycli...@otherserver.com  can for whatever reason not be 
>  delivered, otherserver.com does what it is supposed to do and
>  rejects the mail during the smtp connection, which causes postfix
>  to send out a non-delivery  report to vic...@randomdomain.com  --
>  backscatter.
> 
>  Is there a way to stop this? 
>  
>  
> >>> Yes. Don't forward SPAM.
> >>>
> >>>   Wietse
> >>>   
> >>>   
> >> And how do I do that in this scenario?
> >> 
> >
> > You use recipient verification.
> >
> >   
> I must have been really inarticulate when I wrote out the scenario.
> I do use recipient verification on my server.  How is it that that is
> not clear? Do I need to rewrite this post?
> 
Clearly, you are *NOT* doing recipient verification, or
myotherserver.com would not be rejecting it. Never accept mail which
cannot be delivered.




-- 
John

Re: Backscatter being generated from mail aliased to other servers.

[Victor Duchovni]

On Mon, Nov 16, 2009 at 12:53:14PM -0700, Jim Lang wrote:

> OK here is the scenario.   
> Spammer sends mail to: u...@myclientsdomain.com from forged address 
> vic...@randomdomain.com
>
> If u...@myclientsdomain.com is delivered locally, not a problem, if the 
> address is invalid, postix rejects the mail during the smtp connection.
>
> But if u...@myclientsdomain.com is an alias to mycli...@otherserver.com, 
> postfix accepts the mail as deliverable and forwards it to hotmail.com.  
> But if mycli...@otherserver.com  can for whatever reason not be delivered, 
> otherserver.com does what it is supposed to do and rejects the mail during 
> the smtp connection, which causes postfix to send out a non-delivery  
> report to vic...@randomdomain.com  -- backscatter.
>
> Is there a way to stop this? 

Some backscatter is unavoidable, you can keep the volume low by removing
local aliases to no-longer-valid external addresses, and by rejecting
mail from spam sources, using good blacklists, ...

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Backscatter being generated from mail aliased to other servers.

[Stan Hoeppner]

Jim Lang put forth on 11/16/2009 2:00 PM:
> Wietse Venema wrote:
>> Jim Lang:
>>  
>>> OK here is the scenario.  
>>> Spammer sends mail to: u...@myclientsdomain.com from forged address
>>> vic...@randomdomain.com
>>>
>>> If u...@myclientsdomain.com is delivered locally, not a problem, if
>>> the address is invalid, postix rejects the mail during the smtp
>>> connection.
>>>
>>> But if u...@myclientsdomain.com is an alias to
>>> mycli...@otherserver.com, postfix accepts the mail as deliverable and
>>> forwards it to hotmail.com. 
>>> But if mycli...@otherserver.com  can for whatever reason not be
>>> delivered, otherserver.com does what it is supposed to do and rejects
>>> the mail during the smtp connection, which causes postfix to send out
>>> a non-delivery  report to vic...@randomdomain.com  -- backscatter.
>>>
>>> Is there a way to stop this? 
>>
>> Yes. Don't forward SPAM.
>>
>> Wietse
>>   
> And how do I do that in this scenario?

You don't do it "in this scenario".  You set up comprehensive spam
rejection techniques, one of which is identifying forged email, and
reject spam when it hits your MX.

Dozens of books have been written, and dozens of email lists are
maintained, specifically for fighting spam.  The answer to your scenario
isn't a simple one paragraph response on postfix-users.

What are you doing up to this point to reject spam at your border MX(s)?

--
Stan

Re: ERROR in tcp protocol

[Victor Duchovni]

On Mon, Nov 16, 2009 at 02:56:08PM -0500, Wietse Venema wrote:

> Dhiraj Chatpar:
> > HI,
> > 
> > I am getting this error when i am trying to connect my postfix
> > via transport_maps = tcp:localhost:2525
> > 
> > Nov 16 13:48:34 mail postfix/trivial-rewrite[4403]: fatal: unsupported
> > dictionary type: tcp
> 
> Use "postconf -m" to see what types of map are supported.

Given the port number (2525), it is most likely that the TCP service
in question is an SMTP server. As others have pointed out, the
"transport_maps" parameter is a list of "type:name" *tables* that
map recipient domains to a transport:nexthop.

If the OP wants to set a global default nexthop, that's done with
default_transport:

default_transport = smtp:[localhost]:2525

similar settings are available for other address classes:

relay_transport = ...
virtual_transport = ...
local_transport = ...

Additionally, the "relayhost" parameter provides a default nexthop,
without overriding the transport.

http://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost
http://www.postfix.org/ADDRESS_REWRITING_README.html#delivering
http://www.postfix.org/ADDRESS_REWRITING_README.html#resolve
http://www.postfix.org/ADDRESS_CLASS_README.html#classes

http://www.postfix.org/postconf.5.html#default_transport
http://www.postfix.org/postconf.5.html#relay_transport
http://www.postfix.org/postconf.5.html#virtual_transport
http://www.postfix.org/postconf.5.html#local_transport
http://www.postfix.org/postconf.5.html#relayhost

http://www.postfix.org/postconf.5.html#transport_maps

http://www.postfix.org/transport.5.html

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Backscatter being generated from mail aliased to other servers.

[Jim Lang]

John Peach wrote:

On Mon, 16 Nov 2009 13:00:26 -0700
Jim Lang  wrote:

  

Wietse Venema wrote:


Jim Lang:
  
  
OK here is the scenario.   


Spammer sends mail to: u...@myclientsdomain.com from forged
address vic...@randomdomain.com

If u...@myclientsdomain.com is delivered locally, not a problem,
if the address is invalid, postix rejects the mail during the smtp
connection.

But if u...@myclientsdomain.com is an alias to
mycli...@otherserver.com, postfix accepts the mail as deliverable
and forwards it to hotmail.com.  

But if mycli...@otherserver.com  can for whatever reason not be 
delivered, otherserver.com does what it is supposed to do and

rejects the mail during the smtp connection, which causes postfix
to send out a non-delivery  report to vic...@randomdomain.com  --
backscatter.

Is there a way to stop this? 



Yes. Don't forward SPAM.

Wietse
  
  

And how do I do that in this scenario?



You use recipient verification.

  
I must have been really inarticulate when I wrote out the scenario.  I 
do use recipient verification on my server.  How is it that that is not 
clear? Do I need to rewrite this post?







  

Re: Backscatter being generated from mail aliased to other servers.

[John Peach]

On Mon, 16 Nov 2009 13:00:26 -0700
Jim Lang  wrote:

> Wietse Venema wrote:
> > Jim Lang:
> >   
> >> OK here is the scenario.   
> >>
> >> Spammer sends mail to: u...@myclientsdomain.com from forged
> >> address vic...@randomdomain.com
> >>
> >> If u...@myclientsdomain.com is delivered locally, not a problem,
> >> if the address is invalid, postix rejects the mail during the smtp
> >> connection.
> >>
> >> But if u...@myclientsdomain.com is an alias to
> >> mycli...@otherserver.com, postfix accepts the mail as deliverable
> >> and forwards it to hotmail.com.  
> >>
> >> But if mycli...@otherserver.com  can for whatever reason not be 
> >> delivered, otherserver.com does what it is supposed to do and
> >> rejects the mail during the smtp connection, which causes postfix
> >> to send out a non-delivery  report to vic...@randomdomain.com  --
> >> backscatter.
> >>
> >> Is there a way to stop this? 
> >> 
> >
> > Yes. Don't forward SPAM.
> >
> > Wietse
> >   
> And how do I do that in this scenario?

You use recipient verification.

> 
> 


-- 
John

Re: Backscatter being generated from mail aliased to other servers.

[Jim Lang]

Wietse Venema wrote:

Jim Lang:
  
OK here is the scenario.   

Spammer sends mail to: u...@myclientsdomain.com from forged address 
vic...@randomdomain.com


If u...@myclientsdomain.com is delivered locally, not a problem, if the 
address is invalid, postix rejects the mail during the smtp connection.


But if u...@myclientsdomain.com is an alias to mycli...@otherserver.com, 
postfix accepts the mail as deliverable and forwards it to hotmail.com.  

But if mycli...@otherserver.com  can for whatever reason not be 
delivered, otherserver.com does what it is supposed to do and rejects 
the mail during the smtp connection, which causes postfix to send out a 
non-delivery  report to vic...@randomdomain.com  -- backscatter.


Is there a way to stop this? 



Yes. Don't forward SPAM.

Wietse
  

And how do I do that in this scenario?

Re: ERROR in tcp protocol

[Dhiraj Chatpar]

Hi Mr. Wietse,

I using Centos now.. and this is the output

[r...@lsdinkindia ~]# postconf -m
btree
cidr
environ
hash
nis
proxy
regexp
static
unix


It does not show tcp. How do i get the tcp activated on this centos machine
as it alwayz used to be there on my ubuntu machine by default?

Rgds
Dhiraj

On Tue, Nov 17, 2009 at 01:26, Wietse Venema  wrote:

> Dhiraj Chatpar:
> > HI,
> >
> > I am getting this error when i am trying to connect my postfix
> > via transport_maps = tcp:localhost:2525
> >
> > Nov 16 13:48:34 mail postfix/trivial-rewrite[4403]: fatal: unsupported
> > dictionary type: tcp
>
> Use "postconf -m" to see what types of map are supported.
>
>Wietse
>

Re: ERROR in tcp protocol

[Wietse Venema]

Dhiraj Chatpar:
> HI,
> 
> I am getting this error when i am trying to connect my postfix
> via transport_maps = tcp:localhost:2525
> 
> Nov 16 13:48:34 mail postfix/trivial-rewrite[4403]: fatal: unsupported
> dictionary type: tcp

Use "postconf -m" to see what types of map are supported.

Wietse

Re: Backscatter being generated from mail aliased to other servers.

[Wietse Venema]

Jim Lang:
> OK here is the scenario.   
> 
> Spammer sends mail to: u...@myclientsdomain.com from forged address 
> vic...@randomdomain.com
> 
> If u...@myclientsdomain.com is delivered locally, not a problem, if the 
> address is invalid, postix rejects the mail during the smtp connection.
> 
> But if u...@myclientsdomain.com is an alias to mycli...@otherserver.com, 
> postfix accepts the mail as deliverable and forwards it to hotmail.com.  
> 
> But if mycli...@otherserver.com  can for whatever reason not be 
> delivered, otherserver.com does what it is supposed to do and rejects 
> the mail during the smtp connection, which causes postfix to send out a 
> non-delivery  report to vic...@randomdomain.com  -- backscatter.
> 
> Is there a way to stop this? 

Yes. Don't forward SPAM.

Wietse

Backscatter being generated from mail aliased to other servers.

[Jim Lang]

OK here is the scenario.   

Spammer sends mail to: u...@myclientsdomain.com from forged address 
vic...@randomdomain.com


If u...@myclientsdomain.com is delivered locally, not a problem, if the 
address is invalid, postix rejects the mail during the smtp connection.


But if u...@myclientsdomain.com is an alias to mycli...@otherserver.com, 
postfix accepts the mail as deliverable and forwards it to hotmail.com.  

But if mycli...@otherserver.com  can for whatever reason not be 
delivered, otherserver.com does what it is supposed to do and rejects 
the mail during the smtp connection, which causes postfix to send out a 
non-delivery  report to vic...@randomdomain.com  -- backscatter.


Is there a way to stop this? 

Re: Accept unlisted recipient for authentified users and my network

[Pascal Maes]

Le 16 nov. 2009 à 19:46, Pascal Maes a écrit :

> Helo,
> 
> I would like that authentified users and users from my network could send 
> email to wrong adresses because it could be worse to find a wrong address if 
> the mail is rejected at the smtp connection.
> 
> # postconf -n
> address_verify_sender = verify_addr...@uclouvain.be
> alias_database = hash:/etc/postfix/aliases
> alias_maps = hash:/etc/postfix/aliases
> bounce_size_limit = 5
> broken_sasl_auth_clients = yes
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> disable_vrfy_command = yes
> empty_address_recipient = MAILER-DAEMON
> hash_queue_depth = 1
> hash_queue_names = deferred defer incoming hold
> header_checks = regexp:/etc/postfix/rules/header_checks
> html_directory = no
> mail_owner = postfix
> mailbox_size_limit = 25000
> mailq_path = /usr/bin/mailq
> manpage_directory = /usr/local/man
> message_size_limit = 25000
> milter_default_action = tempfail
> milter_protocol = 6
> mydestination = $myhostname, localhost, localhost.$mydomain
> mydomain = sipr-dc.ucl.ac.be
> myhostname = smtp1.sgsi.ucl.ac.be
> mynetworks = 
> 127.0.0.0/8,10.0.0.0/8,130.104.0.0/16,192.168.128.0/17,193.190.89.0/24
> newaliases_path = /usr/bin/newaliases
> parent_domain_matches_subdomains = debug_peer_list
>   mynetworks
> queue_directory = /var/spool/postfix
> readme_directory = no
> relay_domains = hash:/etc/postfix/relais/relay_domains
> relay_recipient_maps = hash:/etc/postfix/relais/transport 
>hash:/etc/postfix/relais/virtual_relais
>hash:/etc/postfix/relais/virtual_aliases
> sample_directory = /etc/postfix
> sendmail_path = /usr/sbin/sendmail
> setgid_group = postdrop
> smtpd_banner = $myhostname ESMTP
> smtpd_client_connection_rate_limit = 20
> smtpd_client_message_rate_limit = 300
> smtpd_client_recipient_rate_limit = 1000
> smtpd_data_restrictions = check_sender_access 
> hash:/etc/postfix/rules/check_backscatterer
> smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10040
> smtpd_hard_error_limit = ${stress?3}${stress:20}
> smtpd_helo_required = yes
> smtpd_helo_restrictions = check_client_access hash:/etc/postfix/rules/access
>   check_recipient_access pcre:/etc/postfix/rules/listes_client_access
>   permit_mynetworks
>   permit_sasl_authenticated
>   reject_invalid_hostname
>check_client_access hash:/etc/postfix/rules/helo_whitelist
>   check_recipient_access hash:/etc/postfix/rules/roleaccount_exceptions
>reject_non_fqdn_hostname
>   check_client_access hash:/etc/postfix/files_access/spammers
>   check_helo_access pcre:/etc/postfix/rules/helo_checks
>   check_sender_mx_access cidr:/etc/postfix/rules/bogus_mx_checks
>   permit
> smtpd_milters = unix:/var/run/clamav/milter-clamav.socket
>   local:/var/run/milter/milter-spiff.socket
> smtpd_recipient_restrictions = reject_non_fqdn_recipient
>   reject_non_fqdn_sender
>   check_recipient_access hash:/etc/postfix/rules/ucllouvain
>   check_recipient_access hash:/etc/postfix/rules/invalid
>   check_recipient_access hash:/etc/postfix/rules/phishing_reply_adresses
>   permit_sasl_authenticated
>   permit_mynetworks
>   reject_unlisted_recipient
>   reject_unknown_recipient_domain
>   reject_unauth_destination
>   reject_multi_recipient_bounce
>   check_recipient_access hash:/etc/postfix/rules/roleaccount_exceptions
>   check_client_access cidr:/etc/postfix/rules/hi-med-dnswl-header
>   check_client_access cidr:/etc/postfix/rules/hi-med-dnswl-permit
>   check_sender_access hash:/etc/postfix/rules/sender_whitelist
>   check_client_access hash:/etc/postfix/rules/client_whitelist
>   check_sender_access pcre:/etc/postfix/rules/pcre_sender_whitelist
>   check_recipient_access hash:/etc/postfix/rules/recipient_whitelist
>   reject_rbl_client zen.dnsbl
>   reject_rbl_client sip.invaluement.dnsbl
>   reject_rbl_client cbl.abuseat.org
>   reject_rbl_client bl.spamcop.net
>   reject_rbl_client safe.dnsbl.sorbs.net
>   permit_auth_destination
>   reject
> smtpd_restriction_classes = must_be_valid_squirrel_sender
>   restrict_list_client_access
>   restrict_list_sender_accesrestrict_list_cluster_access
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_local_domain = $myhostname
> smtpd_sasl_security_options = noanonymous
> smtpd_sender_restrictions = check_recipient_access 
> pcre:/etc/postfix/rules/listes_sender_access
>   check_client_access hash:/etc/postfix/rules/squirrel_ip
>   check_sender_access hash:/etc/postfix/rules/access
>   permit_sasl_authenticated
>   permit_mynetworks
>   reject_unknown_recipient_domain
>   check_sender_access hash:/etc/postfix/rules/stluc
>   check_client_access hash:/etc/postfix/rules/access
>   reject_unknown_sender_

Re: ERROR in tcp protocol

[Brian Evans - Postfix List]

Dhiraj Chatpar wrote:
> HI,
>
> I am getting this error when i am trying to connect my postfix
> via transport_maps = tcp:localhost:2525
>
> Nov 16 13:48:34 mail postfix/trivial-rewrite[4403]: fatal: unsupported
> dictionary type: tcp
> Nov 16 13:48:35 mail postfix/master[4145]: warning: process
> /usr/libexec/postfix/trivial-rewrite pid 4403 exit status 1
> Nov 16 13:48:35 mail postfix/master[4145]: warning:
> /usr/libexec/postfix/trivial-rewrite: bad command startup -- throttling

transport_maps expects one or more transport map files (see man 5
transport).
It does *not* accept a bare reference to a tcp host/port.

What are you trying to solve?

Re: ERROR in tcp protocol

[Matt Hayes]

Dhiraj Chatpar wrote:
> HI,
> 
> I am getting this error when i am trying to connect my postfix
> via transport_maps = tcp:localhost:2525
> 
> Nov 16 13:48:34 mail postfix/trivial-rewrite[4403]: fatal: unsupported
> dictionary type: tcp
> Nov 16 13:48:35 mail postfix/master[4145]: warning: process
> /usr/libexec/postfix/trivial-rewrite pid 4403 exit status 1
> Nov 16 13:48:35 mail postfix/master[4145]: warning:
> /usr/libexec/postfix/trivial-rewrite: bad command startup -- throttling
> 
> 
> Please help me with a solution.
> 
> Rgds
> Dhiraj

Chatpar,

You really should read transport(5) for details

You don't specify a local socket like that in transport_maps

-Matt

ERROR in tcp protocol

[Dhiraj Chatpar]

HI,

I am getting this error when i am trying to connect my postfix
via transport_maps = tcp:localhost:2525

Nov 16 13:48:34 mail postfix/trivial-rewrite[4403]: fatal: unsupported
dictionary type: tcp
Nov 16 13:48:35 mail postfix/master[4145]: warning: process
/usr/libexec/postfix/trivial-rewrite pid 4403 exit status 1
Nov 16 13:48:35 mail postfix/master[4145]: warning:
/usr/libexec/postfix/trivial-rewrite: bad command startup -- throttling


Please help me with a solution.

Rgds
Dhiraj

Accept unlisted recipient for authentified users and my network

[Pascal Maes]

Helo,

I would like that authentified users and users from my network could send email 
to wrong adresses because it could be worse to find a wrong address if the mail 
is rejected at the smtp connection.

# postconf -n
address_verify_sender = verify_addr...@uclouvain.be
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
bounce_size_limit = 5
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
disable_vrfy_command = yes
empty_address_recipient = MAILER-DAEMON
hash_queue_depth = 1
hash_queue_names = deferred defer incoming hold
header_checks = regexp:/etc/postfix/rules/header_checks
html_directory = no
mail_owner = postfix
mailbox_size_limit = 25000
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 25000
milter_default_action = tempfail
milter_protocol = 6
mydestination = $myhostname, localhost, localhost.$mydomain
mydomain = sipr-dc.ucl.ac.be
myhostname = smtp1.sgsi.ucl.ac.be
mynetworks = 
127.0.0.0/8,10.0.0.0/8,130.104.0.0/16,192.168.128.0/17,193.190.89.0/24
newaliases_path = /usr/bin/newaliases
parent_domain_matches_subdomains = debug_peer_list
mynetworks
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = hash:/etc/postfix/relais/relay_domains
relay_recipient_maps = hash:/etc/postfix/relais/transport   
 hash:/etc/postfix/relais/virtual_relais
 hash:/etc/postfix/relais/virtual_aliases
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP
smtpd_client_connection_rate_limit = 20
smtpd_client_message_rate_limit = 300
smtpd_client_recipient_rate_limit = 1000
smtpd_data_restrictions = check_sender_access 
hash:/etc/postfix/rules/check_backscatterer
smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10040
smtpd_hard_error_limit = ${stress?3}${stress:20}
smtpd_helo_required = yes
smtpd_helo_restrictions = check_client_access hash:/etc/postfix/rules/access
check_recipient_access pcre:/etc/postfix/rules/listes_client_access
permit_mynetworks
permit_sasl_authenticated
reject_invalid_hostname
check_client_access hash:/etc/postfix/rules/helo_whitelist
check_recipient_access hash:/etc/postfix/rules/roleaccount_exceptions
reject_non_fqdn_hostname
check_client_access hash:/etc/postfix/files_access/spammers
check_helo_access pcre:/etc/postfix/rules/helo_checks
check_sender_mx_access cidr:/etc/postfix/rules/bogus_mx_checks
permit
smtpd_milters = unix:/var/run/clamav/milter-clamav.socket
local:/var/run/milter/milter-spiff.socket
smtpd_recipient_restrictions = reject_non_fqdn_recipient
reject_non_fqdn_sender
check_recipient_access hash:/etc/postfix/rules/ucllouvain
check_recipient_access hash:/etc/postfix/rules/invalid
check_recipient_access hash:/etc/postfix/rules/phishing_reply_adresses
permit_sasl_authenticated
permit_mynetworks
reject_unlisted_recipient
reject_unknown_recipient_domain
reject_unauth_destination
reject_multi_recipient_bounce
check_recipient_access hash:/etc/postfix/rules/roleaccount_exceptions
check_client_access cidr:/etc/postfix/rules/hi-med-dnswl-header
check_client_access cidr:/etc/postfix/rules/hi-med-dnswl-permit
check_sender_access hash:/etc/postfix/rules/sender_whitelist
check_client_access hash:/etc/postfix/rules/client_whitelist
check_sender_access pcre:/etc/postfix/rules/pcre_sender_whitelist
check_recipient_access hash:/etc/postfix/rules/recipient_whitelist
reject_rbl_client zen.dnsbl
reject_rbl_client sip.invaluement.dnsbl
reject_rbl_client cbl.abuseat.org
reject_rbl_client bl.spamcop.net
reject_rbl_client safe.dnsbl.sorbs.net
permit_auth_destination
reject
smtpd_restriction_classes = must_be_valid_squirrel_sender
restrict_list_client_access
restrict_list_sender_accesrestrict_list_cluster_access
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = check_recipient_access 
pcre:/etc/postfix/rules/listes_sender_access
check_client_access hash:/etc/postfix/rules/squirrel_ip
check_sender_access hash:/etc/postfix/rules/access
permit_sasl_authenticated
permit_mynetworks
reject_unknown_recipient_domain
check_sender_access hash:/etc/postfix/rules/stluc
check_client_access hash:/etc/postfix/rules/access
reject_unknown_sender_domain
smtpd_soft_error_limit = ${stress?1}${stress:10}
smtpd_tls_CAfile = /etc/postfix/ssl/ct_root.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/ssl/smtp

Adding spam attack IP's to DNSRBL providers

[Stan Hoeppner]

Sharma, Ashish put forth on 11/16/2009 6:23 AM:

> How were you able to identify that a particular IP/IP's are the source of 
> spam attack on your mail server?

A trap and a Mark I eyeball, Senderbase reputation data, examining rDNS
within a netblock, etc.

> After identifying that a particular IP/IP's is the source of attack how were 
> you able to update your local block lists automatically?

I don't update my block lists automatically, but manually, see above.
Local block lists are not a substitute for dnsbls, but an additional
tool used to kill spam sources that aren't listed (yet) by the dnsbls.
Very few dnsbls catch snowshoe spammers because they rely on volume trap
data from individual IPs.  The snowshoe method was invented specifically
to bypass dnsbls.  Spamhaus now has a list specifically targeting
dnsbls, and Invaluement has a paid dnsbl that is very effective at
catching snowshoe.  The Spamhaus snowshoe list is very new.

> For how long did you maintain the IP/IP's record in your local block lists 
> and refreshed them?

Permanently in almost all cases.  Dealing with scorched earth netblocks
is the ISP's responsibility, not mine.  They create the mess by
knowingly assigning spammers to their /24s, /20s, etc, so it's up to
them to clean it up.  Again, local lists aren't a substitute for dnsbls,
so there is no reason to 'refresh' or 'expire' listings in a local block
list, as far as I'm concerned.  I do very thorough analysis before
adding a netblock, and I'm adding maybe only a couple of small ranges a
week.

Think of local block lists as an extremely focused/targeted tool used to
kill spam sources that aren't yet in the dnsbls or likely won't be
listed by dnsbls.  Use them to "pick up the slack" so to speak.

Hope this helps.  Also, you may wish to join spam-l.com to learn more
about various methods used in fighting spam.

--
Stan

Re: mx fails due to typo on remote dns

[Simon Waters]

On Monday 16 November 2009 15:08:08 Eero Volotinen wrote:
> > Possibly make sense for DNS servers to reject such records? I have seen a
> > proliferation of same, most of which were cut and paste from Google's web
> > page.
>
> Sounds like very poor dns management, maybe you can change dns service
> provider?

I think you misunderstand, I see these in other peoples domains.

I'm fear changing DNS service provider isn't going to fix the rest of the 
Internet, if only it were that easy.

I'm thinking the recursive servers should growl and moan, although I'm not 
100% sure the standards disallow them (they use to - RFC 1035).

Re: mx fails due to typo on remote dns

[Eero Volotinen]

Possibly make sense for DNS servers to reject such records? I have seen a
proliferation of same, most of which were cut and paste from Google's web
page.


Sounds like very poor dns management, maybe you can change dns service  
provider?



--
Eero

Re: mx fails due to typo on remote dns

[Simon Waters]

On Monday 16 November 2009 14:27:19 Eero Volotinen wrote:
> Quoting Laurence Moughan :
> > Thanks Eero,
> >
> > But im concerned that more will fail in future - should my postfix
> > be able to resolve this ( the groupwise system can and both are
> > pointing at same ns )
>
> No, ask dns admin to fix that dns zone.

Looks also like one of the delegated name servers is not responding, and the 
delegation includes only 2 of 4 servers, both delegated servers on the same 
network.

Possibly make sense for DNS servers to reject such records? I have seen a 
proliferation of same, most of which were cut and paste from Google's web 
page.

 Simon

Re: mx fails due to typo on remote dns

[Eero Volotinen]

Quoting Laurence Moughan :


Thanks Eero,

But im concerned that more will fail in future - should my postfix   
be able to resolve this ( the groupwise system can and both are   
pointing at same ns )




No, ask dns admin to fix that dns zone.

--
Eero

Re: mx fails due to typo on remote dns

[Laurence Moughan]

Thanks Eero,
 
But im concerned that more will fail in future - should my postfix be able to 
resolve this ( the groupwise system can and both are pointing at same ns ) 
 
Thanks
 
Laurence

>>> Eero Volotinen  16/11/09 14:16:51 >>>

Quoting Laurence Moughan :

> Hi all,
>
>
> Someo of my mail destinations failing, due to unable to find mx,
>
> However when i DIG i see the mx record, but has a typo ( the remote   
> needs to fix thier dns )

> My postfix fails to find an mx
>
> (Host or domain name not found. Name service error for   
> name=EUROCOMMERCE.IE type=MX: Host not found, try again)
>  alan.wy...@eurocommerce.ie
>
>
> My postfix is 2.2 - do later postfix release cater for remote dns   
> typos of this kind ?
>
> My oiffice mail server ( groupwise )  seems to be able to cope with   
> the typo and find mx, just my postfix server fails.

Err. Ask remote to fix dns server or if you want ugly hack, then run  
that zone on your own dns..

--
Eero

Re: Log per domain

[Jaroslaw Grzabel]

ram wrote:
>
> You can write a parser and dump into a database.
> Give every domain a UI to access the database. That is much better.
>
> Thanks
> Ram
> PS:
> The parser may not be so neat because postfix unfortunately does not
> log in sender , recipient , sent and size on a single line
>
Hi,

OK, let's forget about it. I thought it's something simpler. It's not so
urgent so... thank you for all answers.

Regards,
Jarek

Re: mx fails due to typo on remote dns

[Eero Volotinen]

Quoting Laurence Moughan :


Hi all,


Someo of my mail destinations failing, due to unable to find mx,

However when i DIG i see the mx record, but has a typo ( the remote   
needs to fix thier dns )



My postfix fails to find an mx

(Host or domain name not found. Name service error for   
name=EUROCOMMERCE.IE type=MX: Host not found, try again)

 alan.wy...@eurocommerce.ie


My postfix is 2.2 - do later postfix release cater for remote dns   
typos of this kind ?


My oiffice mail server ( groupwise )  seems to be able to cope with   
the typo and find mx, just my postfix server fails.


Err. Ask remote to fix dns server or if you want ugly hack, then run  
that zone on your own dns..


--
Eero

mx fails due to typo on remote dns

[Laurence Moughan]

Hi all,
 
 
Someo of my mail destinations failing, due to unable to find mx,
 
However when i DIG i see the mx record, but has a typo ( the remote needs to 
fix thier dns ) 
 
; <<>> DiG 9.3.2 <<>> @localhost eurocommerce.ie MX ; (2 servers found) ;; 
global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: 
NOERROR, id: 5270 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, 
ADDITIONAL: 0  ;; QUESTION SECTION: ;eurocommerce.ie.   IN  MX  
;; ANSWER SECTION: eurocommerce.ie. 3151IN  MX  20 
cluster8a.eu.messagelabs.com\032. eurocommerce.ie.   3151IN  MX  10 
cluster8.eu.messagelabs.com.  ;; Query time: 1 msec ;; SERVER: 
127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 16 14:46:36 2009 ;; MSG SIZE  rcvd: 
121 See the ( \032)  trailing commas on the line containing the mx also seem to 
fail me.
 
My postfix fails to find an mx
 
(Host or domain name not found. Name service error for name=EUROCOMMERCE.IE 
type=MX: Host not found, try again)
 alan.wy...@eurocommerce.ie

 
My postfix is 2.2 - do later postfix release cater for remote dns typos of this 
kind ?
 
My oiffice mail server ( groupwise )  seems to be able to cope with the typo 
and find mx, just my postfix server fails.
 
Thanks
 
laurence
 
 

Re: Log per domain

[ram]

On Mon, 2009-11-16 at 10:51 +, Jaroslaw Grzabel wrote:

> Magnus Bäck wrote:
> > On Mon, November 16, 2009 10:58 am, Jaroslaw Grzabel said:
> >
> >   
> >> Is there any way to configure postfix to create separate log file for
> >> every domain it keeps ?
> >> 
> >
> > No. Postfix needs to start logging before it even knows to which domain a
> > log message pertains.
> >
> >   
> Thank you Magnus,
> 
> I had a hope there is something like a built-in wrapper which may split
> the logs into domains logs.
> 

You can write a parser and dump into a database. 
Give every domain a UI to access the database. That is much better. 

Thanks
Ram
PS:
The parser may not be so neat because postfix unfortunately does not log
in sender , recipient , sent and size on a single line

Re: increase queue lifetime

[lst_hoe02]

Zitat von "Kammen van, Marco, Springer SBM NL" :


Hi All,



Because of a crashed exchange server we need to queue messages longer on
our smarthost then usual.

I want to increase the time messages are queued to at least 2 weeks...



Is changing the 'maximal_queue_lifetime' in main.cf sufficient to
accomplish this?


Thanks!


You also *may* want to adjust "delay_warning_time" dependant if you  
want the senders to know that you are in trouble...


Regards

Andreas

RE: Adding spam attack IP's to DNSRBL providers

[Sharma, Ashish]

Stan,

Thanks for the reply and showing me a way.

Can you elaborate on your solution ?

Some of my doubts arise from :

>I started my own local block lists
>implemented in various Postfix access tables.  It has been very
>effective, especially against snowshoe spammers.

>http://www.postfix.org/access.5.html
>http://www.postfix.org/cidr_table.5.html

How were you able to identify that a particular IP/IP's are the source of spam 
attack on your mail server?

After identifying that a particular IP/IP's is the source of attack how were 
you able to update your local block lists automatically?

For how long did you maintain the IP/IP's record in your local block lists and 
refreshed them?

Thanks in advance

Ashish Sharma

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Stan Hoeppner
Sent: Tuesday, November 03, 2009 8:10 PM
To: postfix-users@postfix.org
Subject: Adding spam attack IP's to DNSRBL providers

Sharma, Ashish put forth on 11/3/2009 3:58 AM:
> Hello,
> 
> I have a Postfix e-mail receiving server setup.
> 
> I have applied the following setting in my Postfix main.cf file:
> 
> smtpd_recipient_restrictions =
>   reject_unauth_destination,
>   reject_rbl_client sbl-xbl.spamhaus.org,
>   reject_rbl_client bl.spamcop.net
>   permit
> 
> for checking the mails with DNSRBL providers.
> 
> Since Postfix has custom built RBL check, I want to know if a certain IP
> address is continuously attacking with spam on my e-mail server, then
> how can I get it added with the following DNSRBL provider list:
> 
>1. Spamcop
>2. Spamhaus

Short answer:  For most dnsbls you can't.  You can report spam to
Spamcop and it _might_ make it into their listing.  You can't report
spam to Spamhaus at all.  They are strictly trap driven or they list
based upon their own research.  With Spamhaus, you can report entire
spammy networks, but your research needs to be thorough and dead on, and
this must be done through back channel contacts AFAIK.  They have no
official mechanism for receiving reports.

You seem to be at the same point I was a couple of years ago--only using
dnsbls and no local lists and filters.  At the time, I desired to, and
attempted to do the same thing you desire, to report the spam to the
dnsbls hoping they'd list the senders.  After I learned that's not a
realistic possibility or solution, I started my own local block lists
implemented in various Postfix access tables.  It has been very
effective, especially against snowshoe spammers.

http://www.postfix.org/access.5.html
http://www.postfix.org/cidr_table.5.html

Also, if you will never need to receive emails from certain countries,
you can smtp block their entire address space (or firewall it for that
matter) using http://ipdeny.com   I use this to great effect, blocking
around 1/4 to 1/3 of all inbound spam attempts.

--
Stan

Re: increase queue lifetime

[Wietse Venema]

Kammen van, Marco, Springer SBM NL:
> Hi All,
> 
> Because of a crashed exchange server we need to queue messages longer on
> our smarthost then usual.
> 
> I want to increase the time messages are queued to at least 2 weeks...
> 
> Is changing the 'maximal_queue_lifetime' in main.cf sufficient to
> accomplish this?

Also: bounce_queue_lifetime. Otherwise you lose delivery status
notifications. These may be sent by remote or local systems.

Wietse

Re: Log per domain

[Wietse Venema]

Magnus B?ck:
> On Mon, November 16, 2009 10:58 am, Jaroslaw Grzabel said:
> 
> > Is there any way to configure postfix to create separate log file for
> > every domain it keeps ?
> 
> No. Postfix needs to start logging before it even knows to which domain a
> log message pertains.

Besides, one message may have more than one recipient.

Wietse

Re: Log per domain

[Eero Volotinen]

Quoting Jaroslaw Grzabel :


Magnus Bäck wrote:

On Mon, November 16, 2009 10:58 am, Jaroslaw Grzabel said:



Is there any way to configure postfix to create separate log file for
every domain it keeps ?



No. Postfix needs to start logging before it even knows to which domain a
log message pertains.



Thank you Magnus,

I had a hope there is something like a built-in wrapper which may split
the logs into domains logs.


Maybe you can use syslog-ng to split logs to domain spesific.

--
Eero

Re: Log per domain

[Jaroslaw Grzabel]

Magnus Bäck wrote:
> On Mon, November 16, 2009 10:58 am, Jaroslaw Grzabel said:
>
>   
>> Is there any way to configure postfix to create separate log file for
>> every domain it keeps ?
>> 
>
> No. Postfix needs to start logging before it even knows to which domain a
> log message pertains.
>
>   
Thank you Magnus,

I had a hope there is something like a built-in wrapper which may split
the logs into domains logs.

Regards,
Jarek

Re: Log per domain

[Magnus Bäck]

On Mon, November 16, 2009 10:58 am, Jaroslaw Grzabel said:

> Is there any way to configure postfix to create separate log file for
> every domain it keeps ?

No. Postfix needs to start logging before it even knows to which domain a
log message pertains.

-- 
Magnus Bäck
mag...@dsek.lth.se

Log per domain

[Jaroslaw Grzabel]

Hi guys,

Is there any way to configure postfix to create separate log file for
every domain it keeps ?

Regards,
Jarek