Prev: how to re-write postfix headers
Next: Provide XFORWARDed attributes to policy server?
From: Robert Lopez on 26 May 2010 12:26
This college has a contract with Rave Messaging to deliver high volume
(ex campus emergency) communications via many vectors including email.

In their requirements document, in the portion on email, they write:

"IMPORTANT NOTE: When an emergency alert is sent by your institution,
Rave will open multiple SMTP connections and attempt to send a large
number of emails in a short period of time. Please ensure that there
are no throttling or spam rules that would slow or prevent the
delivery of these emails from Rave."

Below is the output of postconf -n (redacted for critical spamhause key).

I am wondering about pipelining.

Given this statement from http://www.postfix.com/postconf.5.html :

"reject_unauth_pipelining
Reject the request when the client sends SMTP commands ahead of
time where it is not allowed, or when the client sends SMTP
commands ahead of time without knowing that Postfix actually
supports ESMTP command pipelining. This stops mail from bulk mail
software that improperly uses ESMTP command pipelining in order to
speed up deliveries.
With Postfix 2.6 and later, the SMTP server sets a per-session
flag whenever it detects illegal pipelining, including pipelined
EHLO or HELO commands. The reject_unauth_pipelining feature simply
tests whether the flag was set at any point in time during the
session.
With older Postfix versions, reject_unauth_pipelining checks the
current status of the input read queue, and its usage is not
recommended in contexts other than smtpd_data_restrictions."

Does the term unauth imply there is also authorized pipelining?
If so, what document describes authorizing it for an external site?

Using Postfix 2.5.5 currently (Redhat latest), it seems the use
I have of reject_unauth_pipelining under smtpd_client_restrictions.
If I now move it to under smtpd_data_restrictions how will that
impact the "throttling" the Wave company does not want?

$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = yes
biff = no
bounce_size_limit = 1
config_directory = /etc/postfix
default_process_limit = 400
header_checks = regexp:/etc/postfix/header_checks
inet_interfaces = all
mailbox_size_limit = 0
masquerade_domains = $mydomain, cnm.edu, nmvc.org, nmvirtualcollege.org
max_use = 100
message_size_limit = 16777216
mydestination = $myhostname, $mydomain,
localhost.localdomain, cnm.edu, mail.cnm.edu
myhostname = mg04.cnm.edu
mynetworks = 198.133.182.0/24, 198.133.181.0/24, 198.133.180.0/24,
172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8, 127.0.0.0/8
[::ffff:127.0.0.0]/104 [::1]/128
notify_classes = resource, software
readme_directory = no
recipient_delimiter = +
relay_domains = mg04.cnm.edu, mg05.cnm.edu, mg06.cnm.edu, nmvc.org,
mail.nmvc.org, mg04.nmvc.org, mg05.nmvc.org, mg06.nmvc.org,
nmvirtualcollege.org, mail.nmvirtualcollege.org,
mg04.nmvirtualcollege.org,mg05. nmvirtualcollege.org,
mg05.nmvirtualcollege.org, nmln.net, ideal-nm.org, ideal-nm.net,
idealnm.org, idealnm.net
relayhost =
smtp_host_lookup = dns, native
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_restrictions = reject_unauth_pipelining
check_client_access hash:/etc/postfix/whitelist check_client_access
cidr:/etc/postfix/cidr-ip check_client_access hash:/etc/postfix/access
permit_mynetworks reject_rbl_client
<SNIP>.zen.dq.spamhaus.net reject_rbl_client
bl.spamcop.net reject_rbl_client dnsbl.njabl.org reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.4 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.5 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.6 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.7 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.8 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.9 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.10 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.11 reject_rbl_client
blackholes.five-ten-sg.com=127.0.0.13
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks check_helo_access
hash:/etc/postfix/helo-ip reject_invalid_hostname reject_non_fqdn_helo_hostname
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/greylist check_sender_access
hash:/etc/postfix/access
permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit_mynetworks reject_unauth_destination
reject_unknown_recipient_domain reject_unlisted_recipient
check_recipient_access
hash:/etc/postfix/overquota reject_non_fqdn_recipient reject_unknown_recipient_domain
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtualaliases


--
Robert Lopez
Unix Systems Administrator
Central New Mexico Community College (CNM)
525 Buena Vista SE
Albuquerque, New Mexico 87106

From: Wietse Venema on 26 May 2010 13:10
Robert Lopez:
> This college has a contract with Rave Messaging to deliver high volume
> (ex campus emergency) communications via many vectors including email.
>
> In their requirements document, in the portion on email, they write:
>
> "IMPORTANT NOTE: When an emergency alert is sent by your institution,
> Rave will open multiple SMTP connections and attempt to send a large
> number of emails in a short period of time. Please ensure that there
> are no throttling or spam rules that would slow or prevent the
> delivery of these emails from Rave."

If the system opens an insane number of SMTP connections to the
same SMTP server, then that will definitely be a problem.

Postfix enforces concurrency controls when it sends out mail, to
avoid such problems.

> "reject_unauth_pipelining
> Reject the request when the client sends SMTP commands ahead of
> time WHERE IT IS NOT ALLOWED, or when the client sends SMTP
> commands ahead of time WITHOUT KNOWING THAT POSTFIX ACTUALLY
> SUPPORTS ESMTP COMMAND PIPELINING.

a) the system sends commands together where it is not allowed by
RFC 2920, even after prior negotiation, or b) the system sends
commands together without prior negotiation as per RFC 2920.

Wietse

From: Robert Lopez on 26 May 2010 20:13
On Wed, May 26, 2010 at 11:10 AM, Wietse Venema <wietse(a)porcupine.org> wrote:
> Robert Lopez:
>> This college has a contract with Rave Messaging to deliver high volume
>> (ex campus emergency) communications via many vectors including email.
>>
>> In their requirements document, in the portion on email, they write:
>>
>> "IMPORTANT NOTE: When an emergency alert is sent by your institution,
>> Rave will open multiple SMTP connections and attempt to send a large
>> number of emails in a short period of time.  Please ensure that there
>> are no throttling or spam rules that would slow or prevent the
>> delivery of these emails from Rave."
>
> If the system opens an insane number of SMTP connections to the
> same SMTP server, then that will definitely be a problem.
>
> Postfix enforces concurrency controls when it sends out mail, to
> avoid such problems.
>
>> "reject_unauth_pipelining
>>     Reject the request when the client sends SMTP commands ahead of
>>     time WHERE IT IS NOT ALLOWED, or when the client sends SMTP
>>     commands ahead of time WITHOUT KNOWING THAT POSTFIX ACTUALLY
>>     SUPPORTS ESMTP COMMAND PIPELINING.
>
> a) the system sends commands together where it is not allowed by
> RFC 2920, even after prior negotiation, or b) the system sends
> commands together without prior negotiation as per RFC 2920.
>
>        Wietse
>

Thank you. Prior to reading RFC 2920 I was assuming that pipelining was
a bad thing done by spammers. I never comprehended it could be a good thing
if managed by both ends correctly.

At a web meeting today I was told they will use 40 concurrent connections.
With the default max connection limit (given no other server resource limits)
I suppose that is not blasting an insane number of SMTP connections.

Would this situation be better if I moved reject_unauth_pipelining from
smtpd_client_restrictions to smtpd_data_restrictions, taking it out completely,
or leaving it as it is?


--
Robert Lopez
Unix Systems Administrator
Central New Mexico Community College (CNM)
525 Buena Vista SE
Albuquerque, New Mexico 87106

From: Wietse Venema on 26 May 2010 21:05
Robert Lopez:
> >> "reject_unauth_pipelining
> >> ? ? Reject the request when the client sends SMTP commands ahead of
> >> ? ? time WHERE IT IS NOT ALLOWED, or when the client sends SMTP
> >> ? ? commands ahead of time WITHOUT KNOWING THAT POSTFIX ACTUALLY
> >> ? ? SUPPORTS ESMTP COMMAND PIPELINING.
> >
> > a) the system sends commands together where it is not allowed by
> > RFC 2920, even after prior negotiation, or b) the system sends
> > commands together without prior negotiation as per RFC 2920.
> >
> > ? ? ? ?Wietse
> >
>
> Thank you. Prior to reading RFC 2920 I was assuming that pipelining was
> a bad thing done by spammers. I never comprehended it could be a good thing
> if managed by both ends correctly.
>
> At a web meeting today I was told they will use 40 concurrent connections.
> With the default max connection limit (given no other server resource limits)
> I suppose that is not blasting an insane number of SMTP connections.
>
> Would this situation be better if I moved reject_unauth_pipelining from
> smtpd_client_restrictions to smtpd_data_restrictions, taking it out completely,
> or leaving it as it is?

A properly-implemented sender will implement SMTP command pipelining
in a manner that respects RFC 2920.

I highly recommend that you run some tests before you make any
promises that the device will "work" with your mail system.

I think that many sites would object to 40 simultaneous connections
without some prior agreement.

Wietse

 | 
Pages: 1
Prev: how to re-write postfix headers
Next: Provide XFORWARDed attributes to policy server?