On Sep 2, 2010, at 10:39 AM, Alessandro Vesely wrote:
On 02/Sep/10 00:15, Steve Atkins wrote:
I develop code that receives email to one address and forwards it
on to another address. It's not intended for use as an MLM, but it
does have a number of optional features in common - modifying the
subject line to add a tag, rewriting from / reply-to, modifying the
body content, adding or removing MIME elements.
I think that software is included in the broad definition of "resending MLM"
given in draft-ietf-dkim-mailinglists.
Yes. It's quite a stretch, but "resending MLM" is a fairly broad category.
Are senders aware that the messages they send to that address will be
forwarded the way you say?
No. The inbound mail is a mixture of 1:1 mail sent to role accounts, ARF
reports, replies to email and all sorts of other miscellaneous junk including
in some cases asynchronous bounces.
In case they are not, is that a feature or would the software let the sender
know, e.g. by answering "251 User not local; will forward to <forward-path>"?
It's a feature, I guess. The sender won't be notified of the forwarding in any
mechanical way - they generally can't be in the way you mention, as typically
the inbound mail will be store-and-forward.
May I also ask how does the admin specify that forward-path?
A set of forwarding rules, ranging from very specific ("Any email sent To
_this_ address, From _this_ address forward to this other address") to quite
general ("If any URL in the body of the inbound mail resolved to an IP address
in any of these ranges, forward it on to the associated email addresses"). The
admin might be able to produce a list of all the possible recipients, but is
likely to have no idea where any given inbound email will go in some cases.
Has the final recipient's MTA to be aware of the forwarding, e.g. for
whitelisting?
Not in any mechanical way. It's likely they'll be whitelisting the inbound mail
in some cases, but they'll be doing so based on the forwarder, not on the
original author. They may be relying on the original sender for further routing
in some cases, but they're not going to care about anything more than the From:
and To: fields, nor about any cryptographic authentication of them.
Have you considered SMTP-AUTH as a whitelisting means?
smtp auth isn't really useful for anything other than submission, I don't
think. It's not a good match here, certainly, not least because the outbound
email is store and forward.
It will break DKIM signatures (any that sign the subject line, at
the very least) much of the time. I've no intention of removing
those features in order to make it not break DKIM signature as,
well, they're features that were added because users wanted them.
Fine, IMHO.
DKIM signing the mail sent by the MLM is something I support doing.
Checking DKIM signature on the inbound is something I don't do now,
as there's not been much call for it, but it's something I'd like
to add eventually. Recording that inbound authentication data in a
header of the forwarded email is something I see as not terribly
useful, nor particularly desired by the users I've talked to, but
pretty much harmless.
It should quite straightforward for the hosting MTA to add an A-R field.
Easy enough to do, should there be any demand for it.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html