Postfix doesn't send EHLO
Ralf Hildebrandt
# postconf|grep ehlo
smtp_always_send_ehlo = yes
smtp_discard_ehlo_keyword_address_maps =
smtp_discard_ehlo_keywords =
smtp_never_send_ehlo = no
smtpd_discard_ehlo_keyword_address_maps =
smtpd_discard_ehlo_keywords =
smtpd_proxy_ehlo = $myhostname
According to this, postfix should be using EHLO in any case. But:
Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 220 ************************************************************************************************
Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: HELO mail.charite.de
Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 250 mail.klinikum-lev.de Hello [160.45.207.131]
Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: MAIL FROM:<Ralf.Hil...@charite.de>
Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 250 <Ralf.Hil...@charite.de>: Sender Ok
Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: RCPT TO:<reci...@klinikum-lev.de>
Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 250 <reci...@klinikum-lev.de>: Recipient Ok
Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: DATA
Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 354 mail.klinikum-lev.de: Send data now. Terminate with "."
Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: .
Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 250 mail.klinikum-lev.de: Message accepted for delivery
Oct 4 11:03:29 mail postfix/smtp[5136]: 12C1D1668B7: to=<reci...@klinikum-lev.de>, relay=pop.klinikum-lev.de[195.71.206.27]:25, delay=0.35,
delays=0.17/0.01/0.07/0.1, dsn=2.0.0, status=sent (250 mail.klinikum-lev.de: Message accepted for delivery)
Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: QUIT
I know, it's a PIX there on the other side, but I always thought
"smtp_always_send_ehlo = yes" would cause Postfix to try
EHLO $smtp_helo_name
in any case, because, after all, it would work:
# telnet pop.klinikum-lev.de 25
Trying 195.71.206.27...
Connected to pop.klinikum-lev.de.
Escape character is '^]'.
220 ***************************************************************************************************************************************
EHLO mail.charite.de
250-mail.klinikum-lev.de supports the following ESMTP extensions:
250-SIZE 5242880
250-DSN
250-8bitmime
250 XA
QUIT
221 mail.klinikum-lev.de closing connection. Goodbye!
Connection closed by foreign host.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Why you can't find your system administrators:
has slashed her/his wrists on the Answerbook(tm) or Univers CD.
Ralf Hildebrandt
> I'm trying to get postfix to use ESMTP when sending to us...@klinikum-lev.de:
>
> # postconf|grep ehlo
> smtp_always_send_ehlo = yes
> smtp_discard_ehlo_keyword_address_maps =
> smtp_discard_ehlo_keywords =
> smtp_never_send_ehlo = no
> smtpd_discard_ehlo_keyword_address_maps =
> smtpd_discard_ehlo_keywords =
> smtpd_proxy_ehlo = $myhostname
I also have no transport_maps entries that refer to
pop.klinikum-lev.de or klinikum-lev.de:
mail:/etc/postfix# grep -i lev.de *
main.cf:debug_peer_list = pop.klinikum-lev.de
I made sure that no old transport_maps entries have effect on the mail:
mail:/etc/postfix# postsuper -r D4188166521
postsuper: D4188166521: requeued
postsuper: Requeued: 1 message
And still:
mail:/etc/postfix# postfix flush && tail -f /var/log/mail.log|grep -i lev
Oct 4 11:22:17 mail postfix/smtp[16418]: < pop.klinikum-lev.de[195.71.206.27]: 220 ************************************************************************************************
Oct 4 11:22:17 mail postfix/smtp[16418]: > pop.klinikum-lev.de[195.71.206.27]: HELO mail.charite.de
Oct 4 11:22:17 mail postfix/smtp[16418]: < pop.klinikum-lev.de[195.71.206.27]: 250 mail.klinikum-lev.de Hello [160.45.207.131]
Oct 4 11:22:17 mail postfix/smtp[16418]: > pop.klinikum-lev.de[195.71.206.27]: MAIL FROM:<sen...@charite.de>
Oct 4 11:22:17 mail postfix/smtp[16418]: < pop.klinikum-lev.de[195.71.206.27]: 250 <sen...@charite.de>: Sender Ok
Oct 4 11:22:17 mail postfix/smtp[16418]: > pop.klinikum-lev.de[195.71.206.27]: RCPT TO:<reci...@klinikum-lev.de>
Oct 4 11:22:17 mail postfix/smtp[16418]: < pop.klinikum-lev.de[195.71.206.27]: 250 <reci...@klinikum-lev.de>: Recipient Ok
Oct 4 11:22:17 mail postfix/smtp[16418]: > pop.klinikum-lev.de[195.71.206.27]: DATA
Oct 4 11:22:17 mail postfix/smtp[16418]: < pop.klinikum-lev.de[195.71.206.27]: 354 mail.klinikum-lev.de: Send data now. Terminate with "."
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Why you can't find your system administrators:
they've snapped, started muttering about "this damned post office", and left for the nearest gun store
Ralf Hildebrandt
BTW: mail_version = 2.4-20060930
Robert Felber
> I'm trying to get postfix to use ESMTP when sending to us...@klinikum-lev.de:
>
> # postconf|grep ehlo
> smtp_always_send_ehlo = yes
> smtp_discard_ehlo_keyword_address_maps =
> smtp_discard_ehlo_keywords =
> smtp_never_send_ehlo = no
> smtpd_discard_ehlo_keyword_address_maps =
> smtpd_discard_ehlo_keywords =
> smtpd_proxy_ehlo = $myhostname
>
> According to this, postfix should be using EHLO in any case. But:
>
> Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 220 ************************************************************************************************
> Oct 4 11:03:29 mail postfix/smtp[5136]: > pop.klinikum-lev.de[195.71.206.27]: HELO mail.charite.de
Do you have some mail-scanning-reinjection?
If so, you should probably set smtp_always_send_ehlo in your master.cf
for the reinjection-smtpd
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
Ralf Hildebrandt
> Do you have some mail-scanning-reinjection?
Yes.
> If so, you should probably set smtp_always_send_ehlo in your master.cf
> for the reinjection-smtpd
smtpd doesn't use smtp options :) Or does it?
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Look what sendmail just dragged in:
Ah, so if SMTP is a dog, does that imply that sendmail is a cat? It'd
make sense, given that cats will often drag in nasty little dying
things & drop them lovingly in front of you.
A female cat. Because sometimes, sendmail is a bitch.
Robert Felber
> Do you have some mail-scanning-reinjection?
> If so, you should probably set smtp_always_send_ehlo in your master.cf
> for the reinjection-smtpd
s/smtpd/smtp/
However, nevermind. It defaults to "yes".
Ralf Hildebrandt
> On Wed, Oct 04, 2006 at 11:40:26AM +0200, Robert Felber wrote:
> > Do you have some mail-scanning-reinjection?
> > If so, you should probably set smtp_always_send_ehlo in your master.cf
> > for the reinjection-smtpd
>
> s/smtpd/smtp/
>
> However, nevermind. It defaults to "yes".
Indeed. I tried this on another box in Braunschweig and that one also
doesn't send EHLO.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Yes, Microsoft are such a small company and can't possibly keep things
backwards-compatible between two contiguous Windows versions.
Robert Felber
> * Robert Felber <r.fe...@ek-muc.de>:
> > On Wed, Oct 04, 2006 at 11:40:26AM +0200, Robert Felber wrote:
> > > Do you have some mail-scanning-reinjection?
> > > If so, you should probably set smtp_always_send_ehlo in your master.cf
> > > for the reinjection-smtpd
> >
> > s/smtpd/smtp/
> >
> > However, nevermind. It defaults to "yes".
>
> Indeed. I tried this on another box in Braunschweig and that one also
> doesn't send EHLO.
Same here (postfix 2.3.3). I've a tcpdump (ascii) of the session.
Robert Felber
> > On Wed, Oct 04, 2006 at 11:40:26AM +0200, Robert Felber wrote:
> > > Do you have some mail-scanning-reinjection?
> > > If so, you should probably set smtp_always_send_ehlo in your master.cf
> > > for the reinjection-smtpd
> >
> > s/smtpd/smtp/
> >
> > However, nevermind. It defaults to "yes".
>
> Indeed. I tried this on another box in Braunschweig and that one also
> doesn't send EHLO.
Is there no way that they turn off "SMTP Fu^Hixup Protocol"? Or maybe an update
of their PIX may help.
Wietse Venema
That proves nothing unless it's recorded at the SENDING end.
Wietse
Ralf Hildebrandt
> > Same here (postfix 2.3.3). I've a tcpdump (ascii) of the session.
>
> That proves nothing unless it's recorded at the SENDING end.
Where else would Norbert record it?
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Gates' Law: Every 18 months, the speed of software halves.
Wietse Venema
> I'm trying to get postfix to use ESMTP when sending to us...@klinikum-lev.de:
>
> # postconf|grep ehlo
> smtp_always_send_ehlo = yes
> smtp_discard_ehlo_keyword_address_maps =
> smtp_discard_ehlo_keywords =
> smtp_never_send_ehlo = no
> smtpd_discard_ehlo_keyword_address_maps =
> smtpd_discard_ehlo_keywords =
> smtpd_proxy_ehlo = $myhostname
>
> According to this, postfix should be using EHLO in any case. But:
>
> Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 220 ************************************************************************************************
Postfix turns off ESMTP when talking to a PIX crippled system.
Did you forget that PIX fixup caused all kinds of protocol damage?
Wietse
Ralf Hildebrandt
> > According to this, postfix should be using EHLO in any case. But:
> >
> > Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 220 ************************************************************************************************
>
> Postfix turns off ESMTP when talking to a PIX crippled system.
Ah, that explains it. It should log that, though.
> Did you forget that PIX fixup caused all kinds of protocol damage?
Of course not, but in this particular case it's really evil:
* I try to send a 9MB file
* The receiving side times out
(that's of course an error on the receiving side, since it should
refuse the mail with a proper error code!)
I found out that the receiving side only supports a message size of up
to 5MB. Postfix would have never even tried sending mail there if it
had seen the SIZE announcement.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
"My computer's sick. I think my modem is a carrier."
Ralf Hildebrandt
> I found out that the receiving side only supports a message size of up
> to 5MB. Postfix would have never even tried sending mail there if it
> had seen the SIZE announcement.
Hmm, would it be feasible to actually have postfix look at the ESMTP
Options and use SOME of them (like the SIZE extension), while ignoring
other stuff ESMTP offers (like the ESMTP command pipelining) --
whenever a PIX is detected?
donovan
On Oct 4, 2006, at 5:10 AM, Ralf Hildebrandt wrote:
> I'm trying to get postfix to use ESMTP when sending to
> us...@klinikum-lev.de:
>
> # postconf|grep ehlo
> smtp_always_send_ehlo = yes
-- always send
> smtp_discard_ehlo_keyword_address_maps =
> smtp_discard_ehlo_keywords =
> smtp_never_send_ehlo = no
-- never send
> smtpd_discard_ehlo_keyword_address_maps =
> smtpd_discard_ehlo_keywords =
> smtpd_proxy_ehlo = $myhostname
>
> According to this, postfix should be using EHLO in any case. But:
these two lines make me go hmmm
-jeff
Ralf Hildebrandt
> >smtp_always_send_ehlo = yes
> -- always send
always send = yes.
> >smtp_never_send_ehlo = no
> -- never send
No:
never send no == always send
> these two lines make me go hmmm
Your comment makes me go "hmm" :)
I fixed the problem by patching the code, duznno if that was wise,
though.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Radioactive cats have 18 half-lives.
Wietse Venema
[ Charset UTF-8 unsupported, converting... ]
> * Wietse Venema <wie...@porcupine.org>:
>
> > > According to this, postfix should be using EHLO in any case. But:
> > >
> > > Oct 4 11:03:29 mail postfix/smtp[5136]: < pop.klinikum-lev.de[195.71.206.27]: 220 ************************************************************************************************
> >
> > Postfix turns off ESMTP when talking to a PIX crippled system.
>
> Ah, that explains it. It should log that, though.
If you want this logged, you're welcome.
Currently, Postfix only logs when it enables the <CRLF>.<CRLF>
workaround, which happens only for "old" mail.
if ((session->features & SMTP_FEATURE_MAYBEPIX) != 0
&& request->msg_stats.incoming_arrival.tv_sec
<= vstream_ftime(session->stream) - var_smtp_pix_thresh) {
msg_info("%s: enabling PIX <CRLF>.<CRLF> workaround for %s",
request->queue_id, session->namaddrport);
> I found out that the receiving side only supports a message size of up
> to 5MB. Postfix would have never even tried sending mail there if it
> had seen the SIZE announcement.
With PIX fixup enabled, the client never finds out that the server
supports the SIZE extension.
I have even better news for you: as of 20061002, Postfix no longer
sends SIZE information when it sends 8bit mail to a destination
that does not announce 8BITMIME support.
Wietse
Wietse Venema
> * Ralf Hildebrandt <Ralf.Hil...@charite.de>:
>
> > I found out that the receiving side only supports a message size of up
> > to 5MB. Postfix would have never even tried sending mail there if it
> > had seen the SIZE announcement.
>
> Hmm, would it be feasible to actually have postfix look at the ESMTP
> Options and use SOME of them (like the SIZE extension), while ignoring
> other stuff ESMTP offers (like the ESMTP command pipelining) --
> whenever a PIX is detected?
Last time I looked, PIX fixup mode didn't allow EHLO commands.
Wietse
Ralf Hildebrandt
> > Hmm, would it be feasible to actually have postfix look at the ESMTP
> > Options and use SOME of them (like the SIZE extension), while ignoring
> > other stuff ESMTP offers (like the ESMTP command pipelining) --
> > whenever a PIX is detected?
>
> Last time I looked, PIX fixup mode didn't allow EHLO commands.
Some do, some don't! From my logs:
Some do:
========
pop.klinikum-lev.de
mx1.mail.faseb.org
mail.kages.at
Some don't:
===========
mx4.informatik.uni-tuebingen.de
mx.elysee.de
vector.dalsemi.com
Some are broken:
================
bastion.klinikum-magdeburg.de
(look at the SIZE announced!)
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
The secret of flying is simple: Throw yourself at the ground and miss.
Victor Duchovni
> With PIX fixup enabled, the client never finds out that the server
> supports the SIZE extension.
>
> I have even better news for you: as of 20061002, Postfix no longer
> sends SIZE information when it sends 8bit mail to a destination
> that does not announce 8BITMIME support.
Still, if the other side announces a limit, messages larger than the
limit (prior to any 7bit downgrade) are not sent... (7bit downgrade
never shrinks the message size). Yes, there is typically a size window
where the server may ultimately reject the message, but for most messages
the "SIZE" option prevents needless transmission.
Back to the PIX issue, disabling ESMTP is still appropriate IMHO.
--
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:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
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.
Ralf Hildebrandt
> Back to the PIX issue, disabling ESMTP is still appropriate IMHO.
Especially given that example:
# telnet bastion.klinikum-magdeburg.de 25
Trying 141.44.122.90...
Connected to bastion.klinikum-magdeburg.de.
Escape character is '^]'.
220 *********************************************************************************************************************
EHLO foo
250-bastion.klinikum-magdeburg.de supports the following ESMTP
extensions:
250 SIZE 0
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
"Lotus Notes for Dummies" is surely a single page pull out with
"don't" printed on it.
Ralf Hildebrandt
> * Victor Duchovni <Victor....@MorganStanley.com>:
>
> > Back to the PIX issue, disabling ESMTP is still appropriate IMHO.
>
> Especially given that example:
>
> # telnet bastion.klinikum-magdeburg.de 25
> Trying 141.44.122.90...
> Connected to bastion.klinikum-magdeburg.de.
> Escape character is '^]'.
> 220 *********************************************************************************************************************
> EHLO foo
> 250-bastion.klinikum-magdeburg.de supports the following ESMTP
> extensions:
> 250 SIZE 0
Ahem:
A parameter value of 0 (zero) indicates that no fixed maximum message size is in force.
Sorry for the noise.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Quoted-Printable : a standard for mangling Internet messages
Quoted-Unreadable : the result of applying said standard
Unquoted-Unprintable: the comments from the recipients of the above
Duncan Hill
> * Victor Duchovni <Victor....@MorganStanley.com>:
> > Back to the PIX issue, disabling ESMTP is still appropriate IMHO.
>
> Especially given that example:
>
> # telnet bastion.klinikum-magdeburg.de 25
> Trying 141.44.122.90...
> Connected to bastion.klinikum-magdeburg.de.
> Escape character is '^]'.
> 220
> ***************************************************************************
>******************************************
I'm starting to suspect you're seeing PIX OS 6.x vs 7.x. 7.x removes the
fixup command, but puts in an alternate methodology. Work wiki has the
comment:
"For PIX version 7 and higher, the fixup command has been deprecated - see
Cisco PIX Upgrade Guide 6.2/6.3 to 7.0. The functionality is now achieved
with the inspect command."
Never seen a 7.x box though, so I can't state with certainty that that's it.
You might also be seeing boxes that -behave- like a PIX with the *s, but are
something diffferent (hence allowing EHLO).
mouss
> [snip]
> Some are broken:
> ================
> bastion.klinikum-magdeburg.de
> (look at the SIZE announced!)
>
>
but it doesn't want to tell you.
Victor Duchovni
I think the best way to advertise this is:
250-SIZE
rather than:
250-SIZE 0
Wietse Venema
> On Wed, Oct 04, 2006 at 10:34:38PM +0200, mouss wrote:
>
> > Ralf Hildebrandt wrote:
> > >[snip]
> > >Some are broken:
> > >================
> > >bastion.klinikum-magdeburg.de
> > >(look at the SIZE announced!)
> > >
> > >
> > "SIZE 0" is perfectly ok. it means it has no size limitation or it has
> > but it doesn't want to tell you.
>
> I think the best way to advertise this is:
>
> 250-SIZE
>
> rather than:
>
> 250-SIZE 0
mouss is almost correct:
A parameter value of 0 (zero) indicates that no fixed maximum
message size is in force. If the parameter is omitted no
information is conveyed about the server's fixed maximum message
size;
The form "250 SIZE 0" means there is no size limitation, while
"250 SIZE" means that the server won't reveal the limit explicitly.
Wieste
Wietse Venema
20061005
Cleanup: make CISCO PIX bug workarounds configurable. This
introduces new parameters: smtp_pix_workarounds (default:
disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
(workarounds indexed by server IP address). The default
settings are backwards compatible. File: smtp/smtp.c,
smtp/smtp_proto.c.
In some distant future, these defaults may change.
With Postfix mostly feature complete, the snapshot releases will
be dominated by "Cleanup" and "Bugfix" updates. In this case, the
cleaning up is about making hard-coded behavior configurable.
Wietse
Ralf Hildebrandt
> Citing from the HISTORY file:
>
> 20061005
>
> Cleanup: make CISCO PIX bug workarounds configurable. This
> introduces new parameters: smtp_pix_workarounds (default:
> disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
> (workarounds indexed by server IP address). The default
> settings are backwards compatible. File: smtp/smtp.c,
> smtp/smtp_proto.c.
Cool, thanks!
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.postfix-buch.com
Why you can't find your system administrators:
He was arrested cause the police thought he was a Drug dealer when they saw the three pagers on his belt..
Victor Duchovni
> Citing from the HISTORY file:
>
> 20061005
>
> Cleanup: make CISCO PIX bug workarounds configurable. This
> introduces new parameters: smtp_pix_workarounds (default:
> disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
> (workarounds indexed by server IP address). The default
> settings are backwards compatible. File: smtp/smtp.c,
> smtp/smtp_proto.c.
Is a table indexed by server IP address the right interface? IP addresses
are more volatile than recipient domain names, and my guess at the right
interface would be transport(5) to select a suitable master(5) smtp(8)
clone transport with options suitable for the destination in question.
While the transport(5) approach forces undesirable master.cf tweaks,
it has the advantage of not forcing one to use hard-coded IP addresses.
I think that the master.cf tweaks are the lesser evil.
Victor Duchovni
> While the transport(5) approach forces undesirable master.cf tweaks,
> it has the advantage of not forcing one to use hard-coded IP addresses.
> I think that the master.cf tweaks are the lesser evil.
Perhaps the best of both words would be a table indexed by the nexthop?
Sure this will apply the same policy for all MX hosts, not all of
which will have the same firewall, but it in practice this will not be
an issue...
Wietse Venema
> On Thu, Oct 05, 2006 at 02:21:20PM -0400, Wietse Venema wrote:
>
> > Citing from the HISTORY file:
> >
> > 20061005
> >
> > Cleanup: make CISCO PIX bug workarounds configurable. This
> > introduces new parameters: smtp_pix_workarounds (default:
> > disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
> > (workarounds indexed by server IP address). The default
> > settings are backwards compatible. File: smtp/smtp.c,
> > smtp/smtp_proto.c.
>
> Is a table indexed by server IP address the right interface? IP addresses
> are more volatile than recipient domain names, and my guess at the right
> interface would be transport(5) to select a suitable master(5) smtp(8)
> clone transport with options suitable for the destination in question.
You can still do that:
-o smtp_pix_workaround_maps=foo,bar
> While the transport(5) approach forces undesirable master.cf tweaks,
> it has the advantage of not forcing one to use hard-coded IP addresses.
> I think that the master.cf tweaks are the lesser evil.
I give people both options.
Finally, it's not the end of the world if we add domain name
support to the ehlo/pixbug lookup tables.
It just is not clear for me what the user interface would be like:
indexed by nexthop, by server, or both?
Wietse
Victor Duchovni
> You can still do that:
>
> -o smtp_pix_workaround_maps=foo,bar
Yes, indeed. A nexthop table could obviate the transport(5) indirection,
but the functionality is there either way.
> > While the transport(5) approach forces undesirable master.cf tweaks,
> > it has the advantage of not forcing one to use hard-coded IP addresses.
> > I think that the master.cf tweaks are the lesser evil.
>
> I give people both options.
>
> Finally, it's not the end of the world if we add domain name
> support to the ehlo/pixbug lookup tables.
>
> It just is not clear for me what the user interface would be like:
> indexed by nexthop, by server, or both?
On further reflection, perhaps (given that we are fine-tuning transmission
to hosts behind firewalls, not domains) the IP lookup is the best approach.
CIDR maps can be used to cover containing blocks to allow minor renumbering
within a netblock.