Re: sending email with Gnus

[Wietse Venema]

Ralf Hildebrandt:
> * LuKreme :
> 
> > Postfix does not 'support' TLS at all.
> 
> I wouldn't say it that way. STARTTLS looks like TLS support, if you
> ask me
> 
> > It should work with Gnu TLS as well as with any other TLS library.
> 
> As far as I knwo it doesn't :)

A couple years ago, Gnu TLS would exit the program (exit status 2)
instead of reporting an error to Postfix, so that Postfix could
switch to plaintext where appropriate.

http://www.postfix.org/TLS_README.html#build_tls

Wietse

Re: sending email with Gnus

[Ralf Hildebrandt]

* Wietse Venema :

> A couple years ago, Gnu TLS would exit the program (exit status 2)
> instead of reporting an error to Postfix, so that Postfix could
> switch to plaintext where appropriate.
> 
> http://www.postfix.org/TLS_README.html#build_tls

Should I retry a build with GNUTLS?

-- 
Ralf Hildebrandt (ralf.hildebra...@charite.de)  snick...@charite.de
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Re: alias question

[Leonardo Coelho]

I'm sorry but i don't get it, if i have this two lines:

> local_transport = virtual
> virtual_alias_maps = hash:/etc/postfix/alias-virtual

and before i had:

> virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf

and isn't work anyway.
Can anyone give me another direction?


Thanks


On Sat, Feb 28, 2009 at 3:16 PM, mouss  wrote:

> Leonardo Coelho a écrit :
> > Hey guys this is my postconf -n output:
> >
> > append_dot_mydomain = no
> > biff = no
> > config_directory = /etc/postfix
> > disable_vrfy_command = yes
> > inet_interfaces = 127.0.0.1, 10.1.1.107, 189.11.37.1xx
> > invalid_hostname_reject_code = 450
> > local_transport = virtual
>
> alias_maps only work in "local", not "virtual". so move your alias to
> virtual_alias_maps.
>
> > mailbox_command = procmail -a "$EXTENSION"
> > mailbox_size_limit = 0
> > mailbox_transport = virtual
> > maps_rbl_reject_code = 450
> > message_size_limit = 0
> > mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp
> > mydestination = mail.domain.com.br ,
> > localhost, mail2.domain.com.br 
> > myhostname = mail.domain.com.br 
> > mynetworks = 192.168.0.0/24  192.168.x.x/24
> > 192.168.x.x/24 192.168.x.x/24 189.11.37.1xx/32
> > non_fqdn_reject_code = 450
> > receive_override_options = no_address_mappings
> > recipient_delimiter = +
> > relayhost =
> > smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
> > smtpd_banner = $myhostname ESMTP $mail_name (Debian/Rox)
> > smtpd_client_restrictions = permit_mynetworks,  reject_non_fqdn_sender,
> > reject_rbl_client sbl-xbl.spamhaus.org ,
> > reject_rbl_client bl.spamcop.net ,
> > reject_unknown_sender_domain,permit
> > smtpd_helo_required = yes
> > smtpd_recipient_restrictions = permit_mynetworks,
> > permit_sasl_authenticated,  reject_non_fqdn_sender,
> > reject_unauth_destination,
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_local_domain = domain.com.br 
> > smtpd_sasl_path = private/auth
> > smtpd_sasl_security_options = noanonymous
> > smtpd_sasl_type = dovecot
> > smtpd_sender_restrictions = permit_mynetworks,
> > reject_unknown_sender_domain,   reject_non_fqdn_sender, permit
> > smtpd_tls_auth_only = yes
> > smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
> > smtpd_tls_key_file = /etc/ssl/private/postfix.pem
> > smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
> > smtpd_use_tls = yes
> > transport_maps = hash:/etc/postfix/transport
> > virtual_alias_maps = hash:/etc/postfix/alias-virtual
> > virtual_gid_maps = static:5000
> > virtual_mailbox_base = /home/vmail
> > virtual_mailbox_domains =
> > mysql:/etc/postfix/mysql_virtual_domains_maps.cf
> > 
> > virtual_mailbox_limit = 0
> > virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
> > 
> > virtual_minimum_uid = 5000
> > virtual_transport = dovecot
> > virtual_uid_maps = static:5000
> >
> > and log non-verbose:
> >
> > mail2 postfix/smtpd[3642]: 901AB5FAFD2: client=rv-out-0708.google.com
> > [209.85.198.245]
> >
> > mail2 postfix/cleanup[3023]: 901AB5FAFD2:
> > message-id=<39f8772a0902270313v7e620027q330920899717e...@mail.gmail.com
> > >
> >
> > mail2 postfix/qmgr[31327]: 901AB5FAFD2: from= > >, size=2430, nrcpt=1 (queue active)
> >
> > mail2 postfix/pipe[4168]: 901AB5FAFD2: to= > >, relay=dovecot, delay=1,
> > delays=0.98/0/0/0.04, dsn=2.0.0, status=sent (delivered via dovecot
> service)
> >
> > mail2 postfix/qmgr[31327]: 901AB5FAFD2: removed
> >
> >
>



-- 
"First they ignore you, then they laugh at you, then they fight you, then
you win." - Mahatma Gandhi
Linux User #373408
cabelohw.blogspot.com
GPGkey ID  8AEEAAEB -->> http://pgp.mit.edu

Re: sending email with Gnus

[Wietse Venema]

Ralf Hildebrandt:
> * Wietse Venema :
> 
> > A couple years ago, Gnu TLS would exit the program (exit status 2)
> > instead of reporting an error to Postfix, so that Postfix could
> > switch to plaintext where appropriate.
> > 
> > http://www.postfix.org/TLS_README.html#build_tls
> 
> Should I retry a build with GNUTLS?

Apparently this library freaks out when there's no /dev/*random,
so this is a double idiot problem. 

Idiot #1: GnuTLS library calls exit instead of allowing applications
such as Postfix to provide randomness.  Postfix provides randomness
via a tlsmgr daemon that runs outside the chroot jail and that has
access to /dev/*random.

Idiot #2: Linux distro turns on CHROOT by default, but provides no
/dev/*random.

You're welcome to reproduce this.

Wietse

Prioritising outgoing mail

[Wouter van Marle]

Hi list,

From me a question that seems to be asked now and then here, but I 
could not find any answers even on whether this is possible in the 
first place.


I would like to be able to prioritise outgoing e-mail so they do not 
get stuck in the queue. This as I now and then send out a large number 
of e-mails with attachments, and that saturates my connection for a 
prolonged time. It doesn't matter that those mails get out slower, as 
long as they get out eventually I'm happy.


However it can clog up other e-mails that I do want to get tackled 
first.


Any way to do this?

Any solution will do as long as it can run on a single server, and an 
upgrade of my uplink is also not an option (financially, and it is too 
infrequent to require more bandwidth but frequent enough to irritate me 
that my other e-mails do not get out quickly). Separate mailqueues, 
whatever: just a way to get normal priority mails first in line.


Thanks.

Wouter.

Re: outbound email destination based on sender's domain

[Iad Scoot]

Hi again,

Still working on this - something that I didn't mention (sorry, should have)
was that the Postfix gateway is multi-homed and that the other edge Postfix
systems (and the internal mail servers) are each on different subnets.

Example:
a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1
b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1
c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1

...and so on. The gateway system has a NIC for each pair of systems and the
traffic is forwarded through a router from the internal server to the
gateway and then either back to one of the other internal servers or out to
the edge proxy that matches the sender's domain from the internal mail
server.

How does this new info affect the previous solution that you provided?

Thanks...

On Fri, Feb 27, 2009 at 6:50 PM, Iad Scoot  wrote:

> Gotcha - and after a "little more" research I've found a couple of examples
> online. It'll be Monday before I can try but much thanks again - I will post
> back my outcome.
>
>  - iad
>
>   On Fri, Feb 27, 2009 at 6:33 PM, Barney Desmond  > wrote:
>
>> 2009/2/28 Iad Scoot :
>> > Hey thanks for the info - it looks like (from what I've read so far)
>> that
>> > the sender_dependent_relayhost_maps parameter is for specific users - is
>> > there any way to do this for any user (or all users) in a given domain
>> w/o
>> > having to list their full address in the map file?
>>
>> That should work; according to the documentation, "The tables are
>> searched by the envelope sender address and @domain".
>>
>> I admit I haven't *actually* used this myself, but I'm guessing you
>> either use "senderdomain.com" (like a transport table) or
>> "@senderdomain.com" (virtual-style catchall) as the key to the lookup.
>> Testing will tell you in a matter of minutes.
>>
>
>

Re: Prioritising outgoing mail

[Victor Duchovni]

On Mon, Mar 02, 2009 at 10:44:21PM +0800, Wouter van Marle wrote:

> Hi list,
>
> From me a question that seems to be asked now and then here, but I could 
> not find any answers even on whether this is possible in the first place.
>
> I would like to be able to prioritise outgoing e-mail so they do not get 
> stuck in the queue. This as I now and then send out a large number of 
> e-mails with attachments, and that saturates my connection for a prolonged 
> time. It doesn't matter that those mails get out slower, as long as they 
> get out eventually I'm happy.

Use a custom transport for these messages with a low concurrency limit,
or use traffic shaping in the TCP stack to limit the bandwidth per
SMTP connection.

-- 
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: Prioritising outgoing mail

[Wouter van Marle]

On 2 Mar 09, at 23:09, Victor Duchovni wrote:


On Mon, Mar 02, 2009 at 10:44:21PM +0800, Wouter van Marle wrote:


Hi list,

From me a question that seems to be asked now and then here, but I 
could
not find any answers even on whether this is possible in the first 
place.


I would like to be able to prioritise outgoing e-mail so they do not 
get

stuck in the queue. This as I now and then send out a large number of
e-mails with attachments, and that saturates my connection for a 
prolonged
time. It doesn't matter that those mails get out slower, as long as 
they

get out eventually I'm happy.


Use a custom transport for these messages with a low concurrency limit,


You mean like installing sendmail or so in parallel to postfix and then 
have sendmail send out the lower-priority mails?



or use traffic shaping in the TCP stack to limit the bandwidth per
SMTP connection.


And how would that get certain mails out with priority? It sounds to me 
like this would slow down the overall process. I have up to 100 smtp 
processes running at a time, but as long as new mails end up at the 
back of the queue still no progress there. They have to come first.


Wouter.



--
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: Prioritising outgoing mail

[Wietse Venema]

Wouter van Marle:
> 
> On 2 Mar 09, at 23:09, Victor Duchovni wrote:
> 
> > On Mon, Mar 02, 2009 at 10:44:21PM +0800, Wouter van Marle wrote:
> >
> >> Hi list,
> >>
> >> From me a question that seems to be asked now and then here, but I 
> >> could
> >> not find any answers even on whether this is possible in the first 
> >> place.
> >>
> >> I would like to be able to prioritise outgoing e-mail so they do not 
> >> get
> >> stuck in the queue. This as I now and then send out a large number of
> >> e-mails with attachments, and that saturates my connection for a 
> >> prolonged
> >> time. It doesn't matter that those mails get out slower, as long as 
> >> they
> >> get out eventually I'm happy.
> >
> > Use a custom transport for these messages with a low concurrency limit,
> 
> You mean like installing sendmail or so in parallel to postfix and then 
> have sendmail send out the lower-priority mails?

No, use a POSTFIX transport map.

> > or use traffic shaping in the TCP stack to limit the bandwidth per
> > SMTP connection.
> 
> And how would that get certain mails out with priority? It sounds to me 

With the concurrency limit (see above), low priority mail can use
up only a limited portion of the bandwidth.

Wietse

Re: Prioritising outgoing mail

[Victor Duchovni]

On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote:

>> Use a custom transport for these messages with a low concurrency limit,
>
> You mean like installing sendmail or so in parallel to postfix and then 
> have sendmail send out the lower-priority mails?
>

No I mean a Postfix "transport", as in transport(5) and master(5).

>> or use traffic shaping in the TCP stack to limit the bandwidth per
>> SMTP connection.
>
> And how would that get certain mails out with priority? It sounds to me 
> like this would slow down the overall process. I have up to 100 smtp 
> processes running at a time, but as long as new mails end up at the back of 
> the queue still no progress there. They have to come first.

It would not, but you won't saturate the entire link with any given email,
leaving enough room for other traffic. If you can limit the concurrency
of this particular message, then you'll have some bandwidth left over for
other messages.

-- 
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: /usr/sbin/sendmail requeue and address expansion

[kj]

Wietse Venema wrote:

Look for receive_override_options in the MASTER.CF file
examples of the FILTER_README documentation.

Wietse
  


Thanks Wietse,  adding it to the smtp line in master.cf instead solve 
the problem.


Sorry for my late reply - I wrote it and then went off on a long weekend 
without ever hitting send.


--kj

mysql lookup errors

[kj]

Hi guys,

I'm seeing this in the logs:

Mar  2 18:18:05 web postfix/cleanup[27207]: warning: mysql query failed: 
MySQL server has gone away
Mar  2 18:18:05 web postfix/cleanup[27207]: warning: D1D1A71029C: 
virtual_alias_maps map lookup problem for donny_bra...@example.co.uk
Mar  2 18:18:28 web postfix/smtpd[27153]: connect from 
unknown[xxx.xxx.xxx.xxx]
Mar  2 18:18:29 web postfix/trivial-rewrite[27154]: warning: mysql query 
failed: MySQL server has gone away
Mar  2 18:18:29 web postfix/trivial-rewrite[27154]: fatal: 
mysql:/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table 
lookup problem

Mar  2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48 from=
Mar  2 18:18:30 web postfix/smtpd[27153]: warning: premature 
end-of-input on private/rewrite socket while reading input attribute name
Mar  2 18:18:30 web postfix/smtpd[27153]: warning: problem talking to 
service rewrite: Success
Mar  2 18:18:30 web postfix/cleanup[27207]: warning: premature 
end-of-input on private/rewrite socket while reading input attribute name
Mar  2 18:18:30 web postfix/cleanup[27207]: warning: problem talking to 
service rewrite: Connection reset by peer
Mar  2 18:18:30 web postfix/master[21481]: warning: process 
/usr/libexec/postfix/trivial-rewrite pid 27154 exit status 1
Mar  2 18:18:31 web postfix/cleanup[27207]: E381E7102B3: 
message-id=
Mar  2 18:18:31 web postfix/cleanup[27207]: warning: E381E7102B3: 
virtual_alias_maps map lookup problem for donny_bra...@example.co.uk
Mar  2 18:18:32 web postfix/smtpd[27153]: warning: mysql query failed: 
MySQL server has gone away
Mar  2 18:18:32 web postfix/smtpd[27153]: NOQUEUE: reject: RCPT from 
unknown[xxx.xxx.xxx.xxx]: 451 4.3.0 : Temporary 
lookup failure;


e-mail addresses in the above is, of course, fictitious.   
donny_bra...@example.co.uk is hosted elsewhere,  sa...@some_domain.com 
is hosted on this box.   The server is running RHEL5, with the stock Red 
Hat rpm recompiled with mysql support.


The mysql database sits on another server, and is mostly idle (the 
Postfix box has very low traffic so far).  I am unable to reproduce any 
query problems outside of postfix. Doing the queries directly in the 
mysql shell just works.  The following also works 100%:


# postmap -q sa...@some_domain.com 
mysql:/etc/postfix/mysql_virtual_alias_maps.cf

sa...@some_domain.com

I have verified the usernames/passwords in the mysql_*.cf files.  
Nothing was changed in the last few days.  So I have two questions about 
the above:


1.  What could possibly cause postfix to have lookup problems when 
nothing else does?   The server did run out of disc space a few days 
ago.  I did a postsuper -s -v which didn't show any problems.  Could the 
disc space issue have damaged something?


2.  Is there a way to enable debugging output for connections from apache?

3.  I looks like the query fails when the mysql connection has timed 
out.  Can postfix be told to reconnect automatically instead of 
accepting it as a failure?


Thanks
--kj

Re: alias question

[/dev/rob0]

Massive confusion, and looking back on the thread somewhat, I still 
think we're lacking a good description of the problem.

On Mon March 2 2009 06:31:09 Leonardo Coelho wrote:
> I'm sorry but i don't get it, if i have this two lines:
> 
> > local_transport = virtual

Don't do this. It probably doesn't work anyway. We have address classes 
with proper *_transport defaults. The local_transport is of course 
local(8), which is designed to work with Unix users and traditional 
Unix system aliases(5).

Where did you get this idea? It's a bad idea. See the 
ADDRESS_CLASS_README to begin to understand how different classes are 
handled in Postfix ... the right way.

> > virtual_alias_maps = hash:/etc/postfix/alias-virtual

See the VIRTUAL_README and aforementioned ADDRESS_CLASS_README to get 
the difference between virtual(8) mailboxes and virtual(5) aliases. 
Also, be aware that virtual_alias_maps apply to ALL mail, not just the 
domains defined in virtual_alias_domains.

> and before i had:
> > virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
>
> and isn't work anyway.

MYSQL_README tells you how to construct a proper query, but it assumes 
you're already up to speed on mysql. A hash: map is the way to start 
out, then when that works, all you have to do is import the data into 
your relational database.

I suggest, as does DATABASE_README, that you figure out the Postfix 
workings before you muddy it all up with mysql confusion.

> Can anyone give me another direction?

Read the documentation? Well, I'll look at your config and logs below.

> On Sat, Feb 28, 2009 at 3:16 PM, mouss  wrote:
> > Leonardo Coelho a écrit :
> > > Hey guys this is my postconf -n output:
> > >
> > > append_dot_mydomain = no
> > > biff = no
> > > config_directory = /etc/postfix
> > > disable_vrfy_command = yes
> > > inet_interfaces = 127.0.0.1, 10.1.1.107, 189.11.37.1xx
> > > invalid_hostname_reject_code = 450
> > > local_transport = virtual
> >
> > alias_maps only work in "local", not "virtual". so move your alias
> > to virtual_alias_maps.
> >
> > > mailbox_command = procmail -a "$EXTENSION"
> > > mailbox_size_limit = 0
> > > mailbox_transport = virtual
> > > maps_rbl_reject_code = 450

This was deprecated YEARS ago. You must have followed a HOWTO which is 
outdated in addition to being just plain bad.

> > > message_size_limit = 0
> > > mime_header_checks =
> > > regexp:/etc/postfix/mime_header_checks.regexp mydestination =
> > > mail.domain.com.br , localhost,
> > > mail2.domain.com.br  myhostname =
> > > mail.domain.com.br  mynetworks =
> > > 192.168.0.0/24  192.168.x.x/24
> > > 192.168.x.x/24 192.168.x.x/24 189.11.37.1xx/32
> > > non_fqdn_reject_code = 450
> > > receive_override_options = no_address_mappings

See postconf.5.html#receive_override_options to understand what this 
does. Don't use settings that you don't understand. Looks like that 
describes a big part of your configuration.

> > > recipient_delimiter = +
> > > relayhost =
> > > smtp_tls_session_cache_database =
> > > btree:${queue_directory}/smtp_scache smtpd_banner = $myhostname
> > > ESMTP $mail_name (Debian/Rox)
> > > smtpd_client_restrictions = 
> > > permit_mynetworks,  reject_non_fqdn_sender, reject_rbl_client
> > > sbl-xbl.spamhaus.org ,

(Please do NOT post in HTML on a mailing list, thank you.)

> > > reject_rbl_client bl.spamcop.net ,
> > > reject_unknown_sender_domain,permit
> > > smtpd_helo_required = yes
> > > smtpd_recipient_restrictions = permit_mynetworks,
> > > permit_sasl_authenticated,  reject_non_fqdn_sender,
> > > reject_unauth_destination,
> > > smtpd_sasl_auth_enable = yes
> > > smtpd_sasl_local_domain = domain.com.br 
> > > smtpd_sasl_path = private/auth
> > > smtpd_sasl_security_options = noanonymous
> > > smtpd_sasl_type = dovecot
> > > smtpd_sender_restrictions = permit_mynetworks,
> > > reject_unknown_sender_domain,   reject_non_fqdn_sender, permit

Three different smtpd(8) restriction stages, no good reason for them 
(such as a whitelisting restriction which might be unsafe in 
smtpd_recipient_restrictions.) I would suggest consolidation of these 
into smtpd_recipient_restrictions, making it easier to follow and to 
maintain.

> > > smtpd_tls_auth_only = yes
> > > smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
> > > smtpd_tls_key_file = /etc/ssl/private/postfix.pem
> > > smtpd_tls_session_cache_database =
> > > btree:${queue_directory}/smtpd_scache smtpd_use_tls = yes
> > > transport_maps = hash:/etc/postfix/transport

Why are you using transport_maps ?

> > > virtual_alias_maps = hash:/etc/postfix/alias-virtual
> > > virtual_gid_maps = static:5000
> > > virtual_mailbox_base = /home/vmail
> > > virtual_mailbox_domains =
> > > mysql:/etc/postfix/mysql_virtual_domains_maps.cf
> > > 
> > > vir

Re: alias question

[Victor Duchovni]

On Mon, Mar 02, 2009 at 12:56:33PM -0600, /dev/rob0 wrote:

> Massive confusion, and looking back on the thread somewhat, I still 
> think we're lacking a good description of the problem.
> 
> On Mon March 2 2009 06:31:09 Leonardo Coelho wrote:
> > I'm sorry but i don't get it, if i have this two lines:
> > 
> > > local_transport = virtual
> 
> Don't do this. It probably doesn't work anyway. We have address classes 
> with proper *_transport defaults. The local_transport is of course 
> local(8), which is designed to work with Unix users and traditional 
> Unix system aliases(5).

There is nothing wrong with "local_transport = virtual", if one wants
virtual delivery with no aliases(5) processing or .forward processing
for all local users, but often setting mailbox_transport is a better
way to handle "local" (system-user) mail.

-- 
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: mysql lookup errors

[/dev/rob0]

On Mon March 2 2009 12:51:23 kj wrote:
> I'm seeing this in the logs:
>
> Mar  2 18:18:05 web postfix/cleanup[27207]: warning: mysql query
> failed: MySQL server has gone away
snip
> Mar  2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48
> from=
snip
> RHEL5, with the stock Red Hat rpm recompiled with mysql support.

That RPM is probably chroot'ed by the distributor. My first guess is 
that you're seeing a chroot problem. My second guess, SELinux. In 
either case, seek support from your vendor for these problems.

> 1.  What could possibly cause postfix to have lookup problems when
> nothing else does?   The server did run out of disc space a few days
> ago.  I did a postsuper -s -v which didn't show any problems.  Could
> the disc space issue have damaged something?
>
> 2.  Is there a way to enable debugging output for connections from
> apache?

Uh, "connections from apache", what? Is that a Postfix question? If so 
see postconf.5.html#debug_peer_list and list the IP address of the 
client. See also DEBUG_README (which will also describe the chroot 
issue and how to get out of it.)

However, the logging in your post did not show any "connections from 
apache," it showed submission via sendmail(1) by your apache user. 
Try "man sendmail" or sendmail.1.html.

> 3.  I looks like the query fails when the mysql connection has timed
> out.  Can postfix be told to reconnect automatically instead of
> accepting it as a failure?
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: alias question

[/dev/rob0]

On Mon March 2 2009 13:07:18 Victor Duchovni wrote:
> On Mon, Mar 02, 2009 at 12:56:33PM -0600, /dev/rob0 wrote:
> > Massive confusion, and looking back on the thread somewhat, I still
> > think we're lacking a good description of the problem.
> >
> > On Mon March 2 2009 06:31:09 Leonardo Coelho wrote:
> > > I'm sorry but i don't get it, if i have this two lines:
> > > > local_transport = virtual
> >
> > Don't do this. It probably doesn't work anyway. We have address
> > classes with proper *_transport defaults. The local_transport is of
> > course local(8), which is designed to work with Unix users and
> > traditional Unix system aliases(5).
>
> There is nothing wrong with "local_transport = virtual", if one wants
> virtual delivery with no aliases(5) processing or .forward processing
> for all local users, but often setting mailbox_transport is a better
> way to handle "local" (system-user) mail.

Thanks. I was thinking, as well, that the someone with such a need  
might do better using relay_domains and set "relay_transport = 
dovecot", for the domains defined in his virtual_mailbox_domains, since 
later on the OP also changed virtual_transport. Then the mydestination 
domains could be moved to virtual_mailbox_domains and mydestination 
unset. This fits in with the principle of doing the least possible 
pounding of square pegs into round holes.

Of course this is all academic; I doubt the OP really knows what he 
needs.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: mysql lookup errors

[mouss]

kj a écrit :
> Hi guys,
> 
> I'm seeing this in the logs:
> 
> Mar  2 18:18:05 web postfix/cleanup[27207]: warning: mysql query failed:
> MySQL server has gone away
> Mar  2 18:18:05 web postfix/cleanup[27207]: warning: D1D1A71029C:
> virtual_alias_maps map lookup problem for donny_bra...@example.co.uk
> Mar  2 18:18:28 web postfix/smtpd[27153]: connect from
> unknown[xxx.xxx.xxx.xxx]
> Mar  2 18:18:29 web postfix/trivial-rewrite[27154]: warning: mysql query
> failed: MySQL server has gone away
> Mar  2 18:18:29 web postfix/trivial-rewrite[27154]: fatal:
> mysql:/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table
> lookup problem
> Mar  2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48
> from=
> Mar  2 18:18:30 web postfix/smtpd[27153]: warning: premature
> end-of-input on private/rewrite socket while reading input attribute name
> Mar  2 18:18:30 web postfix/smtpd[27153]: warning: problem talking to
> service rewrite: Success
> Mar  2 18:18:30 web postfix/cleanup[27207]: warning: premature
> end-of-input on private/rewrite socket while reading input attribute name
> Mar  2 18:18:30 web postfix/cleanup[27207]: warning: problem talking to
> service rewrite: Connection reset by peer
> Mar  2 18:18:30 web postfix/master[21481]: warning: process
> /usr/libexec/postfix/trivial-rewrite pid 27154 exit status 1
> Mar  2 18:18:31 web postfix/cleanup[27207]: E381E7102B3:
> message-id=
> Mar  2 18:18:31 web postfix/cleanup[27207]: warning: E381E7102B3:
> virtual_alias_maps map lookup problem for donny_bra...@example.co.uk
> Mar  2 18:18:32 web postfix/smtpd[27153]: warning: mysql query failed:
> MySQL server has gone away
> Mar  2 18:18:32 web postfix/smtpd[27153]: NOQUEUE: reject: RCPT from
> unknown[xxx.xxx.xxx.xxx]: 451 4.3.0 : Temporary
> lookup failure;
> 
> [snip]

replace "mysql:" with "proxy:mysql:" and try again.

Restrict external hosts

[Vernon A. Fort]

I have a setup which we use an external mail filtering service and need 
to limit/restrict external client access.  Meaning the MX for the domain 
points to the filtering service and they relay checked email.  I need to 
limit access to just these network blocks but also allow sasl 
authenticated as well as the internal network.


I also do not want to blindly trust this service so i would like to 
check the IP address as well as ensuring the recipient is for my domain.


can someone point me to an example or man page.  I cannot seem to find 
anything related to limiting inbound smtp clients/servers.


Vernon

Re: outbound email destination based on sender's domain

[Barney Desmond]

2009/3/3 Iad Scoot :
> Still working on this - something that I didn't mention (sorry, should have)
> was that the Postfix gateway is multi-homed and that the other edge Postfix
> systems (and the internal mail servers) are each on different subnets.
>
> Example:
> a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1
> b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1
> c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1
>
> ...and so on. The gateway system has a NIC for each pair of systems and the
> traffic is forwarded through a router from the internal server to the
> gateway and then either back to one of the other internal servers or out to
> the edge proxy that matches the sender's domain from the internal mail
> server.
>
> How does this new info affect the previous solution that you provided?

Assuming your setup is generally sane, this shouldn't cause you any
grief. You *can* bind the postfix smtp client to a given src address,
but that's only useful when you're single-homed and want to use one
particular address of many (for policy/firewall/whatever reasons).
This doesn't apply to you, so that's fine.

Another thing people sometimes want is (the currently non-existent)
sender-dependent src-address. This is usually because they're trying
to optimise their mass-mailings of questionable legitimacy. This also
doesn't apply to you, which is fine.

Left to its own devices, Postfix will let the network stack figure out
how to get the packets to the destination properly. As long as your
routing is all working, the details you've provided won't change
anything (as far as I know).

Re: Restrict external hosts

[Noel Jones]

Vernon A. Fort wrote:
I have a setup which we use an external mail filtering service and need 
to limit/restrict external client access.  Meaning the MX for the domain 
points to the filtering service and they relay checked email.  I need to 
limit access to just these network blocks but also allow sasl 
authenticated as well as the internal network.


I also do not want to blindly trust this service so i would like to 
check the IP address as well as ensuring the recipient is for my domain.


can someone point me to an example or man page.  I cannot seem to find 
anything related to limiting inbound smtp clients/servers.


Vernon


Minimal config:

# main.cf

# do not include filter service IPs in mynetworks
mynetworks = 127.0.0.0/8 ...
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  check_client_access cidr:/etc/postfix/filter_service
  reject

# filter_service
192.1.0.0/24  OK
... other cidr ranges filter service uses ...


  -- Noel Jones

Re: Restrict external hosts

[Vernon A. Fort]

Noel Jones wrote:

Vernon A. Fort wrote:
I have a setup which we use an external mail filtering service and 
need to limit/restrict external client access.  Meaning the MX for 
the domain points to the filtering service and they relay checked 
email.  I need to limit access to just these network blocks but also 
allow sasl authenticated as well as the internal network.


I also do not want to blindly trust this service so i would like to 
check the IP address as well as ensuring the recipient is for my domain.


can someone point me to an example or man page.  I cannot seem to 
find anything related to limiting inbound smtp clients/servers.


Vernon


Minimal config:

# main.cf

# do not include filter service IPs in mynetworks
mynetworks = 127.0.0.0/8 ...
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  check_client_access cidr:/etc/postfix/filter_service
  reject

# filter_service
192.1.0.0/24  OK
... other cidr ranges filter service uses ...


  -- Noel Jones

Hey Noel,
 What i have now under the smtpd_*_restrictions:

smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_etrn_restrictions = reject
smtpd_recipient_restrictions =
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_helo_access .
  check_sender_access ...
  check_client_access (for white listing client sites - just in 
case they get rbl listed)

  reject_rbl_client 
  permit
smtpd_data_restrictions =
  reject_unauth_pipelining,
  permit

What i 'thinking' of is:

smtpd_sender_restrictions =
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  check_client_access cidr:/etc/postfix/filter_service.cidr,
  reject

The filter_service.cidr would look like
   1.2.3.4/29  OK
   1.2.4.4/29  OK
   0.0.0.0/0REJECT

Would it be redundant to have the permit_sasl and permit_mynetworks 
under both the smtpd_client and smtpd_recipient?


Vernon


 

RE: mysql lookup errors

[MacShane, Tracy]

 
> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of /dev/rob0
> Sent: Tuesday, 3 March 2009 7:31 AM
> To: postfix-users@postfix.org
> Subject: Re: mysql lookup errors
> 
> On Mon March 2 2009 12:51:23 kj wrote:
> > I'm seeing this in the logs:
> >
> > Mar  2 18:18:05 web postfix/cleanup[27207]: warning: mysql query
> > failed: MySQL server has gone away
> snip
> > Mar  2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48 
> > from=
> snip
> > RHEL5, with the stock Red Hat rpm recompiled with mysql support.
> 
> That RPM is probably chroot'ed by the distributor. My first 
> guess is that you're seeing a chroot problem. My second 
> guess, SELinux. In either case, seek support from your vendor 
> for these problems.
> 

RedHat does not have Postfix chrooting enabled in the distro by default
- it seems to be more the Debian-based distros that have that problem.
Also, I've never had any problems with SELinux and Postfix in stock RH
installs (although I haven't used it with MySql)

Re: Restrict external hosts

[Noel Jones]

Vernon A. Fort wrote:

Noel Jones wrote:

Vernon A. Fort wrote:
I have a setup which we use an external mail filtering service and 
need to limit/restrict external client access.  Meaning the MX for 
the domain points to the filtering service and they relay checked 
email.  I need to limit access to just these network blocks but also 
allow sasl authenticated as well as the internal network.


I also do not want to blindly trust this service so i would like to 
check the IP address as well as ensuring the recipient is for my domain.


can someone point me to an example or man page.  I cannot seem to 
find anything related to limiting inbound smtp clients/servers.


Vernon


Minimal config:

# main.cf

# do not include filter service IPs in mynetworks
mynetworks = 127.0.0.0/8 ...
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  check_client_access cidr:/etc/postfix/filter_service
  reject

# filter_service
192.1.0.0/24  OK
... other cidr ranges filter service uses ...


  -- Noel Jones

Hey Noel,
 What i have now under the smtpd_*_restrictions:

smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_etrn_restrictions = reject
smtpd_recipient_restrictions =
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_helo_access .
  check_sender_access ...
  check_client_access (for white listing client sites - just in case 
they get rbl listed)

  reject_rbl_client 
  permit
smtpd_data_restrictions =
  reject_unauth_pipelining,
  permit

What i 'thinking' of is:

smtpd_sender_restrictions =
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  check_client_access cidr:/etc/postfix/filter_service.cidr,
  reject

The filter_service.cidr would look like
   1.2.3.4/29  OK
   1.2.4.4/29  OK
   0.0.0.0/0REJECT

Would it be redundant to have the permit_sasl and permit_mynetworks 
under both the smtpd_client and smtpd_recipient?


Vernon









You (usually) need permit_sasl_authenticated and 
permit_mynetworks under each smtpd_*_restrictions in use to 
exempt trustworthy clients from those checks.  If you use a 
whitelist you will likely need to duplicate that under each 
section too.  That's one reason it's often easier to put 
everything under smtpd_recipient_restrictions.


To add additional restrictions, refer to the example I 
provided earlier:

# do not include filter service IPs in mynetworks
mynetworks = 127.0.0.0/8 ...
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  ... other restrictions here ...
  check_client_access cidr:/etc/postfix/filter_service
  reject

Important Note: the various check_client_access, 
reject_rbl_client, various helo checks, and 
reject_unauth_pipelining restrictions will see the filter 
service connection info - not the original sender - so they 
are quite limited in usefulness to you.  You could use 
reject_rhsbl_sender to reject bad sender domains if you can 
find a service that you consider trustworthy enough for 
rejections.


  -- Noel Jones

Re: Restrict external hosts

[Vernon A. Fort]

Noel Jones wrote:

Vernon A. Fort wrote:

Noel Jones wrote:

Vernon A. Fort wrote:
I have a setup which we use an external mail filtering service and 
need to limit/restrict external client access.  Meaning the MX for 
the domain points to the filtering service and they relay checked 
email.  I need to limit access to just these network blocks but 
also allow sasl authenticated as well as the internal network.


I also do not want to blindly trust this service so i would like to 
check the IP address as well as ensuring the recipient is for my 
domain.


can someone point me to an example or man page.  I cannot seem to 
find anything related to limiting inbound smtp clients/servers.


Vernon


Minimal config:

# main.cf

# do not include filter service IPs in mynetworks
mynetworks = 127.0.0.0/8 ...
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  check_client_access cidr:/etc/postfix/filter_service
  reject

# filter_service
192.1.0.0/24  OK
... other cidr ranges filter service uses ...


  -- Noel Jones

Hey Noel,
 What i have now under the smtpd_*_restrictions:

smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_etrn_restrictions = reject
smtpd_recipient_restrictions =
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_helo_access .
  check_sender_access ...
  check_client_access (for white listing client sites - just in 
case they get rbl listed)

  reject_rbl_client 
  permit
smtpd_data_restrictions =
  reject_unauth_pipelining,
  permit

What i 'thinking' of is:

smtpd_sender_restrictions =
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  check_client_access cidr:/etc/postfix/filter_service.cidr,
  reject

The filter_service.cidr would look like
   1.2.3.4/29  OK
   1.2.4.4/29  OK
   0.0.0.0/0REJECT

Would it be redundant to have the permit_sasl and permit_mynetworks 
under both the smtpd_client and smtpd_recipient?


Vernon


   




You (usually) need permit_sasl_authenticated and permit_mynetworks 
under each smtpd_*_restrictions in use to exempt trustworthy clients 
from those checks.  If you use a whitelist you will likely need to 
duplicate that under each section too.  That's one reason it's often 
easier to put everything under smtpd_recipient_restrictions.


To add additional restrictions, refer to the example I provided earlier:
# do not include filter service IPs in mynetworks
mynetworks = 127.0.0.0/8 ...
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  permit_mynetworks
  reject_unauth_destination
  ... other restrictions here ...
  check_client_access cidr:/etc/postfix/filter_service
  reject

Important Note: the various check_client_access, reject_rbl_client, 
various helo checks, and reject_unauth_pipelining restrictions will 
see the filter service connection info - not the original sender - so 
they are quite limited in usefulness to you.  You could use 
reject_rhsbl_sender to reject bad sender domains if you can find a 
service that you consider trustworthy enough for rejections.


  -- Noel Jones
I agree, the simpler the better.  With the cidr file, i ONLY want to 
accept email from this filter service meaning do i need to put the 
0.0.0.0/0 REJECT at the end of the list?


Vernon

Re: Restrict external hosts

[Noel Jones]

Vernon A. Fort wrote:
I agree, the simpler the better.  With the cidr file, i ONLY want to 
accept email from this filter service meaning do i need to put the 
0.0.0.0/0 REJECT at the end of the list?


Vernon


The "reject" after the check_client_access takes care 
rejecting any client not permitted by the cidr table (or other 
rules), and makes it clear at a glance that nothing else will 
be accepted.


That said, adding 0.0.0.0/0 REJECT at the end of the cidr 
table isn't exactly wrong, just unnecessary.


  -- Noel Jones

Re: Prioritising outgoing mail

[Wouter van Marle]

On Mon, 2009-03-02 at 11:18 -0500, Victor Duchovni wrote:
> On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote:
> 
> >> Use a custom transport for these messages with a low concurrency limit,
> >
> > You mean like installing sendmail or so in parallel to postfix and then 
> > have sendmail send out the lower-priority mails?
> 
> No I mean a Postfix "transport", as in transport(5) and master(5).

The problem of a transport map (I have just read the man page, which as
usual is highly technical so I am not sure whether I fully understand
the purpose and working of transport maps) is that there is a huge
overlap between receivers of the low-priority mail list and regular
e-mail receivers. Most of the regular e-mail receivers also receive this
mail list.

Many of my mail list receivers are on common domains like gmail.com and
yahoo.com, thus this would slow down all other mails to those domains as
well, even if they are not part of the mail list.

Setting it per recipient is not a good idea because of maintenance
issues (keeping mail list and transport map in sync), and because of the
regular mails that may be sent to those recipients while a mail list run
is in progress.

The idea of using a "slow:" transport as suggested in the transport(5)
man page (without elaborating unfortunately...) to limit the number of
smtp deamons that sounds like the way to go to me. Then I can reserve 80
deamons for the mail list, or maybe 50, enough to saturate my uplink -
still allowing regular mails to have an smtp available to be handled
immediately. This appears to me a way to let the other mails "jump the
queue" and be processed with priority. That there is little bandwidth
available is not too much of an issue, then it might take a minute
instead of seconds to send out, still a major improvement of the hours
it may take in the current situation.

> >> or use traffic shaping in the TCP stack to limit the bandwidth per
> >> SMTP connection.
> >
> > And how would that get certain mails out with priority? It sounds to me 
> > like this would slow down the overall process. I have up to 100 smtp 
> > processes running at a time, but as long as new mails end up at the back of 
> > the queue still no progress there. They have to come first.
> 
> It would not, but you won't saturate the entire link with any given email,
> leaving enough room for other traffic. If you can limit the concurrency
> of this particular message, then you'll have some bandwidth left over for
> other messages.

I don't like that idea very much: when I have only a few mails to send
out, I want them to go with the maximum speed possible. I have 2 Mbit
available, so with 100 smtp connections could limit it to say 20 kbit
per smtp process. But that would leave the rest of my bandwidth idle
when there are less than 100 active smtp connections, which is the case
like 90% of the time.

Wouter.


> 

Re: Prioritising outgoing mail

[Wouter van Marle]

Hi all,

Would it be possible to add an extension to the user's address, e.g.
user+s...@example.com, that would be mapped through a separate transport
(e.g. the slow: as suggested in the man page), and be rewritten by
trivial-rewrite to u...@example.com before being sent out.

An option like this would do the job for me. It would allow me to easily
maintain my maillist, rewriting addresses on the fly when creating the
mails, and allowing regular mails to be handled with priority.

And any ideas on how/where such a slow: transport (with a limited number
of smtp daemons to be started) would be configured? I can't find
anything about this in the man pages. Except that it is possible.

Wouter.

On Tue, 2009-03-03 at 11:25 +0800, Wouter van Marle wrote:
> On Mon, 2009-03-02 at 11:18 -0500, Victor Duchovni wrote:
> > On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote:
> > 
> > >> Use a custom transport for these messages with a low concurrency limit,
> > >
> > > You mean like installing sendmail or so in parallel to postfix and then 
> > > have sendmail send out the lower-priority mails?
> > 
> > No I mean a Postfix "transport", as in transport(5) and master(5).
> 
> The problem of a transport map (I have just read the man page, which as
> usual is highly technical so I am not sure whether I fully understand
> the purpose and working of transport maps) is that there is a huge
> overlap between receivers of the low-priority mail list and regular
> e-mail receivers. Most of the regular e-mail receivers also receive this
> mail list.
> 
> Many of my mail list receivers are on common domains like gmail.com and
> yahoo.com, thus this would slow down all other mails to those domains as
> well, even if they are not part of the mail list.
> 
> Setting it per recipient is not a good idea because of maintenance
> issues (keeping mail list and transport map in sync), and because of the
> regular mails that may be sent to those recipients while a mail list run
> is in progress.
> 
> The idea of using a "slow:" transport as suggested in the transport(5)
> man page (without elaborating unfortunately...) to limit the number of
> smtp deamons that sounds like the way to go to me. Then I can reserve 80
> deamons for the mail list, or maybe 50, enough to saturate my uplink -
> still allowing regular mails to have an smtp available to be handled
> immediately. This appears to me a way to let the other mails "jump the
> queue" and be processed with priority. That there is little bandwidth
> available is not too much of an issue, then it might take a minute
> instead of seconds to send out, still a major improvement of the hours
> it may take in the current situation.
> 
> > >> or use traffic shaping in the TCP stack to limit the bandwidth per
> > >> SMTP connection.
> > >
> > > And how would that get certain mails out with priority? It sounds to me 
> > > like this would slow down the overall process. I have up to 100 smtp 
> > > processes running at a time, but as long as new mails end up at the back 
> > > of 
> > > the queue still no progress there. They have to come first.
> > 
> > It would not, but you won't saturate the entire link with any given email,
> > leaving enough room for other traffic. If you can limit the concurrency
> > of this particular message, then you'll have some bandwidth left over for
> > other messages.
> 
> I don't like that idea very much: when I have only a few mails to send
> out, I want them to go with the maximum speed possible. I have 2 Mbit
> available, so with 100 smtp connections could limit it to say 20 kbit
> per smtp process. But that would leave the rest of my bandwidth idle
> when there are less than 100 active smtp connections, which is the case
> like 90% of the time.
> 
> Wouter.
> 
> 
> > 
> 
> 

Re: Prioritising outgoing mail

[Victor Duchovni]

On Tue, Mar 03, 2009 at 11:25:55AM +0800, Wouter van Marle wrote:

> On Mon, 2009-03-02 at 11:18 -0500, Victor Duchovni wrote:
> > On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote:
> > 
> > >> Use a custom transport for these messages with a low concurrency limit,
> > >
> > > You mean like installing sendmail or so in parallel to postfix and then 
> > > have sendmail send out the lower-priority mails?
> > 
> > No I mean a Postfix "transport", as in transport(5) and master(5).
> 
> The problem of a transport map (I have just read the man page, which as
> usual is highly technical so I am not sure whether I fully understand
> the purpose and working of transport maps) is that there is a huge
> overlap between receivers of the low-priority mail list and regular
> e-mail receivers. Most of the regular e-mail receivers also receive this
> mail list.

You may need to do sender-dependent routing for this sender, and inject
the mail into a different queue, or get the originating system to do
this directly.

> > It would not, but you won't saturate the entire link with any given email,
> > leaving enough room for other traffic. If you can limit the concurrency
> > of this particular message, then you'll have some bandwidth left over for
> > other messages.
> 
> I don't like that idea very much: when I have only a few mails to send
> out, I want them to go with the maximum speed possible. I have 2 Mbit
> available, so with 100 smtp connections could limit it to say 20 kbit
> per smtp process. But that would leave the rest of my bandwidth idle
> when there are less than 100 active smtp connections, which is the case
> like 90% of the time.

Does limiting bandwidth for small messages signicantly impact delivery
latency? Also who said you should divide the bandwidth 100-fold? You
give the slow transport 5 parallel threads, and up to half the bandwidth,
so each channel gets 10% of the bandwidth.

-- 
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.

Spam attacks

[Dave Johnson]

Hi all

Is there anyway of stopping the from "j...@foo.com" to "j...@foo.com" spam
attacks?

Regards

 

Re: Spam attacks

[Paweł Leśniak]

W dniu 2009-03-03 08:25, Dave Johnson pisze:

Hi all

Is there anyway of stopping the from "j...@foo.com" 
 to "j...@foo.com" spam attacks?




Hi

Without knowing your config it's hard to say what are you already doing.
Are you using SASL authentication? If not, have a look here: 
http://www.postfix.org/SASL_README.html#server_sasl
To get really useful help (not just speculations) you have to read 
http://www.postfix.org/DEBUG_README.html#mail


Pawel Lesniak