WalkWithMe to <my>@<mail.list>

Collaborators, who are, or want to be engineers and not just
part-changers, are invited to follow the progress and contribute
ideas, on how to send directly to a mail-list.

One day, you too may be painted into a corner:
ISP1, where you're subscribed/known to your mail-lists, won't
forward your mails unless you directly-dial-in, which you can no
longer do; and ISP2's email is out of order.

You only have internet access via ISP2; so the plan is to mail
DIRECTLY to <my>@<mail.list> as if "From: " <me>@ISP1.

Since it seems that very few people know how to do this
[dropping phrases doesn't qualify], let's make the journey into
a TUTORIAL. --------------------


Obviously this ascii-diagram needs fixed-sized-font for viewing:-

2. The SMTP Model

2.1 Basic Structure

The SMTP design can be pictured as:

+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
______________________________________
AFAICS we need to get the adr/IP of the <Server-SMTP>.
Simplistically I might think it's smtp.<mail.list>

I can't remember [find my log] right now;
but I saw something 'DNS-like'.

But now I get no meanigfull results from:
telnet smtp.<mail.list> 25 / 587? 465?
whois <my>@<mail.list>

BTW, I must PAY to go online, so I need to plan each time like a
shopping trip, to pay for the cost with other fetches. So I can't
just imediately test each idea, that comes to me.
So let's add to the shopping-list: RFC 974 (MX routing).
=> Obsoleted by: RFC 2821
This is becoming a LOONG journey ?!
----
The issue of routing email is older than the Internet, stemming from
the very earliest days of the ARPANET. Since the introduction of the
DNS in RFCs 882 and 883, the principles for email routing, as
presented in this RFC, have not changed. However, with the
relatively recent introduction of DNS Security (DNSSEC) in RFC 2065,
there may be changes to come. The general principles presented in
this RFC will hardly become very different, though.
--
The decision process always starts with making one or more queries =\=
to the DNS regarding a certain host's Mail Exchanger (MX) Resource
Records (RR). Depending on the answer(s) gotten, a decision is then
iterated. Aside of the expected and normal situations, a number of
error conditions and the appropriate actions for them are also
described.

---> Request for Comments: 2821
Obsoletes: 821, 974, 1869 April 2001
2.3.4 Host
2.3.8 Originator, Delivery, Relay, and Gateway Systems
2.3.10 Mailbox and Address

==> That's enough for today!

Thanks; to be continued.

BTW, the first mail-list is:
============ boundry between notes @ NwsPost ================
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
5. Address Resolution and Mail Handling <=!=!
Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host.
______________________________________
17.4.1. Mail Routing on the Internet
On the Internet, the destination host's configuration determines =\?
whether any specific mail routing is performed. The default is to
deliver the message to the destination by first determining what host
the message should be sent to and then delivering it directly to that =\?
host. Most Internet sites want to direct all inbound mail to a highly
available mail server that is capable of handling all this traffic and
have it distribute the mail locally. To announce this service, the site =\=
publishes a so-called MX record for its local domain in its DNS
database. MX stands for Mail Exchanger and basically states that the
server host is willing to act as a mail forwarder for all mail
addresses in the domain.
==> OK, that looks relevant.
MX records are always assigned a preference. This is a positive
....
==> OK, first see if we can fetch ANY records, before we check
their syntax.


EditTools.Store *
===> Trim out extra:--

#[1]Linux Network Administrators Guide [2]Electronic Mail [3]Email
Addresses [4]Configuring elm

Linux Network Administrators Guide
[5]Prev Chapter 17. Electronic Mail [6]Next
_______________________________________________________________________

17.4. How Does Mail Routing Work?

The process of directing a message to the recipient's host is called
routing. Apart from finding a path from the sending site to the
destination, it involves error checking and may involve speed and cost
optimization.

There is a big difference between the way a UUCP site handles routing
and the way an Internet site does. On the Internet, the main job of
directing data to the recipient host (once it is known by its IP
address) is done by the IP networking layer, while in the UUCP zone,
the route has to be supplied by the user or generated by the mail
transfer agent.

17.4.1. Mail Routing on the Internet

On the Internet, the destination host's configuration determines =\?
whether any specific mail routing is performed. The default is to
deliver the message to the destination by first determining what host
the message should be sent to and then delivering it directly to that =\?
host. Most Internet sites want to direct all inbound mail to a highly
available mail server that is capable of handling all this traffic and
have it distribute the mail locally. To announce this service, the site =\=
publishes a so-called MX record for its local domain in its DNS
database. MX stands for Mail Exchanger and basically states that the
server host is willing to act as a mail forwarder for all mail
addresses in the domain. MX records can also be used to handle traffic
for hosts that are not connected to the Internet themselves, like UUCP
networks or FidoNet hosts that must have their mail passed through a
gateway.

MX records are always assigned a preference. This is a positive
integer. If several mail exchangers exist for one host, the mail
transport agent will try to transfer the message to the exchanger with
the lowest preference value, and only if this fails will it try a host
with a higher value. If the local host is itself a mail exchanger for
the destination address, it is allowed to forward messages only to MX =\=
hosts with a lower preference than its own; this is a safe way of
avoiding mail loops. If there is no MX record for a domain, or no MX
records left that are suitable, the mail transport agent is permitted
to see if the domain has an IP address associated with it and attempt =\=
delivery directly to that host.

Suppose that an organization, say Foobar, Inc., wants all its mail
handled by its machine mailhub. It will then have MX records like this
in the DNS database:
green.foobar.com. IN MX 5 mailhub.foobar.com.

This announces mailhub.foobar.com as a mail exchanger for
green.foobar.com with a preference of 5. A host that wishes to deliver
a message to checks DNS and finds the MX record
pointing at mailhub. If there's no MX with a preference smaller than 5,
the message is delivered to mailhub, which then dispatches it to green.

This is a very simple description of how MX records work. For more
information on mail routing on the Internet, refer to RFC-821, RFC-974,
and RFC-1123.

17.4.2. Mail Routing in the UUCP World
-- snip --

17.4.3. Mixing UUCP and RFC-822
-- snip --

_______________________________________________________________________

[12]Prev [13]Home [14]Next
Email Addresses [15]Up Configuring elm

References

1. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/index.html
2. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.html
3. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.address.html
4. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.elm.html
5. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.address.html
6. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.elm.html
7. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.routing.html#FTN.X-087-2-FNMA06
8. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.routing.html#X-087-2-MAIL.ROUTING.INTERNET
9. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.routing.html#FTN.X-087-2-FNMA07
10. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.routing.html#X-087-2-FNMA06
11. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.routing.html#X-087-2-FNMA07
12. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.address.html
13. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/index.html
14. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.elm.html
15. file://localhost/mnt/hd/home/crg/NtwrkAdmDocm/nag2/x-087-2-mail.html
Fri Oct 19 05:30:48 SAST 2012
=============================

-> /mnt/FC1 locate RFC ==
/usr/share/doc/openssh-3.6.1p2/RFC.nroff
/mnt/p6/home/crg/ISPnet/AvianCarRFC
/mnt/p11/Inet/MAIL/gMail/RFC2821
/mnt/p11/Inet/TelCom.ETHno/RFCs
/mnt/p11/Inet/TelCom.ETHno/RFCs.Bak
/mnt/p11/leo2/NwsClient/mutt/RFC4MTA
/mnt/p11/leo2/NwsClient/mutt/RFC4MTA.Bak
/mnt/p11/leo2/NwsClient/RFC4eMail

2. The SMTP Model

2.1 Basic Structure

The SMTP design can be pictured as:

+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server

When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
D.1 A Typical SMTP Transaction Scenario
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<>
S: 250 OK
C: RCPT TO:<>
S: 250 OK
C: RCPT TO:<>
S: 550 No such user here
C: RCPT TO:<>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel


==> /mnt/hdc11/Inet/MAIL/gMail/RFC2821 == ..
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.8 Mail Gatewaying .............................................. 25
3.9 Terminating Sessions and Connections ......................... 27
4.1.3 Address Literals ........................................... 38
4.4 Trace Information ............................................ 49
4.5.3 Sizes and Timeouts ......................................... 54
5. Address Resolution and Mail Handling .......................... 60
7. Security Considerations ....................................... 64
7.5 Information Disclosure in Trace Fields ....................... 66
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71

3.5.2 VRFY Normal Response
....In order to facilitate parsing by both computers
and people, addresses SHOULD appear in pointed brackets. When
addresses, rather than free-form debugging information, are returned,
EXPN and VRFY MUST return only valid domain addresses that are usable
in SMTP RCPT commands.
3.5.3 Meaning of VRFY or EXPN Success Response
A server MUST NOT return a 250 code in response to a VRFY or EXPN
command unless it has actually verified the address.
....
5. Address Resolution and Mail Handling

Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.

When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.

==> File: index.html ==

6. Name Service and Resolver Configuration

6.1. The Resolver Library

6.2. How DNS Works

6.3. Running named
....
17. Electronic Mail

17.1. What Is a Mail Message?

17.2. How Is Mail Delivered?

17.3. Email Addresses

17.4. How Does Mail Routing Work?

17.5. Configuring elm

18. Sendmail

18.1. Introduction to sendmail

18.2. Installing sendmail

18.3. Overview of Configuration Files

18.4. The sendmail.cf and sendmail.mc Files

18.5. Generating the sendmail.cf File

18.6. Interpreting and Writing Rewrite Rules

18.7. Configuring sendmail Options

18.8. Some Useful sendmail Configurations

18.9. Testing Your Configuration

18.10. Running sendmail

18.11. Tips and Tricks

--> /mnt/DebDVD1bak
-> rdev == /dev/hdc17 /
--> which exim == /usr/sbin/exim
-> ls == ... =Lenny+Ovrflow=

19. Getting EximUp and Running

19.1. Running Exim

19.2. If Your Mail Doesn't Get Through

19.3. Compiling Exim

19.4. Mail Delivery Modes

19.5. Miscellaneous config Options

19.6. Message Routing and Delivery

19.7. Protecting Against Mail Spam

19.8. UUCP Setup

==> use `links` to browse the <NetAdminGuide>

On most systems the same MTA is used for both local and remote delivery and is usually
invoked as /usr/sbin/sendmail, or on non-FSSTND compliant systems as /usr/lib/sendmail.

For remote delivery, the transport software used depends on the nature
of the link. Mail delivered over a network using
TCP/IP commonly uses Simple Mail Transfer Protocol (SMTP), which is
described in RFC-821. SMTP was designed to deliver mail directly to a
recipient's machine, negotiating the message transfer with the remote
side's SMTP daemon. Today it is common practice for organizations to
establish special hosts that accept all mail for recipients in the
organization and for that host to manage appropriate delivery to the
intended recipient.

Email addresses are made up of at least two parts. One part is the name
of a mail domain that will ultimately translate to
either the recipient's host or some host that accepts mail on
behalf of the recipient. The other part is some form of unique user
identification that may be the login name of that user, the real name
of that user in "Firstname.Lastname" format, or an arbitrary alias
that will be translated into a user or list of users.

17.3.1. RFC-822
Internet sites adhere to the RFC-822 standard, which requires the familiar
notation of , for which
host.domain is the host's fully qualified domain name. The character
separating the two is properly called a "commercial at" sign, but it
helps if you read it as "at." This notation does not specify a route
to the destination host. Routing of the mail message is left to the
mechanisms we'll describe shortly.

You will see a lot of RFC-822 if you run an Internet connected site. Its
use extends not only to mail, but has also spilled
over into other services, such as news.

In an RFC-822 environment, you should avoid using anything other than
absolute addresses, such as .

17.4. How Does Mail Routing Work?
The process of directing a message to the recipient's host is called
routing. Apart from finding a path from the sending site
to the destination, it involves error checking and may involve speed
and cost optimization.

On the Internet, the main job of directing data to the recipient host
(once it is known by its IP address) is done by the IP networking layer.

17.4.1. Mail Routing on the Internet
On the Internet, the destination host's configuration determines whether
any specific mail routing is performed. The default
is to deliver the message to the destination by first determining what
host the message should be sent to and then delivering it directly
to that host. Most Internet sites want to direct all inbound mail to
a highly available mail server that is capable of handling all this
traffic and have it distribute the mail locally. To announce this
service, the site publishes a so-called MX record for its local domain
in its DNS database. MX stands for Mail Exchanger and basically states
that the server host is willing to act as a mail forwarder for all
mail addresses in the domain.

MX records are always assigned a preference. This is a positive
integer. If several mail exchangers exist for one host, the
mail transport agent will try to transfer the message to the exchanger
with the lowest preference value, and only if this fails will it try a
host with a higher value. If the local host is itself a mail exchanger
for the destination address, it is allowed to forward messages only
to MX hosts with a lower preference than its own; this is a safe
way of avoiding mail loops. If there is no MX record for a domain,
or no MX records left that are suitable, the mail transport agent is
permitted to see if the domain has an IP address associated with it
and attempt delivery directly to that host.

Suppose that an organization, say Foobar, Inc., wants all its mail
handled by its machine mailhub. It will then have MX
records like this in the DNS database:

green.foobar.com. IN MX 5 mailhub.foobar.com.
This announces mailhub.foobar.com as a mail exchanger for
green.foobar.com with a preference of 5. A host that wishes to
deliver a message to checks DNS and finds the MX
record pointing at mailhub. If there's no MX with a preference smaller
than 5, the message is delivered to mailhub, which then dispatches
it to green.

This is a very simple description of how MX records work. For more
information on mail routing on the Internet, refer to
RFC-821, RFC-974, and RFC-1123.
=====================
18.8.3. Using a Smart Host

Sometimes a host finds mail that it is unable to deliver directly to
the desired remote host. It is often convenient to have
a single host on a network take on the role of managing transmission
of mail to remote hosts that are difficult to reach, rather than have
each local host try to do this independently.

There are a few good reasons to have a single host take on mail
management. You can simplify management by having only one
host with a comprehensive mail configuration that knows how to handle
all of the different mail transport types, such as UUCP, Usenet,
etc. All other hosts need only a single tranport protocol to send
their mail to this central host. Hosts that fill this central mail
routing and forwarding role are called smart hosts. If you have a
smart host that will accept mail from you, you can send it mail of
any sort and it will manage the routing and transmission of that mail
to the desired remote destinations.

Another good application for smart host configurations is to manage
transmission of mail across a private firewall. An
organization may elect to install a private IP network and use their
own, unregistered IP addresses. The private network may be connected
to the Internet through a firewall. Sending mail to and from hosts
in the private network to the outside world using SMTP would not be
possible in a conventional configuration because the hosts are not
able to accept or establish direct network connections to hosts on the
Internet. Instead, the organization could elect to have the firewall
provide a mail smart host function. The smart host running on the
firewall is able to establish direct network connections with hosts
both on the private network and on the Internet. The smart host would
accept mail from both hosts on the private network and the Internet,
store them in local storage and then manage the retransmission of
that mail to the correct host directly.

Smart hosts are usually used when all other methods of delivery have
failed. In the case of the organization with the private
network, it would be perfectly reasonable to have the hosts attempt
to deliver mail directly first, and if that fails then to send it
to the smart host. This relieves the smart host of a lot of traffic
because other hosts can directly send mail to other hosts on the
private network.

sendmail provides a simple method of configuring a smart host using the
SMART_HOST feature; when implementing it in the
Virtual Brewery configuration, we do exactly this. The relevant
portions of our configuration that define the smart host are:

define(`SMART_HOST', `uucp-new:moria')
LOCAL_NET_CONFIG
# This rule ensures that all local mail is delivered using the
# smtp transport, everything else will go via the smart host.
R$* < @ $* .$m. > $* $#smtp [email protected] $2.$m. $: $1 < @ $2.$m. > $3

The SMART_HOST macro allows you to specify the host that should relay
all outgoing mail that you are unable to deliver
directly, and the mail transport protocol to use to talk to it.

In our configuration we are using the uucp-new transport to UUCP host
moria. If we wanted to configure sendmail to use an
SMTP-based Smart Host, we would instead use something like:

define(`SMART_HOST', `mail.isp.net')

We don't need to specify SMTP as the transport, as it is the default.

Can you guess what the LOCAL_NET_CONFIG macro and the rewrite rule might be doing?

The LOCAL_NET_CONFIG macro allows you to add raw sendmail rewrite rules
to your configuration that define what mail should
stay within the local mail system. In our example, we've used a
rule that matches any email address where the host belongs to our
domain (.$m.) and rewrite it so that it is sent directly to the
SMTP mailer. This ensures that any message for a host on our local
domain is directed immediately to the SMTP mailer and forwarded to
that host, rather than falling through to our smart host, which is
the default treatment.
----------------------------------------
18.9. Testing Your Configuration

The m4 command processes the macro definition files according to its
own syntax rules without understanding anything about
correct sendmail syntax; so there won't be any error messages
if you've gotten anything wrong in your macro definition file.
For this reason, it is very important that you thoroughly test your
configuration. Fortunately, sendmail provides a relatively easy way <--*!
of doing this.
==> cont ....
=> 18.10. Running sendmail ....
==> 18.11. Tips and Tricks ...
Chapter 19. Getting EximUp and Running
.....
You can check that Exim is correctly set up for receiving incoming SMTP
messages by telnetting to the SMTP port on your
machine. This is what a successful connect to the SMTP server looks
like:
$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 richard.vbrew.com ESMTP Exim 3.13 #1 Sun, 30 Jan 2000 16:23:55 +0600
quit
221 richard.brew.com closing connection
Connection closed by foreign host.

==> telnet localhost smtp
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

If this test doesn't produce the SMTP banner (the line starting with
the 220 code), check that you are either running an Exim
daemon process or have inetd correctly configured. If that doesn't
reveal the problem, look in the Exim log files (described next)
in case there is an error in Exim's configuration file.

19.2. If Your Mail Doesn't Get Through
A number of features are available for troubleshooting installation
problems. The first place to check is Exim's log files.
On Linux systems they are normally kept in /var/log/exim/log and
are named exim_mainlog, exim_rejectlog, and exim_paniclog. On other
operating systems, they are often kept in /var/spool/exim/log. You
can find out where the log files are by running the command:
....

===> /usr/doc/sendmail-8.14.3/op/op.me == ...
mail routing facility under the UNIXr operating system. It
is not tied to any one transport protocol -- its function
may be likened to a crossbar switch, relaying messages from
one domain into another. In the process, it can do a lim-
ited amount of message header editing to put the message
into a format that is appropriate for the receiving domain.
All of this is done under the control of a configuration
file.
....
Sendmail is based on RFC 821 (Simple Mail Transport
Protocol), RFC 822 (Internet Mail Headers Format), RFC 974 =\=
(MX routing), RFC 1123 (Internet Host Requirements), RFC
1413 (Identification server), RFC 1652 (SMTP 8BITMIME Exten-
sion), RFC 1869 (SMTP Service Extensions), RFC 1870 (SMTP
SIZE Extension), RFC 1891 (SMTP Delivery Status Notifica-
tions), RFC 1892 (Multipart/Report), RFC 1893 (Enhanced Mail
System Status Codes), RFC 1894 (Delivery Status Notifica-
tions), RFC 1985 (SMTP Service Extension for Remote Message
Queue Starting), RFC 2033 (Local Message Transmission Proto-
col), RFC 2034 (SMTP Service Extension for Returning

 

Bye motherfucker! KILLFILED!!!

 

Nah, it's more fun to post a 627 line rant to a newsgroup.

I've come to the conclusion that Chris doesn't really want to solve his
problems, he just wants to whine.

I usually just ignore him, but this post was just so over the top.

Jerry

 

How would you do that [apart from polite & carefully] ifand your man-servant ran away with you mule?

As previously indicated, I'll log my findings because perhaps some
adults will read here in future, and we want to share our efforts,
even if not polite & carefully.

Based of various RFCs as previouslly posted in this thread, it seemed
that mailing to the remote smtp-server was viable.

In this specific case the final address was to be:


Although I've gorgotten, my logs show what I was trying to test.
= first I repeated an old familiar smtp via telnet, then I did/got:--

=> phil4.ethz.ch [129.132.183.133] 25 (smtp) open
220 phil4.ethz.ch ESMTP Exim 4.69 Tue, 23 Oct 2012 20:14:26 +0200
EHLO absamail.co.za
250-phil4.ethz.ch Hello absamail.co.za [41.174.14.7]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250 HELP
MAIL FROM:<****@absamail.co.za>
250 OK
RCPT TO:<>
550 41.174.14.7 blacklisted at zen.dnsbl.ethz.ch 127.0.0.11
QUIT
221 phil4.ethz.ch closing connection
sent 94, rcvd 287
===============
And 41.174.14.7 was the dynamic IP allocated my ISP2,
who've been gonna-fix-email-real-soon-now for 3 months.

Blacklisting the sending IP seems a good viable way to keep
bad-mails out provided the zillions of dynamically allocated
IPs can be 'masked' in a reasonably small set.

Currently my /var/log/messages has only got the last 6
on-line-sessions, and they've all been allocated 41.174.*.*

So the system works, as intended to keep me out.
Who here knows if/how the dynamic IPs are grouped to
be blacklisted?

Oh crap, in the above log, I was not actually absamail.co.za
Just that I must appear as absamail.co.za to my mail-list.

Theoretically it could be determined that 41.174.14.7
doesn't 'belong' to absamail. But I don't think that's
the problem.