Re: Relay Exceptions

[Jamie Paul Griffin]

* Noel Jones  [2013-01-23 12:37:28 -0600]:

> On 1/23/2013 12:30 PM, Tom Tucker wrote:
> > 
> > I think I got it.  The ordering is critical.  Thanks
> > 
> > 
> > smtpd_recipient_restrictions =
> > check_recipient_access hash:/etc/postfix/relay_domains  #
> > This will allow clients missing PTR records the ability to relay locally
> > reject_unknown_reverse_client_hostname   # Reject all other
> > clients missing PTR records from sending externally
> > reject_unknown_recipient_domain
> > reject_non_fqdn_sender
> > reject_non_fqdn_helo_hostname
> > reject_invalid_helo_hostname
> > reject_unknown_helo_hostname
> > reject_unlisted_recipient
> > permit_mynetworks  # Permit all other mail traffic both
> > internally and externally
> > reject_unauth_destination
> > 
> > 
> > /etc/postfix/relay_domains
> > mydomain.com OK
> > myotherdomain.com  OK
> 
> 
> 
> The above disables all your UCE controls.

Wouldn't it be better to put $reject_unauth_destination closer to
the top of the restriction class: i.e. after $check_recipient_access?
and then $permit_mynetworks after that?

Like so:

smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/relay_domains,
reject_unauth_destination,
permit_mynetworks,
...

Jamie

Re: how to use a mailing list

[Reindl Harald]

Am 25.01.2013 10:43, schrieb Dibyendra Hyoju:
> I have installed postfix in my local machine and it's working. In the 
> configuration I added following line:
> mynetworks = 127.0.0.0/8 , 192.168.0.0/24 
> 
> 
> However, in the rackspace having IP: 50.57.179.51, I could not get postfix to 
> work. I am not sure what
> configuration is required in the main.cf  file. Please 
> provide your suggestion, what configuration
> in main.cf  I have to make in order to have a working postfix?

first:  you should start wih a subject to your mails
second: provide "postconf -n" output as statet in the welcome message
third:  describe your problem "could not get to work" is no description



signature.asc
Description: OpenPGP digital signature

Re: how to use a mailing list

[Tom Kinghorn]

On 25/01/2013 13:21, Reindl Harald wrote:

first:  you should start wih a subject to your mails
second: provide "postconf -n" output as statet in the welcome message
third:  describe your problem "could not get to work" is no description



And read the documents..( I am not going to say RTFM)

Re: your mail

[Wietse Venema]

Dibyendra Hyoju:
> I have installed postfix in my local machine and it's working. In the
> configuration I added following line:
> mynetworks = 127.0.0.0/8, 192.168.0.0/24
> 
> However, in the rackspace having IP: 50.57.179.51, I could not get postfix
> to work. I am not sure what configuration is required in the main.cf file.
> Please provide your suggestion, what configuration in main.cf I have to
> make in order to have a working postfix?

You don't show the error message, so I won't speculate other than
that you need to update the old network adress and hostname
information.

For more details:

http://www.postfix.org/BASIC_CONFIGURATION_README.html

Wietse

Re: Relay Exceptions

[Noel Jones]

On 1/25/2013 4:29 AM, Jamie Paul Griffin wrote:
> * Noel Jones  [2013-01-23 12:37:28 -0600]:
> 
>> On 1/23/2013 12:30 PM, Tom Tucker wrote:
>>>
>>> I think I got it.  The ordering is critical.  Thanks
>>>
>>>
>>> smtpd_recipient_restrictions =
>>> check_recipient_access hash:/etc/postfix/relay_domains  #
>>> This will allow clients missing PTR records the ability to relay locally
>>> reject_unknown_reverse_client_hostname   # Reject all other
>>> clients missing PTR records from sending externally
>>> reject_unknown_recipient_domain
>>> reject_non_fqdn_sender
>>> reject_non_fqdn_helo_hostname
>>> reject_invalid_helo_hostname
>>> reject_unknown_helo_hostname
>>> reject_unlisted_recipient
>>> permit_mynetworks  # Permit all other mail traffic both
>>> internally and externally
>>> reject_unauth_destination
>>>
>>>
>>> /etc/postfix/relay_domains
>>> mydomain.com OK
>>> myotherdomain.com  OK
>>
>>
>>
>> The above disables all your UCE controls.
> 
> Wouldn't it be better to put $reject_unauth_destination closer to
> the top of the restriction class: i.e. after $check_recipient_access?
> and then $permit_mynetworks after that?
> 
> Like so:
> 
> smtpd_recipient_restrictions =
>   check_recipient_access hash:/etc/postfix/relay_domains,
>   reject_unauth_destination,
>   permit_mynetworks,
>   ...
> 
> Jamie
> 


Generally yes.

In this particular case -- a host not connected to the internet with
very unusual requirements -- no, it works as intended already and
that change would "break" it.

This particular case could be simplified to:
   permit_auth_destination
   reject_unknown_reverse_client_hostname
   permit_mynetworks
   reject

This is not a useful example for 99%+ of users, except maybe as an
exercise in the importance of restriction order to meet specific
requirements.



  -- Noel Jones

misconfiguration standard spf

[ml]

hello guys


hello I'm fine and everything is going well on the whole better. I want
to evoke a thought higher of us. I followed the outstanding issues
lately on hotmail and problems of validation spf (the spf is: do the
simplest and shortest possible). I noticed the strange behavior in my
validation spf
my spf returns this
~]$ host -ttxt lists.fakessh.eu
lists.fakessh.eu descriptive text "spf2.0/pra   ip4:46.105.34.177
ip4:91.121.7.86 ?all"
lists.fakessh.eu descriptive text "v=spf1  ip4:46.105.34.177
ip4:91.121.7.86  ?all"
lists.fakessh.eu descriptive text "spf2.0/mfrom ip4:46.105.34.177
ip4:91.121.7.86 ~all"

I wonder this thing

describes why the standard if I remember correctly if there is no
presence of spf2 valid spf1 more
I have noticed this by looking logs of my mail server in my case some
providers only valid spf1 abstain from spf2, meet the other two and
therefore ignore the ok spf1 (often time error sid Marid openssl
mailling often) to meet the other spf2 but only test the spf1 and are ok
and still another test both as hotmail and we are left with paradoxes
room with sending malicious spam spf1 ok senderid ok not tagged spam
(feat exploit http://img528.imageshack.us/img528/1739/spf2virii.jpg
my modified version of nc )

about spf I think we should amend the standards for testing spf1 and or
spf2

Wietse ?

when do you think


-- 
gpg --keyserver pgp.mit.edu --recv-key C2626742
http://about.me/fakessh


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Sufficiently locked down?

[btb]

On Jan 24, 2013, at 22.57, Stan Hoeppner wrote:

>> commendably, he is at least making an attempt to properly use submission 
>> [which, btw, is far from "useless" and has nothing to do with the route a 
>> packet might take].
> 
> The primary features of the submission service are TLS encryption and
> authentication.

the primary feature of the submission service is to provide different ports for 
servers and clients, so that the appropriate policy can be applied to each, 
independently.  these policies are quite obviously completely subjective, and 
may or may not include smtp auth [and thus with it, encryption].  the 
submission protocol defines a port for clients to use, period.  it does not say 
"use port 587, unless you are talking to localhost, in which case use port 25."

> Even the user logging of submission is useless, as it's a single user box.


hmm, not sure where you got this idea.  there have been no such statements from 
the op.

-ben

Re: Sufficiently locked down?

[Stan Hoeppner]

On 1/25/2013 10:18 AM, b...@bitrate.net wrote:
> On Jan 24, 2013, at 22.57, Stan Hoeppner wrote:

>> The primary features of the submission service are TLS encryption and
>> authentication.
> 
> the primary feature of the submission service is to provide different ports 
> for servers and clients, 

You might want to read this before repeating your statement above:

http://www.engardelinux.org/modules/index/list_archives.cgi?list=postfix-users&page=0425.html&month=2012-03

Note that the port is TCP 587, that TLS is enabled, and auth is enabled.
 The submission service isn't simply for separating traffic on different
ports.  It's for secure submission of user mail with auth, over the
wire.  It is not intended for submission via IPC.

> ...the submission protocol defines a port for clients to use, period.  

Again, not true.  See above.

>> Even the user logging of submission is useless, as it's a single user box.
> 
> hmm, not sure where you got this idea.  there have been no such statements 
> from the op.

Long experience.  The only reason to use the submission service in an
IPC scenario is on a multiuser webmail server with local Postfix.  The
submission service logs the authenticated user name.  So even though the
encryption and authentication are useless for security reasons in an IPC
submission scenario, having the username logged is advantageous.  For
instance if a user spams, is being abusive, sends threats, etc, the
admin can track down who sent the emails.

This is the only scenario where using the submission service for IPC
submission makes any sense.  So again, for a single user box running
both the MUA and Postfix, one is better off using the standard smtpd
server on TCP 25, or creating a non TLS/auth submission service on an
arbitrary port.

-- 
Stan

Re: Sufficiently locked down?

[btb]

On Jan 25, 2013, at 13.29, Stan Hoeppner wrote:

> On 1/25/2013 10:18 AM, b...@bitrate.net wrote:
>> On Jan 24, 2013, at 22.57, Stan Hoeppner wrote:
> 
>>> The primary features of the submission service are TLS encryption and
>>> authentication.
>> 
>> the primary feature of the submission service is to provide different ports 
>> for servers and clients, 
> 
> You might want to read this before repeating your statement above:
> 
> http://www.engardelinux.org/modules/index/list_archives.cgi?list=postfix-users&page=0425.html&month=2012-03


the sample configuration postfix offers does not define the submission 
protocol.  rather, it emphasizes my point that it is a personal choice.

at this point, this thread has become non beneficial to the op, and should be 
suspended until he returns with the additional requested data.

-ben

Upgrade for Postfix & Mailman

[Jeff Bernier]

Hello All,

I am currently running Mailman (2.1.14) and Postfix (2.4.3) on an aging Mac
OS X server (10.5.8). Mailman and Postfix on this system are Apple's
implementation on their platform of course. Apple no longer supports the
Xserve platform, and I am in need of replacing this system, and upgrading
to newer versions of Postfix and Mailman.

We use Postfix for our on campus SMTP Gateway, and Mailman for a small
number of active lists. The traffic is light.

Can anyone recommend a good replacement to this? Recommended Unix/Linux? Is
a VM environment an option?

I would like to get away from the Mac solution, and set up some flavor of
Unix with more current versions of Postfix and Mailman. I know this is a
very broad question, but I have a blank canvas here... just looking for a
direction to go in.

Any suggestions are appreciated.

Thanks



Jeff Bernier
Email & Accounts Administration
Rhode Island School of Design
20 Washington Place, Providence RI 02903
401.454.6168

Re: Upgrade for Postfix & Mailman

[btb]

On Jan 25, 2013, at 15.07, Jeff Bernier wrote:

> Hello All,
> 
> I am currently running Mailman (2.1.14) and Postfix (2.4.3) on an aging Mac
> OS X server (10.5.8). Mailman and Postfix on this system are Apple's
> implementation on their platform of course. Apple no longer supports the
> Xserve platform, and I am in need of replacing this system, and upgrading
> to newer versions of Postfix and Mailman.

you may already know this, but do note that while the xserve and mac os x 
server have gone away, the underlying components themselves [apple and 
otherwise] have not, and are now just hidden away within "regular" mac os x.  
apple sells software that you add to your standard install to provide the apple 
management mechanisms as were found in os x server.  of course, this means that 
an xserve is not needed either, since it runs just fine on any mac.

that being said, *do not* misinterpret this information as a suggestion or 
encouragement that you do this - it is intended only as information, for the 
sake of it.  quite to the contrary, if i were to offer encouragement, it would 
be to move away from apple products for this sort of thing, but not because the 
platform has changed.

> We use Postfix for our on campus SMTP Gateway, and Mailman for a small
> number of active lists. The traffic is light.
> 
> Can anyone recommend a good replacement to this? Recommended Unix/Linux?

whatever os you prefer is likely perfectly fine.  i'd encourage you to use an 
operating system you're comfortable with rather than a particular os just for 
the sake of postfix.  what's more important is that you run reasonably current 
versions of the software - this may or may not mean using the version available 
in the operating system's software repositories.

> Is a VM environment an option?

in a nutshell - certainly, of course.  many people routinely run mail servers 
on virtual guests.  degree of utilization can always become a factor, be it a 
virtual guest or otherwise, but even moderately high loads can be quite 
efficiently accommodated by a competent admin.

-ben

Re: Upgrade for Postfix & Mailman

[Larry Stone]

On Fri, 25 Jan 2013, b...@bitrate.net wrote:


On Jan 25, 2013, at 15.07, Jeff Bernier wrote:


Hello All,

I am currently running Mailman (2.1.14) and Postfix (2.4.3) on an aging Mac
OS X server (10.5.8). Mailman and Postfix on this system are Apple's
implementation on their platform of course. Apple no longer supports the
Xserve platform, and I am in need of replacing this system, and upgrading
to newer versions of Postfix and Mailman.


you may already know this, but do note that while the xserve and mac os 
x server have gone away, the underlying components themselves [apple and 
otherwise] have not, and are now just hidden away within "regular" mac 
os x.  apple sells software that you add to your standard install to 
provide the apple management mechanisms as were found in os x server. 
of course, this means that an xserve is not needed either, since it runs 
just fine on any mac.


that being said, *do not* misinterpret this information as a suggestion 
or encouragement that you do this - it is intended only as information, 
for the sake of it.  quite to the contrary, if i were to offer 
encouragement, it would be to move away from apple products for this 
sort of thing, but not because the platform has changed.


While I have no experience with OS X Server, I have been running a mail 
server (and related software) on OS X (Client) for several years. Most 
software for the "server" was installed from sources although I used the 
Apple provided versions of Postfix and amavisd-new. However, I am 
currently still running Lion on that machine and from what testing I've 
done, do not see an easy path forward to Mountain Lion (the current OS X 
version). In the upgrade to Mountain Lion, a lot of stuff was moved and 
some things (like amavisd-new) removed.


One of the problems of the past was Apple's constant behind the scenes 
changes which required some reconfiguration at every major upgrade. If I 
do ever move forward with trying to upgrade, I most likely will go "build 
from sources" for everything (ignoring Apple's provided Postfix) with 
everything in /usr/local (which Apple so far does not touch) so that I am 
not at the whim of their changes.


-- Larry Stone
   lston...@stonejongleux.com

Re: Upgrade for Postfix & Mailman

[Reindl Harald]

Am 25.01.2013 23:46, schrieb Larry Stone:
> One of the problems of the past was Apple's constant behind the scenes 
> changes which required some reconfiguration
> at every major upgrade. If I do ever move forward with trying to upgrade, I 
> most likely will go "build from
> sources" for everything (ignoring Apple's provided Postfix) with everything 
> in /usr/local (which Apple so far does
> not touch) so that I am not at the whim of their changes

and that is why i said 10 years ago apple is crap on a server
nobody believed me and sweared it is the bast you can have

throw away this carp and learn how to work with a real
operating system like linx or bsd



signature.asc
Description: OpenPGP digital signature

Re: Recommendations for antivirus

[Jeroen Geilman]

On 01/16/2013 10:55 PM, TFML wrote:

I'm running a server on average week we receive 14,000, send 19,000, and in 
total deferred/bounced/rejected 5,000


Are you certain of those numbers ?

For any publically-reachable MX host, the amount of spam rejected is AT 
LEAST 10 times the amount of desirable mail accepted.


Over 90% of all mail is spam, sadly; this is near-universal.

Of course, you might be deploying a non-postfix solution as MX frontend, 
like Barracuda, but for an exposed MX host, 14:5 Ham/Spam is an entirely 
unbelievable ratio.



--
J.