8------------------- ; [...] ; ; MTBL line added to define the SMTP relay channel which uses a ; smarthost, followed by the usual SMTP channel that uses DNS ; MTBL show="SMTP relay channel", name=smtprlychn, file=smtp-relay.chn, flags=channel MTBL show="SMTP channel", name=smtpchn, flags=ns, flags=channel ; ; [...] ; ; Now we have the two SMTP delivery channels. First, the one that ; uses a channel file ... all of the parameters are cloned from ; the DNS-based SMTP delivery channel except where changes are ; needed ; MCHN show="SMTP Relay", name=smtprly, que=smtprly, tbl=smtprlychn, pgm=smtp, ap=same, ap=try, mod=imm, ttl=15, confstr="charset=7bit,hostname=my.host.name" ; ; And the usual DNS-based SMTP channel ; MCHN show="SMTP Delivery", name=smtp, que=smtp, tbl=smtpchn, pgm=smtp, ap=same, ap=try, mod=imm, ttl=15, confstr="charset=7bit,hostname=my.host.name" ; ; [...] --------------------8<--------(cut here)--------->8------------------- Then I create a channel file listing the hosts/domains which won't let me send directly to them, and the IP address of the relay server I use: --------------------8<--------(cut here)--------->8------------------- ; LHS is the name of the domain or host that won't accept mail ; directly from me ; RHS is the IP address of the relay server to use ; domain.name 10.10.10.10 other.domain 10.10.10.10 one.really.picky.host 10.10.10.10 need.a.different.smarthost 192.168.1.1 --------------------8<--------(cut here)--------->8------------------- You could even use different relay servers for different domains if necessary, as shown above. Note the format very carefully. At least in 5.0.5, the right-hand side must be an IP address - it cannot be a host name - and you can only use whitespace as a separator. If you use a host name, or use something like ": " as a separator, you will find that MMDF gets stuck in an infinite loop, using as much CPU time as it can, and (depending on your logging level) filling up your disk with log files as quickly as it can. Been there, done that. Now if only I could convince MMDF's smtp channel that a 5yz SMTP reply at any point in the conversation is a permanent error; aol.com, for instance, returns a 554 upon initial connection from a dialup/broadband site. To be fair to MMDF, this violates RFC821, and while RFC2821 permits it, AOL violates the requirement that the connection remain open after the 554. Despite the 5yz response, which in RFC821's explanation of SMTP return code theory indicates that the sender should not attempt exactly the same thing again, MMDF treats this as a temporary failure and keeps the mail in the queue rather than bouncing it, so unless I check the MMDF queue, I don't know my mail is being blocked until I get a warning MWARNTIME later. -- Stephen M. Dunn [ref][ref][ref] >>>----------------> http://www.stevedunn.ca/ <----------------<<<[/ref][/ref][/ref] ------------------------------------------------------------------ Say hi to my cat -- http://www.stevedunn.ca/photos/toby/ [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => [ref] => <20030923132528.A3282@magnatechonline.com> [htmlstate] => on_nl2br [postusername] => Stephen [ip] => stephen@stevedu [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 3 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) --> mmdf on 5.0.7 - splitting outgoing deliveries - SCO

mmdf on 5.0.7 - splitting outgoing deliveries - SCO

Hoping some kind soul can shed some light here. Openserver 5.0.7 with mmdf as MTA my server connection to the world has a dynamic IP from my ISP - i have no choice in the matter. If i set mmdf to do DNS lookup I can send to a lot of people email - however i can not send to earthlink/mindspring/aol as they are denying direct mail sent from anyone with a dynamic IP. If i set mmdf not to do DNS lookup and use my ISP (mail.optonline.net) as a smarthost, i can send fine to earthlink/mindspring/aol, but i can ...

  1. #1

    Default mmdf on 5.0.7 - splitting outgoing deliveries

    Hoping some kind soul can shed some light here.

    Openserver 5.0.7 with mmdf as MTA

    my server connection to the world has a dynamic IP from my ISP - i have
    no choice in the matter.

    If i set mmdf to do DNS lookup I can send to a lot of people email -
    however i can not send to earthlink/mindspring/aol as they are denying
    direct mail sent from anyone with a dynamic IP.

    If i set mmdf not to do DNS lookup and use my ISP (mail.optonline.net)
    as a smarthost, i can send fine to earthlink/mindspring/aol, but i can
    not post to many newsgroups as apparently some or all of optonline.net's
    mailservers are RBL'ed

    I'm pretty sure I had this working on my 5.0.5 system, by a combination
    approach of using both smart/badhost and listing places i'd send email
    to directly both in /etc/hosts (resolv.conf has local bind as resorder)
    as well as smtp.chn table file (probably should only need one of them
    but never found which), however either i'm not remembering correctly or
    something changed in 5.0.7

    ideas?

    --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    -Joe Chasan- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  2. #2

    Default Re: mmdf on 5.0.7 - splitting outgoing deliveries

    In article <com>,
    Joe Chasan <com> wrote: 

    You can do this by telling MMDF to *not* use DNS for domain lookups (no MDMN
    line that refers to a nameserver table), and instead list all of the hosts you
    want to send mail directly to in root.dom (not /etc/hosts). You can use DNS
    for smtp channel lookups; only hostnames that get through the domain lookup
    will get as far as a channel lookup.

    John
    --
    John DuBois com KC6QKZ/AE http://www.armory.com/~spcecdt/
    John Guest

  3. #3

    Default Re: mmdf on 5.0.7 - splitting outgoing deliveries

    In article <com> com writes:
    $my server connection to the world has a dynamic IP from my ISP - i have
    $no choice in the matter.

    I'm in a similar boat, running my own server from home on a
    broadband connection. I prefer to deliver directly where
    possible (though I could simply use a smarthost, as the host
    I use isn't a spam haven), so I only want to use a smarthost
    for sites that block my ISP's customer networks.

    Delivery in MMDF is handled by channels. It's entirely possible
    that more than one channel could be capable of delivering a given
    message; MMDF will use the first suitable channel, in the order
    of MCHN entries specified in mmdftailor. So you can leave your
    DNS-based SMTP channel in place, as long as there's a channel
    listed somewhere before it which will handle delivery to those
    hosts which you know reject your mail if you try connecting directly.
    (You can also leave domains alone. As long as the message matches
    any domain, including the DNS-based one that you already have,
    you're OK.)

    Here are some excerpts from my mmdftailor file with explanatory
    comments. The various parameters to the MTBL and MCHN commands
    are the result of gluing bits and pieces of various mmdftailor files
    together over the years so I don't promise that they're all necessary
    or ideal.

    --------------------8<--------(cut here)--------->8-------------------
    ; [...]
    ;
    ; MTBL line added to define the SMTP relay channel which uses a
    ; smarthost, followed by the usual SMTP channel that uses DNS
    ;
    MTBL show="SMTP relay channel", name=smtprlychn, file=smtp-relay.chn,
    flags=channel
    MTBL show="SMTP channel", name=smtpchn, flags=ns, flags=channel
    ;
    ; [...]
    ;
    ; Now we have the two SMTP delivery channels. First, the one that
    ; uses a channel file ... all of the parameters are cloned from
    ; the DNS-based SMTP delivery channel except where changes are
    ; needed
    ;
    MCHN show="SMTP Relay", name=smtprly, que=smtprly, tbl=smtprlychn,
    pgm=smtp, ap=same, ap=try, mod=imm, ttl=15,
    confstr="cht=7bit,hostname=my.host.name"
    ;
    ; And the usual DNS-based SMTP channel
    ;
    MCHN show="SMTP Delivery", name=smtp, que=smtp, tbl=smtpchn, pgm=smtp,
    ap=same, ap=try, mod=imm, ttl=15,
    confstr="cht=7bit,hostname=my.host.name"
    ;
    ; [...]
    --------------------8<--------(cut here)--------->8-------------------

    Then I create a channel file listing the hosts/domains which
    won't let me send directly to them, and the IP address of the
    relay server I use:

    --------------------8<--------(cut here)--------->8-------------------
    ; LHS is the name of the domain or host that won't accept mail
    ; directly from me
    ; RHS is the IP address of the relay server to use
    ;
    domain.name 10.10.10.10
    other.domain 10.10.10.10
    one.really.picky.host 10.10.10.10
    need.a.different.smarthost 192.168.1.1
    --------------------8<--------(cut here)--------->8-------------------

    You could even use different relay servers for different domains
    if necessary, as shown above.

    Note the format very carefully. At least in 5.0.5,
    the right-hand side must be an IP address - it cannot be a host
    name - and you can only use whitespace as a separator. If you
    use a host name, or use something like ": " as a separator, you
    will find that MMDF gets stuck in an infinite loop, using as much
    CPU time as it can, and (depending on your logging level) filling
    up your disk with log files as quickly as it can. Been there, done
    that.

    Now if only I could convince MMDF's smtp channel that a 5yz
    SMTP reply at any point in the conversation is a permanent error;
    aol.com, for instance, returns a 554 upon initial connection from
    a dialup/broadband site. To be fair to MMDF, this violates RFC821,
    and while RFC2821 permits it, AOL violates the requirement that
    the connection remain open after the 554. Despite the 5yz
    response, which in RFC821's explanation of SMTP return code
    theory indicates that the sender should not attempt exactly the
    same thing again, MMDF treats this as a temporary failure and
    keeps the mail in the queue rather than bouncing it, so unless
    I check the MMDF queue, I don't know my mail is being blocked
    until I get a warning MWARNTIME later.
    --
    Stephen M. Dunn <ca> [/ref][/ref]
    ------------------------------------------------------------------
    Say hi to my cat -- http://www.stevedunn.ca/photos/toby/
    Stephen Guest

  4. #4

    Default Re: mmdf on 5.0.7 - splitting outgoing deliveries

    In article <com>,
    Joe Chasan <com> wrote: 
     
     
     

    Some out there also deny direct email from a static IP also if you
    are in a DSL group provided by some telcos.
     
     

    It could be that the providers changed too. As of two weeks ago I
    had mail being bounced because the Sprint block where I have a
    static IP was in the rbls at easynet.nl.
     

    You could change to sendmail :-).

    I use the mailertable feature so that mail to certain domains,
    such as the entire .rr.com systems go to an ISP mail server.

    I personally don't like that as I can't tell if the mail has been
    delivered.

    I moved from smail to sendmail around 1995 so don't know if other
    mailers have an equivalent of mailertable. mailertable permits
    you to specify deliveriing certain domains - wildcard or specific -
    but uucp - or other transport methods - if you wish.

    Bill
    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  5. #5

    Default Re: mmdf on 5.0.7 - splitting outgoing deliveries

    In article <ca>,
    Stephen M. Dunn <ca> wrote: 

    I fixed this recently. You can (for the moment) pick up a new smtp outbound
    channel binary from ftp://ftp.armory.com/pub/scobins/smtp
    I think it'll work under 5.0.5 if you have oss646b installed.
    For the purpose of determining transient/permanent errors, this channel now
    only pays attention to the first digit of the reply code (as per RFC1123).

    Other changes:
    The smtp port is now read from /etc/services, so you can change it if you
    really want to (I had occasion to do that for some testing).

    The smtp initial-connection-open timeout can be configured with the confstr
    "open_timeout", and the 220 timeout can be configured with the confstr
    "220_timeout" (RFC1123: "Timeouts SHOULD be easily reconfigurable, preferably
    without recompiling the SMTP code".)

    There's also an smtp inbound channel binary at
    ftp://ftp.armory.com/pub/scobins/smtpsrvr
    It has these changes:

    By default, source routes are no longer generated for the return address.
    They can be enabled with the confstr sender_source_route=1 (RFC1123 severely
    deprecates source routes - customers were complaining about this back when I
    was in support!)

    You can enable verification of the return-address domain name with the confstr
    vrfy_sender_domain=1, and for the purpose of verification you can make domain
    names that resolve to certain addresses be treated as though they didn't
    resolve with the confstr 'no_such_domain_hosts', which takes a parameter
    consisting of a colon-separated list of [addresses] and names (which are
    resolved to addresses).
    For example, "vrfy_sender_domain=1,no_such_domain_hosts=[64.94.110.11]"
    (RFC2505 - MTAs "SHOULD be able to verify "MAIL From:" domain")
    Note that this feature is experimental - if you use it, keep an eye on the
    logs.

    John
    --
    John DuBois com KC6QKZ/AE http://www.armory.com/~spcecdt/
    John Guest

  6. Moderated Post

    Default Re: mmdf on 5.0.7 - splitting outgoing deliveries

    Removed by Administrator
    Stephen Guest
    Moderated Post

  7. #7

    Default Re: mmdf on 5.0.7 - splitting outgoing deliveries

    In article <ca>,
    Stephen M. Dunn <ca> wrote: 

    It turns out that the processing of the initial-open message and the response
    to the HELO message are handled in a different part of the code. Since I
    don't get any failures at that point, I didn't notice it :) I've fixed this
    problem. However, in so doing, I noticed it wasn't handling multiline
    responses correctly. Fixing *that* required a change in the deliver/channel
    protocol, so you'd need a new deliver, which in turn would require all new
    channel binaries. I will be building an MMDF supplement sometime soon that
    will include all MMDF binaries - I'll announce it here when it's available.

    John
    --
    John DuBois com KC6QKZ/AE http://www.armory.com/~spcecdt/
    John Guest

Similar Threads

  1. ipfilter outgoing
    By Sandy Rutherford in forum FreeBSD
    Replies: 0
    Last Post: February 17th, 12:34 AM
  2. Replies: 8
    Last Post: September 9th, 09:09 PM
  3. 5.0.7 MMDF Configuration Problems
    By pretzelboy in forum SCO
    Replies: 5
    Last Post: September 3rd, 11:28 AM
  4. MMDF large chan.log
    By drum1975 in forum SCO
    Replies: 0
    Last Post: July 9th, 09:33 AM
  5. MMDF causing system lag
    By tony@aplawrence.com in forum SCO
    Replies: 3
    Last Post: July 8th, 03:25 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •