Is there any way to set sending system to allow iptables (firewall) on
the receiving system use separate rate control for "at once" delivery
attempts and queue runs?

Using different IP addresses will not play well with grey-listing.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Go slowly to the entertainments of thy friends, but quickly to their
misfortunes.
-- Chilo

In article <873aypaihr.fsf [at] anfi.homeunix.com> Andrzej Adam Filip
<anfi [at] onet.eu> writes:
>Is there any way to set sending system to allow iptables (firewall) on
>the receiving system use separate rate control for "at once" delivery
>attempts and queue runs?

Is this a sendmail question?:-)

>Using different IP addresses will not play well with grey-listing.

Well, other things that come to mind for a general answer are source
port (range) and TOS bits. For a sendmail answer, you could perhaps
arrange for one or the other to use a mailer with the 'R' flag set.

--Per Hedeland
per [at] hedeland.org

per [at] hedeland.org (Per Hedeland) writes:

> In article <873aypaihr.fsf [at] anfi.homeunix.com> Andrzej Adam Filip
> <anfi [at] onet.eu> writes:
>>Is there any way to set sending system to allow iptables (firewall) on
>>the receiving system use separate rate control for "at once" delivery
>>attempts and queue runs?
>
> Is this a sendmail question?:-)

Sendmail has a long lasting history of fixing "deficiencies" of other
soft :-)

>>Using different IP addresses will not play well with grey-listing.
>
> Well, other things that come to mind for a general answer are source
> port (range) and TOS bits. For a sendmail answer, you could perhaps
> arrange for one or the other to use a mailer with the 'R' flag set.

Do *you* think playing with TOS would be cost effective?

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
The scum also rises.
-- Dr. Hunter S. Thompson

In article <87k5rzaaec.fsf [at] anfi.office-on-the.net> Andrzej Adam Filip
<anfi [at] onet.eu> writes:
>per [at] hedeland.org (Per Hedeland) writes:
>
>> In article <873aypaihr.fsf [at] anfi.homeunix.com> Andrzej Adam Filip
>> <anfi [at] onet.eu> writes:
>>>Is there any way to set sending system to allow iptables (firewall) on
>>>the receiving system use separate rate control for "at once" delivery
>>>attempts and queue runs?
>>
>> Is this a sendmail question?:-)
>
>Sendmail has a long lasting history of fixing "deficiencies" of other
>soft :-)
>
>>>Using different IP addresses will not play well with grey-listing.
>>
>> Well, other things that come to mind for a general answer are source
>> port (range) and TOS bits. For a sendmail answer, you could perhaps
>> arrange for one or the other to use a mailer with the 'R' flag set.
>
>Do *you* think playing with TOS would be cost effective?

I guess it comes back to my first question above - if you want a
sendmail answer, there is no support for setting the TOS bits from
within sendmail, and doing it for the purpose in question would
basically be a pretty gross hack, so it's likely that you'd end up with
a "private" source mod => not a lot of fun, but if that's what it
takes... Using the 'R' flag for this is a pretty gross hack too, but at
least it's readily available => if it can work, use that instead.

--Per Hedeland
per [at] hedeland.org

per [at] hedeland.org (Per Hedeland) writes:

> In article <87k5rzaaec.fsf [at] anfi.office-on-the.net> Andrzej Adam Filip
> <anfi [at] onet.eu> writes:
>>per [at] hedeland.org (Per Hedeland) writes:
>>
>>> In article <873aypaihr.fsf [at] anfi.homeunix.com> Andrzej Adam Filip
>>> <anfi [at] onet.eu> writes:
>>>>Is there any way to set sending system to allow iptables (firewall) on
>>>>the receiving system use separate rate control for "at once" delivery
>>>>attempts and queue runs?
>>>
>>> Is this a sendmail question?:-)
>>
>>Sendmail has a long lasting history of fixing "deficiencies" of other
>>soft :-)
>>
>>>>Using different IP addresses will not play well with grey-listing.
>>>
>>> Well, other things that come to mind for a general answer are source
>>> port (range) and TOS bits. For a sendmail answer, you could perhaps
>>> arrange for one or the other to use a mailer with the 'R' flag set.
>>
>>Do *you* think playing with TOS would be cost effective?
>
> I guess it comes back to my first question above - if you want a
> sendmail answer, there is no support for setting the TOS bits from
> within sendmail, and doing it for the purpose in question would
> basically be a pretty gross hack, so it's likely that you'd end up with
> a "private" source mod => not a lot of fun, but if that's what it
> takes... Using the 'R' flag for this is a pretty gross hack too, but at
> least it's readily available => if it can work, use that instead.

R flag makes sendmail use ports<1024 reserved on unixes for sole use by
root => it makes sendmail run as root

I would like a solution `usable' by sendmail not seeing root privileges
even for a millisecond.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
What we do not understand we do not possess.
-- Goethe

In article <87vebitndx.fsf [at] anfi.office-on-the.net> Andrzej Adam Filip
<anfi [at] onet.eu> writes:
>per [at] hedeland.org (Per Hedeland) writes:
>
>> In article <87k5rzaaec.fsf [at] anfi.office-on-the.net> Andrzej Adam Filip
>> <anfi [at] onet.eu> writes:
>>>per [at] hedeland.org (Per Hedeland) writes:
>>>
>>>> In article <873aypaihr.fsf [at] anfi.homeunix.com> Andrzej Adam Filip
>>>> <anfi [at] onet.eu> writes:
>>>>>Is there any way to set sending system to allow iptables (firewall) on
>>>>>the receiving system use separate rate control for "at once" delivery
>>>>>attempts and queue runs?
>>>>
>>>> Is this a sendmail question?:-)
>>>
>>>Sendmail has a long lasting history of fixing "deficiencies" of other
>>>soft :-)
>>>
>>>>>Using different IP addresses will not play well with grey-listing.
>>>>
>>>> Well, other things that come to mind for a general answer are source
>>>> port (range) and TOS bits. For a sendmail answer, you could perhaps
>>>> arrange for one or the other to use a mailer with the 'R' flag set.
>>>
>>>Do *you* think playing with TOS would be cost effective?
>>
>> I guess it comes back to my first question above - if you want a
>> sendmail answer, there is no support for setting the TOS bits from
>> within sendmail, and doing it for the purpose in question would
>> basically be a pretty gross hack, so it's likely that you'd end up with
>> a "private" source mod => not a lot of fun, but if that's what it
>> takes... Using the 'R' flag for this is a pretty gross hack too, but at
>> least it's readily available => if it can work, use that instead.
>
>R flag makes sendmail use ports<1024 reserved on unixes for sole use by
>root => it makes sendmail run as root

Not strictly true, some Unices allow you to give this capability to
non-root processes.

>I would like a solution `usable' by sendmail not seeing root privileges
>even for a millisecond.

Well, you could have mentioned that at the outset to save some wasted
time, given that in a standard sendmail setup remote SMTP connections
will always be initiated by a process running as root.

Anyway, modulo your OS being capability-capable per above, I guess
you're then left with a "private" source mod - either to use two
different "unprivileged" source port ranges or to diddle the TOS bits.
At least I can't think of any other properties of the connection that
are a) user-process-settable and b) likely to survive through the
network - given that you've already excluded source IP address.

Well, possibly you could use different source IP addresses after all,
but source-NAT the incoming connections to the same address *after*
applying the rate control - not sure if iptables is able to do such a
thing, but it's theoretically possible at least.

Or modify the greylisting to treat the particular two IP addresses as
identical. Or just live with greylisting kicking in initially.

--Per Hedeland
per [at] hedeland.org

per [at] hedeland.org (Per Hedeland) writes:

> In article <87vebitndx.fsf [at] anfi.office-on-the.net> Andrzej Adam Filip
> <anfi [at] onet.eu> writes:
>>per [at] hedeland.org (Per Hedeland) writes:
>>
>>> In article <87k5rzaaec.fsf [at] anfi.office-on-the.net> Andrzej Adam Filip
>>> <anfi [at] onet.eu> writes:
>>>>per [at] hedeland.org (Per Hedeland) writes:
>>>>
>>>>> In article <873aypaihr.fsf [at] anfi.homeunix.com> Andrzej Adam Filip
>>>>> <anfi [at] onet.eu> writes:
>>>>>>Is there any way to set sending system to allow iptables (firewall) on
>>>>>>the receiving system use separate rate control for "at once" delivery
>>>>>>attempts and queue runs?
>>>>>
>>>>> Is this a sendmail question?:-)
>>>>
>>>>Sendmail has a long lasting history of fixing "deficiencies" of other
>>>>soft :-)
>>>>
>>>>>>Using different IP addresses will not play well with grey-listing.
>>>>>
>>>>> Well, other things that come to mind for a general answer are source
>>>>> port (range) and TOS bits. For a sendmail answer, you could perhaps
>>>>> arrange for one or the other to use a mailer with the 'R' flag set.
>>>>
>>>>Do *you* think playing with TOS would be cost effective?
>>>
>>> I guess it comes back to my first question above - if you want a
>>> sendmail answer, there is no support for setting the TOS bits from
>>> within sendmail, and doing it for the purpose in question would
>>> basically be a pretty gross hack, so it's likely that you'd end up with
>>> a "private" source mod => not a lot of fun, but if that's what it
>>> takes... Using the 'R' flag for this is a pretty gross hack too, but at
>>> least it's readily available => if it can work, use that instead.
>>
>>R flag makes sendmail use ports<1024 reserved on unixes for sole use by
>>root => it makes sendmail run as root
>
> Not strictly true, some Unices allow you to give this capability to
> non-root processes.
>
>>I would like a solution `usable' by sendmail not seeing root privileges
>>even for a millisecond.
>
> Well, you could have mentioned that at the outset to save some wasted
> time, given that in a standard sendmail setup remote SMTP connections
> will always be initiated by a process running as root.

You have wasted no time :-)
I tell you what I would like as the perfect solution (for me),
you 'refreshed my memory' about something that can be used in
*unpatched* sendmail (including older versions).

> Anyway, modulo your OS being capability-capable per above, I guess
> you're then left with a "private" source mod - either to use two
> different "unprivileged" source port ranges or to diddle the TOS bits.
> At least I can't think of any other properties of the connection that
> are a) user-process-settable and b) likely to survive through the
> network - given that you've already excluded source IP address.

Playing with TOS (priority to be specific) seems to be the most
straightforward patch (very similar to setting size of TCP buffers).

> Well, possibly you could use different source IP addresses after all,
> but source-NAT the incoming connections to the same address *after*
> applying the rate control - not sure if iptables is able to do such a
> thing, but it's theoretically possible at least.
>
> Or modify the greylisting to treat the particular two IP addresses as
> identical. Or just live with greylisting kicking in initially.


--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Last guys don't finish nice.
-- Stanley Kelley, on the cult of victory at all costs

On 08/11/07 16:06, Andrzej Adam Filip wrote:
> Is there any way to set sending system to allow iptables (firewall)
> on the receiving system use separate rate control for "at once"
> delivery attempts and queue runs?

One major problem that I see with what you are wanting to do is that
what ever you are trying to do will have to be supported on the
receiving system. And it sounds like you will be sending traffic to
random receiving systems that you have no control over. In such cases,
just about any thing you will do will probably not work based on the
lack of support on the receiving end.

> Using different IP addresses will not play well with grey-listing.

Agreed.

About the only thing that comes to mind that might be possible would be
some form of alternate port and / or port knocking or the likes.
However such a set up will imply that there is pre-existing support for
what you are trying to do on the receiving end, which would beg the
question why can't the receiving end be set up to not apply such
restrictions to the sending system.



Grant. . . .

Grant Taylor <gtaylor [at] riverviewtech.net> writes:

>[...]
> About the only thing that comes to mind that might be possible would be
> some form of alternate port and / or port knocking or the likes.
> However such a set up will imply that there is pre-existing support for
> what you are trying to do on the receiving end, which would beg the
> question why can't the receiving end be set up to not apply such
> restrictions to the sending system.

Because the sending system does not know current load of the receiving system.

Under "normal load" the objective is to achieve email delivery time
below a few seconds (<10s). Under heavy load the objective is to keep
delivery time below a few minutes (<10m) [if possible].

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
"The chain which can be yanked is not the eternal chain."
-- G. Fitch

On 08/15/07 11:58, Andrzej Adam Filip wrote:
> Because the sending system does not know current load of the
> receiving system.

Right. Again, with out some sort of prior established arrangement, what
you are wanting to do is not possible. There is no standard (that I'm
aware of) to allow two systems with out a prior established arrangement
to communicate load level information or any thing else to alter normal
operating conditions (i.e. rejection of messages based on load). I'm
sure that something exists to allow servers to establish a prior
arrangement to do this, but your server will never have such with 99+%
of the servers on the web.

> Under "normal load" the objective is to achieve email delivery time
> below a few seconds (<10s). Under heavy load the objective is to keep
> delivery time below a few minutes (<10m) [if possible].

Agreed.

If you are worried about your messages making it to the receiving
server(s) in a timely manner, play with your queue intervals. I.e. have
a very short retry queue, a longer queue, a longer yet queue, and a
really long queue. Have messages go from queue to queue with each retry
being successively slower and slower. This way, your messages will
retry delivery quickly in the first queue and then be migrated to slower
queues for persistently temp failing messages so that you do not fill
your logs.



Grant. . . .