Re: Rules on incoming email

[Stan Hoeppner]

Jos Chrispijn put forth on 9/19/2010 11:11 AM:
>  I have this email client that takes care of distrubition of email to
> different mail folders.
> As I now started to read my email with a mobile phone, there is a load
> of messages that aren't sorted, as my 'home client' hasn't taken care of
> that.
> Is there a way of using rules on my email the moment it comes in so that
> I am not dependend on my mail clients' rules anymore?

I was in a similar situation not long ago using TBird rules to do my
message sorting into IMAP folders.  When accessing my mail vi my
Roundcube webmail server nothing was sorted.  I grew tired of this.  I
was already using Dovecot for my IMAP server, so I converted to using
Dovecot LDA for delivery instead of Postfix local, and using Sieve
scripts to sort the mail into folders.

If you don't use Dovecot IMAP, you can use a number of plugin delivery
agents with Postfix, such as Procmail, Maildrop, and their respective
scripting languages for sorting.

-- 
Stan

Maximum Concurrent Connections

[Avinash Pawar // Viva]

Hi,

I want to know how we can increase the maximum number of concurrent
connections.

So please tell me at what extent I can increase value and where it is
stored?

-- 
Incase of any further queries, Please feel free to mail me or contact me on
the numbers provided below.

Thanks & Regards,
Avinash Pawar
Software Engineer.

Viva Infomedia Pvt. Ltd.
242, Oshiwara Industrial Centre,
New Link Road, Opp. Oshiwara Bus Depot,
Goregaon West, Mumbai 400104.
Direct: +91.22.40310356
Board: +91.22.40310310

Viva Infomedia: Awarded as Best SME (E-Commerce) at CNBC Emerging India
Awards 2009

Re: Maximum Concurrent Connections

[lst_hoe02]

Zitat von Avinash Pawar // Viva :


Hi,

I want to know how we can increase the maximum number of concurrent
connections.

So please tell me at what extent I can increase value and where it is
stored?


Have a look for "default_process_limit"  
(http://www.postfix.org/postconf.5.html#default_process_limit) or  
change the value for smtpd in master.cf. The location of  
main.cf/master.cf files will depend on your installation, Linux  
typically uses /etc/postfix/.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

SPF Softfail question

[Kammen van, Marco, Springer SBM NL]

Hi All,

Not really Postfix related, but maybe you can share your thoughts...

Received a mail today from a user that sent a e-mail which immediately 
bounced..

The bounce message said:

host bla.bla.bla[xxx.xxx.xxx] said: 550-SPF check SOFT fail. Your are not 
allowed to send mail from 550 ourdomain.com. 
(in reply to RCPT TO command)

As far as I understand from the whole SPF perspective, shouldn't a Soft Fail be 
a 4** error and re-try, instaid of a hard 550 and just bounce the message?
 
With Kind Regards,


- 
Marco van Kammen
Springer Science+Business Media
System Manager & Postmaster 
- 
van Godewijckstraat 30 | 3311 GX
Office Number: 05E21 
Dordrecht | The Netherlands 
-  
tel 
 +31(78)6576446
fax 
 +31(78)6576302

- 
www.springeronline.com 
www.springer.com
- 

Re: SPF Softfail question

[Simon Waters]

On Monday 20 September 2010 14:18:16 Kammen van, Marco, Springer SBM NL wrote:
> 
> Not really Postfix related, but maybe you can share your thoughts...

Definitely not Postfix related.

> As far as I understand from the whole SPF perspective, shouldn't a Soft
> Fail be a 4** error and re-try, 

Softfail introduces ambiguity as to whether an email is forged or not and then 
leaves the decision to the receiving server, so one shouldn't be surprised in 
this spam rich world if they choose to reject it.

Re: SPF Softfail question

[Michael Orlitzky]

On 09/20/2010 09:29 AM, Simon Waters wrote:
> On Monday 20 September 2010 14:18:16 Kammen van, Marco, Springer SBM NL wrote:
>>
>> Not really Postfix related, but maybe you can share your thoughts...
> 
> Definitely not Postfix related.
> 
>> As far as I understand from the whole SPF perspective, shouldn't a Soft
>> Fail be a 4** error and re-try, 
> 
> Softfail introduces ambiguity as to whether an email is forged or not and 
> then 
> leaves the decision to the receiving server, so one shouldn't be surprised in 
> this spam rich world if they choose to reject it.

If you're going to try to contact the recipient, this might help:

  http://www.openspf.org/RFC_4408#op-result-softfail

but I would probably just fix the SPF record.

Re: Rules on incoming email

[Jorge Armando Medina]

Adam Tauno Williams wrote:
> On Sun, 2010-09-19 at 18:11 +0200, Jos Chrispijn wrote:
>   
>> I have this email client that takes care of distrubition of email to 
>> different mail folders.
>> As I now started to read my email with a mobile phone, there is a load 
>> of messages that aren't sorted, as my 'home client' hasn't taken care of 
>> that.
>> Is there a way of using rules on my email the moment it comes in so that 
>> I am not dependend on my mail clients' rules anymore?
>> 
>
> If you are using the amazing Cyrus IMAP  then
> you just setup SIEVE filters and everything will be sorted/discarded
> upon deliver;  but this immediately following the step after which
> Postfix is out of the picture.
>
>   
I and my users prefer to use horde webmail with ingo for server side
filtering using sieve from dovectot.


-- 
Jorge Armando Medina
Computación Gráfica de México
Web: http://www.e-compugraf.com
Tel: 55 51 40 72, Ext: 124
Email: jmed...@e-compugraf.com
GPG Key: 1024D/28E40632 2007-07-26
GPG Fingerprint: 59E2 0C7C F128 B550 B3A6  D3AF C574 8422 28E4 0632




signature.asc
Description: OpenPGP digital signature

Re: conditional "recipient address verification" - how to do?

[Eugene V. Boontseff]

On 19.09.2010 02:30, pf at alt-ctrl-del.org wrote:


But here is what I do:
transport_maps = destination_for_each_domain
relay_recipient_maps = list_of_valid_recipients

lots_of_tests, reject_unauth_destination, reject_unlisted_recipient, 
lots_of_other_tests, reject_unverified_recipient, permit


The final reject_unverified_recipient, prevents me from accepting and 
bouncing mail for users that always have full mailboxes.




What are the values for the parameters
address_verify_positive_expire_time
address_verify_positive_refresh_time
address_verify_negative_expire_time
address_verify_negative_refresh_time
you use?

--
Eugene

Re: Rules on incoming email

[Jos Chrispijn]

 On 20-9-2010 9:11, Stan Hoeppner wrote:

I was in a similar situation not long ago using TBird rules to do my
message sorting into IMAP folders. When accessing my mail vi my
Roundcube webmail server nothing was sorted. I grew tired of this. I
was already using Dovecot for my IMAP server, so I converted to using
Dovecot LDA for delivery instead of Postfix local, and using Sieve
scripts to sort the mail into folders.

That is a good tip, I allready use Dovecot IMAP. Thanks
Jos Chrispijn.

Can postfix guarantee durability (fsync)?

[Yang Zhang]

Can postfix be configured to guarantee durable email receipt?

E.g., can it be sure to fsync the mbox/Maildir file and/or directory
before it acknowledges successful receipt of an email?
--
Yang Zhang
http://yz.mit.edu/

Re: Can postfix guarantee durability (fsync)?

[Wietse Venema]

Yang Zhang:
> Can postfix be configured to guarantee durable email receipt?

This is required by internet mail RFC and therefore not configurable.

Wietse

> E.g., can it be sure to fsync the mbox/Maildir file and/or directory
> before it acknowledges successful receipt of an email?

Re: Can postfix guarantee durability (fsync)?

[Jeroen Geilman]

On 09/20/2010 08:37 PM, Yang Zhang wrote:

Can postfix be configured to guarantee durable email receipt?

E.g., can it be sure to fsync the mbox/Maildir file and/or directory
   


No, but it does guarantee durability from the receiving SMTP session to 
the delivering process.

This CAN be delivery to a mailbox.


before it acknowledges successful receipt of an email?
   


That would be the end of the SMTP session.
No MTA guarantees final mail delivery *before* returning the SMTP 
status, that would make queueing a travesty of epic proportions.

You want queueing.
Yes, really, you do .

--
J.

Re: Forwarding emails, quick question

[Brian Pribis]

Ok, let me do this another way, since I'm clearly not understanding
how this is suppose to work.  I read:
http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual

Am I understanding this correctly?  If I put

addr...@virtual_domain m...@gmail.com

Shouldn't it simply forward email from the first address to my gmail account?

What happens is the mail does go to gmail but if I hit "reply" it
tries to mail back to addr...@vitual_domaininstead of the original
sender.

I do not have this in any other file, btw, and I've made sure I ran
postmap and restarted.

I'm sure this is part of my overall problem and I'm just missing
something stupid, but this has taken WAY to long to set up and I'm
sorta at the end of my wits here.  Any more help would be appreciated.
 Thanks.

brian

On Fri, Sep 17, 2010 at 12:10 PM, Brian Pribis  wrote:
> On 9/16/10 7:56 PM, Sahil Tandon wrote:
>>
>> On Thu, 2010-09-16 at 22:40:10 +0200, Jeroen Geilman wrote:
>>
>>> On 09/16/2010 10:33 PM, Brian Pribis wrote:

 When I receive an email addressed to, say, t...@virtual_domain.com,
 I want this forwarded to someone_e...@virtual_domain.com.

 I have this done in the virtual file and everything appears to work,
 except one thing I can't understand:
>>>
>>
>> Virtual aliasing is recursive, so the above mapping should be fine as
>> long as someone_e...@virtual_domain.com is eventually mapped to an
>> actual mailbox/address. This is why the OP observes that it "works" in
>> the sense that test mail arrives in the intended mailbox.
>>
 When the email arrives in my mail client it arrives with
 t...@virtual_domain.com in the CC field.
>>
>> As noted in the ADDRESS_REWRITING_README, virtual alias mapping affects
>> *only* the envelope recipient address, not the headers.
>>
>
> Sahil,
>
> Ok, thanks.  That clarifies some things.  But it doesn't fix the problem.
>  If I add the "forward" to the canonical file (actually, canonical-receive
> in this case), the address gets rewritten so when the person replies it will
> reply to what the address was rewritten to, which is what you would expect
> but not what I want.
>
> So the virtual file is what I want to use because I want people to be
> thinking the original alias is a valid email address and continue to send to
> it.
>
> But there is a problem with the mail agent.  I'm now starting to think this
> is a localized problem with the agent (in this case Thunderbird). If I put
> the following in the virtual file:
>
> br...@letterpress.cc brian
> c...@letterpress.cc br...@letterpress.cc
>
> the email will be picked up by thunderbird with a header like the following
> which thunderbird wants to reply to br...@boxcarpress.com and CC to
> c...@letterpress.cc
>
> From br...@boxcarpress.com  Fri Sep 17 11:24:27 2010
> Return-Path: 
> X-Original-To: c...@letterpress.cc
> Delivered-To: br...@boxcarmail.com
> Received: from boxcarmail.com (localhost [127.0.0.1])
>        by boxcarmail.com (Postfix) with ESMTP id 9C0C45C02A
>        for ; Fri, 17 Sep 2010 11:24:27 -0400 (EDT)
> Received: by boxcarmail.com (Postfix, from userid 58)
>        id 7FDBB5C029; Fri, 17 Sep 2010 11:24:27 -0400 (EDT)
> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on boxcarmail.com
> X-Spam-Level: **
> X-Spam-Status: No, score=2.5 required=8.0
> tests=MR_NOT_ATTRIBUTED_IP,NO_RDNS,
>        ONE_WORD_SUBJECT,RDNS_NONE autolearn=no version=3.3.1
> Received: from ns34.mmaweb.net (unknown [64.71.129.15])
>        by boxcarmail.com (Postfix) with ESMTP id 3DCDE5C024
>        for ; Fri, 17 Sep 2010 11:24:25 -0400 (EDT)
> Received: from Brian-Pribiss-iMac.local (rrcs-208-125-111-62.nys.biz.rr.com
> [208.125.111.62])
>        by ns34.mmaweb.net (8.13.7/8.13.7) with ESMTP id o8HFOQhd009640
>        for ; Fri, 17 Sep 2010 11:24:26 -0400 (EDT)
> Message-ID: <4c938823.7040...@boxcarpress.com>
> Date: Fri, 17 Sep 2010 11:24:19 -0400
> From: Brian Pribis 
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
> MIME-Version: 1.0
> To: c...@letterpress.cc
> Subject: test
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> X-Virus-Scanned: ClamAV using ClamSMTP
> Status: RO
>
>
> If I send to br...@letterpress.cc I get a header:
>
>
> From br...@boxcarpress.com  Fri Sep 17 11:25:24 2010
> Return-Path: 
> X-Original-To: br...@letterpress.cc
> Delivered-To: br...@boxcarmail.com
> Received: from boxcarmail.com (localhost [127.0.0.1])
>        by boxcarmail.com (Postfix) with ESMTP id 9E93C5C02A
>        for ; Fri, 17 Sep 2010 11:25:24 -0400 (EDT)
> Received: by boxcarmail.com (Postfix, from userid 58)
>        id 8523D5C029; Fri, 17 Sep 2010 11:25:24 -0400 (EDT)
> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on boxcarmail.com
> X-Spam-Level: *
> X-Spam-Status: No, score=2.0 required=8.0
> tests=MR_NOT_ATTRIBUTED_IP,NO_RDNS,
>        RDNS_NONE autolearn=no version=3.3.1
> Receiv

Re: Can postfix guarantee durability (fsync)?

[Yang Zhang]

On Mon, Sep 20, 2010 at 12:02 PM, Jeroen Geilman  wrote:
> On 09/20/2010 08:37 PM, Yang Zhang wrote:
>>
>> Can postfix be configured to guarantee durable email receipt?
>>
>> E.g., can it be sure to fsync the mbox/Maildir file and/or directory
>>
>
> No, but it does guarantee durability from the receiving SMTP session to the
> delivering process.
> This CAN be delivery to a mailbox.
>
>> before it acknowledges successful receipt of an email?
>>
>
> That would be the end of the SMTP session.
> No MTA guarantees final mail delivery *before* returning the SMTP status,
> that would make queueing a travesty of epic proportions.
> You want queueing.
> Yes, really, you do .

That's fine. My main concern (worded poorly) was preventing data
loss/allowing for eventual delivery, not ensuring final mbox/Maildir
delivery. I just assumed there was no intermediate queuing.

Since there's queuing, does Postfix also handle resuming delivery on recovery?

Just to be clear, if I have this Maildir in my mailbox postmap:

  j...@mydomain.com joe/

and most other settings are the Ubuntu 10.04 postfix defaults, then
postfix will have done an fsync by the time the "250 OK: queued as
12345" comes back, such that if I then immediately power cycle the
server, when it comes back up, the mail will make its way to the final
mbox/Maildir?
-- 
Yang Zhang
http://yz.mit.edu/

Re: Can postfix guarantee durability (fsync)?

[Yang Zhang]

Can you pinpoint the exact RFC & section you're referring to? Thanks.

On Mon, Sep 20, 2010 at 11:51 AM, Wietse Venema  wrote:
> Yang Zhang:
>> Can postfix be configured to guarantee durable email receipt?
>
> This is required by internet mail RFC and therefore not configurable.
>
>        Wietse
>
>> E.g., can it be sure to fsync the mbox/Maildir file and/or directory
>> before it acknowledges successful receipt of an email?
>



-- 
Yang Zhang
http://yz.mit.edu/

Re: Can postfix guarantee durability (fsync)?

[Wietse Venema]

Yang Zhang:
> Just to be clear, if I have this Maildir in my mailbox postmap:
> 
>   j...@mydomain.com joe/
> 
> and most other settings are the Ubuntu 10.04 postfix defaults, then
> postfix will have done an fsync by the time the "250 OK: queued as
> 12345" comes back, such that if I then immediately power cycle the

No. Postfix replies "250 OK: queued as 12345" when the message is QUEUED.

Wietse

Re: Can postfix guarantee durability (fsync)?

[Wietse Venema]

Yang Zhang:
> Can you pinpoint the exact RFC & section you're referring to? Thanks.

I will give you as home work to study the following documents:

RFC 821
RFC 2821
RFC 5321

These have lots of other good stuff about Internet mail.

Wietse

> On Mon, Sep 20, 2010 at 11:51 AM, Wietse Venema  wrote:
> > Yang Zhang:
> >> Can postfix be configured to guarantee durable email receipt?
> >
> > This is required by internet mail RFC and therefore not configurable.
> >
> > ? ? ? ?Wietse
> >
> >> E.g., can it be sure to fsync the mbox/Maildir file and/or directory
> >> before it acknowledges successful receipt of an email?
> >
> 
> 
> 
> -- 
> Yang Zhang
> http://yz.mit.edu/
> 
> 

Please Help Me Secure My Mail Server

[bper]

Hello,

I have set up a postfix-dovecot server with smtp-auth using sasl by
following this link:
https://help.ubuntu.com/10.04/serverguide/C/postfix.html

It seems to be working OK. The only thing is that when I view my logs, I see
a lot of 'relaying denied', 'noqueue reject', 'too many errors after rcpt',
and 'disconnect' messages from a lot of unknown domain names and ip
addresses.

I'm hoping that this means that the server is secure and doing its job
bouncing mail from unauthorized requests. 

*** Is that true?

Even if it was true, it has to be slowing down the server receiving so many
unauthorized requests. 

*** Is there a way to avoid this or is this just a function of life in the
world of email spam? Would a spam filter like Spamassasin help this type of
issue?

Thanks!
-- 
View this message in context: 
http://old.nabble.com/Please-Help-Me-Secure-My-Mail-Server-tp29744283p29744283.html
Sent from the Postfix mailing list archive at Nabble.com.

Re: Please Help Me Secure My Mail Server

[Matt Hayes]

On 9/20/2010 4:29 PM, bper wrote:
> 
> Hello,
> 
> I have set up a postfix-dovecot server with smtp-auth using sasl by
> following this link:
> https://help.ubuntu.com/10.04/serverguide/C/postfix.html
> 
> It seems to be working OK. The only thing is that when I view my logs, I see
> a lot of 'relaying denied', 'noqueue reject', 'too many errors after rcpt',
> and 'disconnect' messages from a lot of unknown domain names and ip
> addresses.
> 
> I'm hoping that this means that the server is secure and doing its job
> bouncing mail from unauthorized requests. 
> 
> *** Is that true?
> 
> Even if it was true, it has to be slowing down the server receiving so many
> unauthorized requests. 
> 
> *** Is there a way to avoid this or is this just a function of life in the
> world of email spam? Would a spam filter like Spamassasin help this type of
> issue?
> 
> Thanks!


Please provide logs of said entries (pasted into this mailing list
reply) and also output of postconf -n

That's the best way for us to tell if you have any other remaining issues.

However, seeing rejections for relay denied and noqueue reject that are
stopping possible spammers.. definitely a good thing.

-Matt

Re: Can postfix guarantee durability (fsync)?

[Yang Zhang]

On Mon, Sep 20, 2010 at 12:33 PM, Wietse Venema  wrote:
> Yang Zhang:
>> Can you pinpoint the exact RFC & section you're referring to? Thanks.
>
> I will give you as home work to study the following documents:
>
> RFC 821
> RFC 2821
> RFC 5321
>
> These have lots of other good stuff about Internet mail.

I had looked at these and couldn't find any specification of the
guarantees - would you mind pointing out what you're referring to?
Thanks, greatly appreciate it.
--
Yang Zhang
http://yz.mit.edu/

Re: Please Help Me Secure My Mail Server

[Stan Hoeppner]

bper put forth on 9/20/2010 3:29 PM:
> 
> Hello,
> 
> I have set up a postfix-dovecot server with smtp-auth using sasl by
> following this link:
> https://help.ubuntu.com/10.04/serverguide/C/postfix.html
> 
> It seems to be working OK. The only thing is that when I view my logs, I see
> a lot of 'relaying denied', 'noqueue reject', 'too many errors after rcpt',
> and 'disconnect' messages from a lot of unknown domain names and ip
> addresses.
> 
> I'm hoping that this means that the server is secure and doing its job
> bouncing mail from unauthorized requests. 
> 
> *** Is that true?

It's not _bouncing_ mail, it's _REJECTING_ those connections before the
mail is sent.  This is by design, and is a good thing.

> Even if it was true, it has to be slowing down the server receiving so many
> unauthorized requests.

Define "slowing down" in relative terms.  The lowest end cheapest
servers shipping today can reject hundreds of these connections _per
second_ or millions per day without breaking a sweat.  Actually
accepting and queuing mail for delivery can bog an undersized server
down under heavy load, but you'll never run into a problem with spam
rejection bogging down a server--unless you've done something stupid and
allow unlimited concurrent connections.  In that case, if someone
decided to DDOS you with zombie spam, you could run out of memory.
Postfix is configured by default with 100 concurrent connections, IIRC,
so even with as little as 512MB of RAM (or less depending on your
Postfix restrictions/tables/etc) you aren't susceptible to this.

> *** Is there a way to avoid this or is this just a function of life in the
> world of email spam? Would a spam filter like Spamassasin help this type of
> issue?

Lol.  This _is_ rudimentary spam filtering.  That's what those log
entries are telling you.  Do you not understand them because they don't
say "blocked spam"?  heheh.  If you install SA to do the same thing, the
load on your server will _increase_.  If you can reject spam connections
with Postfix _before_ invoking a content filter, you decrease server
load dramatically.

Welcome to mail server operations 101. :)  You've got a lot to learn,
but there's time.  The internet isn't going away tomorrow.  Stick around
and read all the posts.  You can learn quite a bit.

-- 
Stan

Re: Can postfix guarantee durability (fsync)?

[Yang Zhang]

On Mon, Sep 20, 2010 at 12:31 PM, Wietse Venema  wrote:
> Yang Zhang:
>> Just to be clear, if I have this Maildir in my mailbox postmap:
>>
>>   j...@mydomain.com joe/
>>
>> and most other settings are the Ubuntu 10.04 postfix defaults, then
>> postfix will have done an fsync by the time the "250 OK: queued as
>> 12345" comes back, such that if I then immediately power cycle the
>
> No. Postfix replies "250 OK: queued as 12345" when the message is QUEUED.

Doesn't this contradict your original reply that durability is
guaranteed? If there's no fsync, then the message may not have been
persisted to non-volatile storage, and will be lost.

Just trying to understand this basic question, preferably without
having to source-dive or invest considerable time to become an expert
on email or Postfix. Thanks, I appreciate any help.
--
Yang Zhang
http://yz.mit.edu/

Re: Please Help Me Secure My Mail Server

[Noel Jones]

On 9/20/2010 3:29 PM, bper wrote:


Hello,

I have set up a postfix-dovecot server with smtp-auth using sasl by
following this link:
https://help.ubuntu.com/10.04/serverguide/C/postfix.html

It seems to be working OK. The only thing is that when I view my logs, I see
a lot of 'relaying denied', 'noqueue reject', 'too many errors after rcpt',
and 'disconnect' messages from a lot of unknown domain names and ip
addresses.


These are normal messages indicating that postfix is working 
correctly.





I'm hoping that this means that the server is secure and doing its job
bouncing mail from unauthorized requests.

*** Is that true?


quickie definitions:

bounce - accept mail and return it to the (likely forged) 
sender.  BAD.


reject - unwanted mail is not accepted.  Notification of legit 
senders is the responsibility of the sender's mail server.  GOOD.


Your postfix is apparently doing its job rejecting unwanted mail.


For further analysis, show your "postconf -n" and unaltered 
log entries you don't understand.



-- Noel Jones




Even if it was true, it has to be slowing down the server receiving so many
unauthorized requests.

*** Is there a way to avoid this or is this just a function of life in the
world of email spam? Would a spam filter like Spamassasin help this type of
issue?

Thanks!

Re: Can postfix guarantee durability (fsync)?

[Ralf Hildebrandt]

* Yang Zhang :

> > No. Postfix replies "250 OK: queued as 12345" when the message is QUEUED.
> 
> Doesn't this contradict your original reply that durability is
> guaranteed? If there's no fsync, then the message may not have been
> persisted to non-volatile storage, and will be lost.

After the mail had been written to the queue, fsync() is executed. If
fsync() succeeded, the reply "250 OK: queued as ." is sent back to
the client.

So unless fsync() lies, the mail is safely on the disk.

Then the qmgr decides to e.g. invoke local to perform local delivery.
local writes the mail into the Maildir, invokes fsync(). If
fsync() succeeded, the qmgr considers the mail delivered and deletes
the queuefile.

So unless fsync() lies, the mail is safely on the disk.

Your initial question was:
"Can postfix be configured to guarantee durable email receipt?
E.g., can it be sure to fsync the mbox/Maildir file and/or directory
before it acknowledges successful receipt of an email?"

THAT is not possible, since the process which is ACCEPTING the mail
(smtpd) is NOT the same process that is writing to a local mailbox
(local), due due Postfix's non-monolithical design.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Can postfix guarantee durability (fsync)?

[Stan Hoeppner]

Yang Zhang put forth on 9/20/2010 3:46 PM:
> On Mon, Sep 20, 2010 at 12:33 PM, Wietse Venema  wrote:
>> Yang Zhang:
>>> Can you pinpoint the exact RFC & section you're referring to? Thanks.
>>
>> I will give you as home work to study the following documents:
>>
>> RFC 821
>> RFC 2821
>> RFC 5321
>>
>> These have lots of other good stuff about Internet mail.
> 
> I had looked at these and couldn't find any specification of the
> guarantees - would you mind pointing out what you're referring to?
> Thanks, greatly appreciate it.

Take a look at this previous thread on this mailing list.  An OP was
having a performance problem with ~250 msgs/sec and only 1 spindle worth
of throughput for the incoming and active queues (software mirror of two
disks).  He proposed his own solution to the problem (the wrong solution
for obvious reasons) as modifying the Postfix source and _eliminating_
fsync:

http://www.pubbs.net/200911/postfix/9555-how-to-increase-throughput-of-postfix-to-local-user.html

--- postfix-2.5.9/src/global/mail_stream.c.orig 2009-11-05
23:27:23.0 +0300
+++ postfix-2.5.9/src/global/mail_stream.c 2009-11-05 23:27:34.0
+0300
@@ -292,9 +292,9 @@
|| (want_stamp && stamp_path(VSTREAM_PATH(info->stream), want_stamp))
#endif
|| fchmod(vstream_fileno(info->stream), 0700 | info->mode)
-#ifdef HAS_FSYNC
+/* #ifdef HAS_FSYNC
|| fsync(vstream_fileno(info->stream))
-#endif
+#endif */
|| (check_incoming_fs_clock
&& fstat(vstream_fileno(info->stream), &st) < 0)
)

As you can clearly see in the code, Postfix executes fsync, which this
OP commented out.  Again, the OP didn't use this solution, merely asked
if it would work.  IIRC he temporarily fixed the issue by inserting a
wait to slow down the incoming queue and later added more spindles to
the system as a permanent fix.

So, the short answer is yes, Postfix uses fsync for durability, and the
code that does so, or a portion of it, it pasted above.

-- 
Stan

Re: Can postfix guarantee durability (fsync)?

[Wietse Venema]

Ralf Hildebrandt:
> * Yang Zhang :
> 
> > > No. Postfix replies "250 OK: queued as 12345" when the message is QUEUED.
> > 
> > Doesn't this contradict your original reply that durability is
> > guaranteed? If there's no fsync, then the message may not have been
> > persisted to non-volatile storage, and will be lost.
> 
> After the mail had been written to the queue, fsync() is executed. If
> fsync() succeeded, the reply "250 OK: queued as ." is sent back to
> the client.
> 
> So unless fsync() lies, the mail is safely on the disk.
> 
> Then the qmgr decides to e.g. invoke local to perform local delivery.
> local writes the mail into the Maildir, invokes fsync(). If
> fsync() succeeded, the qmgr considers the mail delivered and deletes
> the queuefile.
> 
> So unless fsync() lies, the mail is safely on the disk.
> 
> Your initial question was:
> "Can postfix be configured to guarantee durable email receipt?
> E.g., can it be sure to fsync the mbox/Maildir file and/or directory
> before it acknowledges successful receipt of an email?"
> 
> THAT is not possible, since the process which is ACCEPTING the mail
> (smtpd) is NOT the same process that is writing to a local mailbox
> (local), due due Postfix's non-monolithical design.

It IS possible, and the reasons have nothing to do with monolithic
design.

Internet mail is a store-and-forward system, so EVERY SYSTEM must
ensure that the message is in stable storage, before it can tell
its predecessor to throw away the predecessor's copy of the message.

This principle also applies to Postfix internally as one part of
Postfix gives the message to another part.

Wietse

transport_maps and round robin dns

[Curtis]

In the case where transport_maps is used to designate the next hop
destination of a message like this:

customer.domain smtp:[mail.customer.domain]

...and the customer uses round robin dns for mail.customer.domain so that it
points to multiple IPs like this:

mail.customer.domain. 900 IN A   111.111.111.111
mail.customer.domain. 900 IN A   222.222.222.222
mail.customer.domain. 900 IN A   333.333.333.333

will postfix rotate between the ips that it delivers to?  Or, will it
cache the first IP (111.111.111.111) and just deliver to that host until the
next time postfix is reloaded or the local DNS cache for the
for mail.customer.domain expires?

Thanks,

Curtis

Re: transport_maps and round robin dns

[Jeroen Geilman]

On 09/21/2010 12:07 AM, Curtis wrote:
In the case where transport_maps is used to designate the next hop 
destination of a message like this:


customer.domain smtp:[mail.customer.domain]

...and the customer uses round robin dns for mail.customer.domain so 
that it points to multiple IPs like this:


mail.customer.domain. 900 IN A   111.111.111.111
mail.customer.domain. 900 IN A   222.222.222.222
mail.customer.domain. 900 IN A   333.333.333.333

will postfix rotate between the ips that it delivers to?


Yes.

 Or, will it cache the first IP (111.111.111.111) and just deliver to 
that host until the next time postfix is reloaded


No.


or the local DNS cache for the for mail.customer.domain expires?


Yes.

Also consider that that is not how a DNS cache works.
On the first query for that A record, all results are returned by an 
origin server, and cached.

Postfix, too, gets all results from the cache.

Assume that postfix will abide by any relevant RFCs for DNS.

--
J.

Re: transport_maps and round robin dns

[Victor Duchovni]

On Tue, Sep 21, 2010 at 12:10:49AM +0200, Jeroen Geilman wrote:

> On 09/21/2010 12:07 AM, Curtis wrote:
>> In the case where transport_maps is used to designate the next hop 
>> destination of a message like this:
>>
>> customer.domain smtp:[mail.customer.domain]
>>
>> ...and the customer uses round robin dns for mail.customer.domain so that 
>> it points to multiple IPs like this:
>>
>> mail.customer.domain. 900 IN A   111.111.111.111
>> mail.customer.domain. 900 IN A   222.222.222.222
>> mail.customer.domain. 900 IN A   333.333.333.333
>>
>> will postfix rotate between the ips that it delivers to?
>
> Yes.

Yes, when traffic to the destination is light (message deliveries
are spaced multiple seconds or more apart) or is very heavy (message
deliveries are many in each interval equal to the delivery of a single
message). When traffic is moderate, demand connection caching may
introduce some short-term bias towards recently used IPs. As the load
rises multiple connections are cached in parallel, and these will tend
to use all the available IPs.

-- 
Viktor.

Re: transport_maps and round robin dns

[Jeroen Geilman]

On 09/21/2010 12:52 AM, Victor Duchovni wrote:

On Tue, Sep 21, 2010 at 12:10:49AM +0200, Jeroen Geilman wrote:

   

On 09/21/2010 12:07 AM, Curtis wrote:
 

In the case where transport_maps is used to designate the next hop
destination of a message like this:

customer.domain smtp:[mail.customer.domain]

...and the customer uses round robin dns for mail.customer.domain so that
it points to multiple IPs like this:

mail.customer.domain. 900 IN A   111.111.111.111
mail.customer.domain. 900 IN A   222.222.222.222
mail.customer.domain. 900 IN A   333.333.333.333

will postfix rotate between the ips that it delivers to?
   

Yes.
 

Yes, when traffic to the destination is light (message deliveries
are spaced multiple seconds or more apart) or is very heavy (message
deliveries are many in each interval equal to the delivery of a single
message). When traffic is moderate, demand connection caching may
introduce some short-term bias towards recently used IPs. As the load
rises multiple connections are cached in parallel, and these will tend
to use all the available IPs.

   


Yes, sorry - I did read that before, but neglected to be complete in my 
answer :(


Am I correct in thinking that this adaptive behaviour is designed to 
prevent overloading the nameservers postfix talks to ?
Hence why it wouldn't kick in at low volumes, and wouldn't matter at 
high volumes.


--
J.

Re: transport_maps and round robin dns

[Victor Duchovni]

On Tue, Sep 21, 2010 at 12:56:14AM +0200, Jeroen Geilman wrote:

>> Yes, when traffic to the destination is light (message deliveries
>> are spaced multiple seconds or more apart) or is very heavy (message
>> deliveries are many in each interval equal to the delivery of a single
>> message). When traffic is moderate, demand connection caching may
>> introduce some short-term bias towards recently used IPs. As the load
>> rises multiple connections are cached in parallel, and these will tend
>> to use all the available IPs.
>
> Am I correct in thinking that this adaptive behaviour is designed to 
> prevent overloading the nameservers postfix talks to ?

No, not at all, DNS lookups are cached and therefore cheap. It is
SMTP connection setup that is expensive for heavily loaded destinations
with multiple MX hosts behind load-balancers, where some MX hosts may
be slow to respond and initial connections are subjected to various DNS
tests, ... that don't apply to a second message for the same connection.

Connection caching is especially attractive when some MX hosts are
down and non-responsive, incurring high connection setup latency.

-- 
Viktor.

Re: transport_maps and round robin dns

[Stan Hoeppner]

Victor Duchovni put forth on 9/20/2010 6:01 PM:
> On Tue, Sep 21, 2010 at 12:56:14AM +0200, Jeroen Geilman wrote:
> 
>>> Yes, when traffic to the destination is light (message deliveries
>>> are spaced multiple seconds or more apart) or is very heavy (message
>>> deliveries are many in each interval equal to the delivery of a single
>>> message). When traffic is moderate, demand connection caching may
>>> introduce some short-term bias towards recently used IPs. As the load
>>> rises multiple connections are cached in parallel, and these will tend
>>> to use all the available IPs.
>>
>> Am I correct in thinking that this adaptive behaviour is designed to 
>> prevent overloading the nameservers postfix talks to ?
> 
> No, not at all, DNS lookups are cached and therefore cheap. It is
> SMTP connection setup that is expensive for heavily loaded destinations
> with multiple MX hosts behind load-balancers, where some MX hosts may
> be slow to respond and initial connections are subjected to various DNS
> tests, ... that don't apply to a second message for the same connection.
> 
> Connection caching is especially attractive when some MX hosts are
> down and non-responsive, incurring high connection setup latency.

Maybe worth reading the relevant documentation on connection caching:

http://www.postfix.org/scache.8.html

-- 
Stan

Re: transport_maps and round robin dns

[Curtis]

On Mon, Sep 20, 2010 at 4:10 PM, Jeroen Geilman  wrote:

> On 09/21/2010 12:07 AM, Curtis wrote:
>
>> In the case where transport_maps is used to designate the next hop
>> destination of a message like this:
>>
>> customer.domain smtp:[mail.customer.domain]
>>
>> ...and the customer uses round robin dns for mail.customer.domain so that
>> it points to multiple IPs like this:
>>
>> mail.customer.domain. 900 IN A   111.111.111.111
>> mail.customer.domain. 900 IN A   222.222.222.222
>> mail.customer.domain. 900 IN A   333.333.333.333
>>
>> will postfix rotate between the ips that it delivers to?
>>
>
> Yes.
>
>
>   Or, will it cache the first IP (111.111.111.111) and just deliver to that
>> host until the next time postfix is reloaded
>>
>
> No.
>
>
>  or the local DNS cache for the for mail.customer.domain expires?
>>
>
> Yes.
>
> Also consider that that is not how a DNS cache works.
> On the first query for that A record, all results are returned by an origin
> server, and cached.
> Postfix, too, gets all results from the cache.
>

Yes, this is how I understood it... that the local DNS would cache all three
IPs... I just wasn't sure if Postfix might cache the first IP.  But thanks
to you and Victor, I am satisfied that it should work the way I hoped it
would.

Thanks,

Curtis

Re: Can postfix guarantee durability (fsync)?

[mouss]

 Le 20/09/2010 22:46, Yang Zhang a écrit :

On Mon, Sep 20, 2010 at 12:33 PM, Wietse Venema  wrote:

Yang Zhang:

Can you pinpoint the exact RFC&  section you're referring to? Thanks.

I will give you as home work to study the following documents:

RFC 821
RFC 2821
RFC 5321

These have lots of other good stuff about Internet mail.

I had looked at these and couldn't find any specification of the
guarantees - would you mind pointing out what you're referring to?
Thanks, greatly appreciate it.


 section 6.1 in both 2821 and 5321:

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.


if you still don't see, focus on the "crashes" part.

Re: Can postfix guarantee durability (fsync)?

[mouss]

 Le 20/09/2010 21:15, Yang Zhang a écrit :

On Mon, Sep 20, 2010 at 12:02 PM, Jeroen Geilman  wrote:

On 09/20/2010 08:37 PM, Yang Zhang wrote:

Can postfix be configured to guarantee durable email receipt?

E.g., can it be sure to fsync the mbox/Maildir file and/or directory


No, but it does guarantee durability from the receiving SMTP session to the
delivering process.
This CAN be delivery to a mailbox.


before it acknowledges successful receipt of an email?


That would be the end of the SMTP session.
No MTA guarantees final mail delivery *before* returning the SMTP status,
that would make queueing a travesty of epic proportions.
You want queueing.
Yes, really, you do .

That's fine. My main concern (worded poorly) was preventing data
loss/allowing for eventual delivery, not ensuring final mbox/Maildir
delivery. I just assumed there was no intermediate queuing.

Since there's queuing, does Postfix also handle resuming delivery on recovery?

Just to be clear, if I have this Maildir in my mailbox postmap:

   j...@mydomain.com joe/

and most other settings are the Ubuntu 10.04 postfix defaults, then
postfix will have done an fsync by the time the "250 OK: queued as
12345" comes back, such that if I then immediately power cycle the
server, when it comes back up, the mail will make its way to the final
mbox/Maildir?


yes.

- 250... means postfix queued the message (on disk).
- the message will stay queued until delivered


of course, you can still lose mail with 'rm -rf /var/spool' or even more 
simply with postsuper.

Re: Forwarding emails, quick question

[Victor Duchovni]

On Mon, Sep 20, 2010 at 03:15:37PM -0400, Brian Pribis wrote:

> If I put
> 
>   addr...@virtual_domain m...@gmail.com
> 
> Shouldn't it simply forward email from the first address to my gmail account?

Yes.

> What happens is the mail does go to gmail but if I hit "reply" it
> tries to mail back to addr...@vitual_domaininstead of the original
> sender.

You are confused. Reply-All, will reply to both the Sender and all
Recipients, other than any the Mail User Agent (in this case Gmail)
knows to be yours.

So if you Reply, the reply will go to the From: address. Virtual rewriting
does not change the From: address.

If you Reply-All, then the reply will Cc the forwarded mailbox.

It is of course possible that you are implementing forwarding in some
other way, that does change the From: address, but that is not how
Postfix virtual alias rewriting works.

-- 
Viktor.

Re: Please Help Me Secure My Mail Server

[fakessh]

On Mon, 20 Sep 2010 15:56:35 -0500, Noel Jones 
wrote:
> On 9/20/2010 3:29 PM, bper wrote:
>>
>> Hello,
>>
>> I have set up a postfix-dovecot server with smtp-auth using sasl by
>> following this link:
>> https://help.ubuntu.com/10.04/serverguide/C/postfix.html
>>
>> It seems to be working OK. The only thing is that when I view my logs, I see
>> a lot of 'relaying denied', 'noqueue reject', 'too many errors after rcpt',
>> and 'disconnect' messages from a lot of unknown domain names and ip
>> addresses.
> 
> These are normal messages indicating that postfix is working correctly.
> 
> 
>>
>> I'm hoping that this means that the server is secure and doing its job
>> bouncing mail from unauthorized requests.
>>
>> *** Is that true?
> 
> quickie definitions:
> 
> bounce - accept mail and return it to the (likely forged) sender.  BAD.
> 
> reject - unwanted mail is not accepted.  Notification of legit
> senders is the responsibility of the sender's mail server.  GOOD.
> 
> Your postfix is apparently doing its job rejecting unwanted mail.
> 
> 
> For further analysis, show your "postconf -n" and unaltered log
> entries you don't understand.
> 
> 
> -- Noel Jones
> 
> 
>>
>> Even if it was true, it has to be slowing down the server receiving so many
>> unauthorized requests.
>>
>> *** Is there a way to avoid this or is this just a function of life in the
>> world of email spam? Would a spam filter like Spamassasin help this type of
>> issue?
>>
>> Thanks!



-:-
good example of config are available
sign my blog

regards

Re: Virtual users pop3d suggestions

[Nick Edwards]

On Tue, Sep 14, 2010 at 4:53 AM, Seth Mattinen  wrote:

> On 9/10/2010 00:32, Nick Edwards wrote:
> > Good day all,
> > I apologize in advance if the moderators consider this slightly OT.
> >
> > We have many users moved to a MySQL database, planned for moving away
> > from Cyrus on Sunday Oct 3, we are almost ready to go but found a
> > problem with pop3 software we were going to use.
> >
> > So basically, using postifx's virtual, excluding Dovecot, what POP3
> > servers are people using? This will be NFS so we are going to use
> Maildir.
> >  We know Courier, but Googling shows a /lot/ of people say it's slow
> > compared to other daemons, but there does not seem to be much else of a
> > real choice?
> >
> > We have approximately 90 thousands DSL and 3G users,  not a big company,
> > but hardly too small either.
> >
>
> I used to use Courier, but ended up replacing it with Dovecot.
>
> ~Seth
>

Thanks, we have over the weekend ran two testbeds at full thrashing with in
house written scripts, the timings show after 57 hours of constant stress
tests with identical copies of various messages pop'd by both using 1000
parallel accesses, for pop3 courier is no faster than dovecot, we are sure
if it was imap it would be a different story, but we have no use, since
sqwebmail uses pop3, we can eliminate imap completely, the decision to our
problem is simple now, after this test, we see no reason to continue to use
dovecot in its current state with its inherit risks when courier has none of
them, the move to courier is now justified.
Thanks to all who offered alternative suggestions.

Nick