WalkWithMe to <my>@<mail.list>

Discussion in 'Linux Networking' started by no.top.post, Oct 23, 2012.

  1. no.top.post

    no.top.post Guest

    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
     
    no.top.post, Oct 23, 2012
    #1
    1. Advertisements

  2. no.top.post

    Anonymous Guest

    Bye motherfucker! KILLFILED!!!
     
    Anonymous, Oct 23, 2012
    #2
    1. Advertisements

  3. no.top.post

    Jerry Peters Guest

    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
     
    Jerry Peters, Oct 23, 2012
    #3
  4. no.top.post

    no.top.post Guest

    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.
     
    no.top.post, Nov 4, 2012
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.