SourceForge has been redesigned. Learn more.
Close

#71 Add xforward/xclient to LMTP

open
nobody
None
5
2011-10-17
2011-10-17
Anonymous
No

XFORWARD/XCLIENT methods are very useful to track messages during delivery. Used by Postfix, Amavis, etc...
See:
http://www.postfix.org/XCLIENT_README.html
http://www.postfix.org/XFORWARD_README.html

Discussion

  • Stevan Bajic

    Stevan Bajic - 2011-11-01

    And where inside DSPAM do you want to use XFORWARD/XCLIENT? The only place where such a information could be useful is during RBL. Anyway... feel free to submit a patch that adds proper XFORWARD/XCLIENT handling inside DSPAM.

     
  • Tom Hendrikx (alt. account)

    Actually, inside DSPAM there is also TrackSources which uses the sender ip. And you might want to pass on the sender ip back to the server that is delivering DSPAM results (DeliveryHost) in dspam.conf).

     
  • Stevan Bajic

    Stevan Bajic - 2011-11-10

    I don't understand what you mean? You want to make the source IP available to the DeliveryHost. Is it that? Might I ask what the use case is for that? Can you name me a real world example where you could/would use the source IP on the DeliveryHost?

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous

    Anonymous - 2011-11-14

    Let suppose setup with Postfix --> DSPAM --> Postfix in standard SMTP/LMTP.
    This feature is strictly related to standard SMTP/LMTP interface with Postfix > 2.8.0.
    It is useful to trace messages in Postfix log.
    DSPAM could accept XFORWARD id from Postfix and pass it again during delivery.
    Now also Amavis supports this. It could be the same with DSPAM interfacing Posftix.

    This is what it happens with Amavis (from amavis.org):

    client-side and server-side support for the IDENT attribute of
    a Postfix XFORWARD smtp command (available since Postfix version 2.8.0).
    The attribute allows passing of a local message identifier (MTA queue id)
    downstream from a front-end MTA to a post-queue content filter and back
    to a back-end MTA. Amavisd makes this information available through an
    existing macro %Q (which was previously non-empty only in milter setups),
    and as such the information appears in the log when using a default amavisd
    log template. This information is also passed back to a re-entry MTA if
    it announces a support for this attribute (enabled on a back-end smtpd
    service with an option smtpd_authorized_xforward_hosts), so the log entries
    are now easier to correlate:

    back-end MTA:
    postfix/smtpd[72995]: 553261D1CB0: client=localhost[::1],
    orig_queue_id=2F5971D1CA3, orig_client=...

    post-queue content filter:
    amavis[20341]: (20341-15) Passed CLEAN ...
    Queue-ID: 2F5971D1CA3, queued_as: 553261D1CB0

    front-end MTA:
    postfix/lmtp[73130]: 2F5971D1CA3: ... relay=127.0.0.1[127.0.0.1]:10024,
    status=sent (250 2.0.0 from MTA(smtp:[::1]:10025):
    250 2.0.0 Ok: queued as 553261D1CB0)

    I leave this hint, but I don't think to be able to make a patch.
    Thanks for understanding.

     

Log in to post a comment.