It would be nice if you could place an IP address as the relay address in
smtproutes rather than a name that *has* to be in the DNS. This is especially
useful for domains that have yet to become visible or domains that use
unrouted internal addresses that are used as a gateway. Alternatively, it
would be nice if qmail-remote was not limited to relying on the resolver
library for the hosts nominated in smtproutes.
The classic case where this occurs is here:
Internet ----> qmail on firewall box ----> Internal network with
SMTP gateway
customer.dom
Typically, the firewall box is in the DNS as the primary MX for
customer.dom. In the qmail config I have either a set of .qmail forwards or
in a number of cases, an smtproute to the internal mail server.
In the case of the internal mail server, it may well not be in the DNS or
the customer may not want it in the DNS. In this case it is a pain to use
smtproutes as the solution to forwarding all mail for that domain.
The reasons for this is that you cannot put an IP address in there and you
cannot even put a host entry in their that's in /etc/hosts rather than the DNS.
So, some mechanism where you can make an entry into smtproutes that does not
rely on a resolved entry would be quite useful.
----
The second reason for mentioned this feature is that it is useful as an aid
in dealing with spam that is sent with bogus envelope sender addresses.
What do I mean by the bogus domains and spam? This:
Imagine you are getting a lot of inbound spam to your site. As usual the
spam has a bogus envelope sender address and mostly no sender address in the
body of the mail. In our case were we have a lot of email address come and
go, so it is often the case that we get left with hundreds of mails sitting in
the queue as a result of a bounce trying to get back to the bogus sending,
informing them of a non-existant user.
What I typically do when such spam is detected is the following:
1. Put them in the badmailfrom file to stop further inbound spam
2. Use tcpserver to block out their IP address
3. Put their nearest smtp server (either their's of their providers) into
smtproutes for the bogus email address.
Net effect, their smtp server gets the bounces back which they cannot double
bounce as their site is now rejected by qmail-smtp/tcpserver. Any recipients
of the
spam at our site who choose to reply can do so and again the smtp server at
the other end cannot double bounce. Typically I have found that the spammers
SMTP server will accept rcpt: <bogus address> especially as they typically
contain an @ so it generally works just fine.
Of course it is always the case that spammers can always bypass such
strategies, it does help to have a diversity of responses to such things and
the ability to smtp route a domain via IP address certain helps in this case.
Besides, it also makes me feel better seeing those bounces and customer
replies head back to the originating site knowing that they are now stuck on
their queue :>
Regards.
smtproutes rather than a name that *has* to be in the DNS. This is especially
useful for domains that have yet to become visible or domains that use
unrouted internal addresses that are used as a gateway. Alternatively, it
would be nice if qmail-remote was not limited to relying on the resolver
library for the hosts nominated in smtproutes.
The classic case where this occurs is here:
Internet ----> qmail on firewall box ----> Internal network with
SMTP gateway
customer.dom
Typically, the firewall box is in the DNS as the primary MX for
customer.dom. In the qmail config I have either a set of .qmail forwards or
in a number of cases, an smtproute to the internal mail server.
In the case of the internal mail server, it may well not be in the DNS or
the customer may not want it in the DNS. In this case it is a pain to use
smtproutes as the solution to forwarding all mail for that domain.
The reasons for this is that you cannot put an IP address in there and you
cannot even put a host entry in their that's in /etc/hosts rather than the DNS.
So, some mechanism where you can make an entry into smtproutes that does not
rely on a resolved entry would be quite useful.
----
The second reason for mentioned this feature is that it is useful as an aid
in dealing with spam that is sent with bogus envelope sender addresses.
What do I mean by the bogus domains and spam? This:
Imagine you are getting a lot of inbound spam to your site. As usual the
spam has a bogus envelope sender address and mostly no sender address in the
body of the mail. In our case were we have a lot of email address come and
go, so it is often the case that we get left with hundreds of mails sitting in
the queue as a result of a bounce trying to get back to the bogus sending,
informing them of a non-existant user.
What I typically do when such spam is detected is the following:
1. Put them in the badmailfrom file to stop further inbound spam
2. Use tcpserver to block out their IP address
3. Put their nearest smtp server (either their's of their providers) into
smtproutes for the bogus email address.
Net effect, their smtp server gets the bounces back which they cannot double
bounce as their site is now rejected by qmail-smtp/tcpserver. Any recipients
of the
spam at our site who choose to reply can do so and again the smtp server at
the other end cannot double bounce. Typically I have found that the spammers
SMTP server will accept rcpt: <bogus address> especially as they typically
contain an @ so it generally works just fine.
Of course it is always the case that spammers can always bypass such
strategies, it does help to have a diversity of responses to such things and
the ability to smtp route a domain via IP address certain helps in this case.
Besides, it also makes me feel better seeing those bounces and customer
replies head back to the originating site knowing that they are now stuck on
their queue :>
Regards.